c# - 高水平的 .NET 争用率和 CLR 安全 RT 检查是否是由过多的 SQL 调用引起的

Question

我从我们的 QA 团队收到一份报告，称 ASP.NET 应用程序的特定部分显示 CPU 使用率非常高，同时只有 10 个用户。报告的其他症状是:

• 高争用率/秒(.NET CLR LocksandThreads 计数器)。
• 观察到应用程序花费 29% 的时间执行运行时检查(RT 检查所占时间百分比 - .NET CLR 安全性)

查看代码并运行 SQL Trace，同时重新运行屏幕发出的各个 AJAX 调用，我看到一些调用发出大量单独的同步 SQL 调用(在一个案例中超过 60 个)，有些非常快，有些相当快慢。

其他详细信息:此代码使用 Windows 身份验证。

所以我很清楚，从性能的角度来看，大量单独的 SQL 往返可能是一个问题，但是代码必须一遍又一遍地等待 SQL 框的响应才能完成这一事实对 RT 检查中的高争用率和 % 时间负责？还有其他我应该问的问题吗？

Answer 1

如果您的应用程序安装在与数据库不同的服务器上，则您描述的症状表明当前瓶颈与数据库无关。

我强调“当前”瓶颈的原因是因为性能改进是一个迭代过程，您找到一个瓶颈，解决它并遇到下一个瓶颈(可能有完全不同的症状)，依此类推，直到客户很满意。

如果您将 CLR 锁和线程性能计数器设置为仅监视您的应用程序进程，您描述的结果将意味着您的应用程序代码中有很多争用，而不是数据库中。长查询有相反的症状，大量 IO 和等待线程和 CPU 很低(因为它主要等待数据从数据库/网络返回)- 而吞吐量仍然很低。

你没有提到每秒的争用率是多少，但鉴于你说只有 10 个用户连接到该应用程序，任何数字都将是一个很大的数字，再添加 10 个用户，应用程序将呈现无响应。

接下来的步骤是打开资源争用分析器(Visual Studio 内置了此功能)，并查看导致大部分争用的锁。在服务器端应用程序中，锁定通常不利于吞吐量，应通过各种方式避免(使用不可变数据模型、不可变缓存、队列、CompareExchange 操作、线程本地数据——有时甚至以克隆数据为代价，等等……) ).

检查你的代码，看看你可以摆脱哪些锁，然后你就会到达下一个瓶颈(DB probably :) )

希望这对您有所帮助，Ofir。