不可忽视的 .NET 应用5大性能问题

2、过度或不必要的日志
日志记录是调试工具库里的强大武器，可以帮助你识别应用执行过程中在特定时间内可能发生的异常。当错误发生时，捕捉错误信息并收集尽可能多的上下文信息是非常重要的。然而，简洁地捕捉错误条件和过度记录之间是有差别的。
最普遍的两个问题就是：
多级别异常日志
错误配置生产日志级别
异常日志能帮助你了解应用程序中发生的问题，因而非常重要。但一个常见的问题是，应用程序所有层级的异常都进行记录。例如，你的某个数据访问对象捕获到一个数据库异常，并将该异常传达到服务层。服务层可能会捕捉该异常，并将其传达到网络层。如果我们在数据层、服务层和网络层上都记录该异常，那么我们对此相同的错误条件就有三条堆栈记录。这会导致写入日志文件的额外负担，还会使日志文件充满冗余信息。但这个问题非常普遍，我敢断言，如果你检查自己的日志文件，你很可能会发现多个这样的例子。
生产应用中常见的另一个大的日志问题与日志级别有关。.NET 日志记录器定义了以下日志记录级别（.NET TraceLevel 与 log4net 中的命名会有所不同，但绝对相似）：
Off
Fatal
Error
Warning
Info
Verbose / Debug
在生产应用程序中，你应该只记录 error 或 fetal 级别的日志语句，在更宽松的环境中，捕捉 warning 甚至 info 级别的日志信息也完全可以，但是一旦应用投入生产环境，用户负载将迅速填满日志并使应用程序陷入瘫痪。如果你不经意地将生产环境下的应用日志级别设为 debug，应用的响应时间比正常情况下高两或三倍都不奇怪！

4.潜在的数据库问题
几乎所有的内容应用最终都会涉及到向/从数据库或文档存储储存/检索数据。因此，数据库、数据库查询，以及存储过程调优对应用程序的性能来说是最重要的。
程序架构师/开发人员和数据库架构师/开发人员之间有一个哲学性的划分。应用程序架构师倾向于认为所有的业务逻辑都应该驻留在应用程序中，数据库应该只提供访问数据的通道。另一方面，数据库架构师更倾向于认为将业务逻辑推到数据库中更有益提高性能。这个划分的答案很可能就是介于两者之间。
作为一个应用程序架构师，我倾向于将更多的业务逻辑应用在程序当中，但我完全承认数据库架构师能更好的理解数据和与数据交互的最佳方式。我认为，这两个群体之间的协同合作才能产生最佳的解决方案。但是，不管你倾向于哪一方，请确保你的数据库架构师检查你的数据模型，所有的查询语句和存储过程，他们都有丰富的知识帮助你以最佳的方式来调整和配置数据库，他们有大量的工具可以为你调整查询语句。例如，有一些工具可用于 SQL 调优，遵循以下这些步骤：
分析 SQL 语句
确定查询的执行计划
利用人工智能生成备选的 SQL 语句
确定所有备选方案的执行计划
提出最佳的查询方式来完成目标
当我在写数据库查询代码时，我使用了这类工具，并在高负载情况下量化了结果，一些细微的调整和优化，都能导致极大的性能提升。