高水平的.net争用率和CLR安全RT检查是否由过多的SQL调用引起?
本文关键字：SQL 调用 检查 争用率 net CLR 安全 高水平 RT 是否 | 更新日期: 2023-09-27 18:03:34
我从我们的QA团队得到一份报告，ASP的一个特定部分。NET应用程序显示出非常高的CPU使用率，只有10个并发用户。报告的其他症状有:
- 高争用率/秒(。. NET CLR LocksandThreads计数器).
- 观察到应用程序花费29%的时间执行运行时检查(%的时间在RT检查- .NET CLR安全)
查看代码并运行SQL Trace，同时重新运行屏幕所做的单个AJAX调用，我看到一些调用进行了许多单独的同步SQL调用(在一种情况下超过60次)，有些非常快，有些相当慢。
附加细节:此代码使用Windows身份验证。
所以我很清楚，从性能的角度来看，大量单独的SQL往返可能是一个问题，但是代码在完成之前必须一遍又一遍地等待SQL框的响应，这一事实会导致RT检查中的高争用率和%时间吗?我还需要问别的问题吗?
如果应用程序安装在与DB不同的服务器上，则所描述的症状表明当前瓶颈与DB无关。
我强调"当前"瓶颈的原因是因为性能改进是一个迭代过程，您发现一个瓶颈，修复它，然后遇到下一个瓶颈(可能有完全不同的症状)，以此类推，直到客户满意为止。
如果您将CLR锁和线程性能计数器设置为只监视您的应用程序进程，那么您所描述的结果将意味着您的应用程序代码中有很多争用，而不是DB。长查询有相反的症状，大量的IO和等待线程和CPU很低(因为它主要等待数据从DB/Network返回)-而吞吐量仍然很低。
你没有提到每秒的争用率是多少，但是考虑到你说只有10个用户连接到应用程序，任何数字都将是一个大数字，并且增加10个以上的用户，应用程序将呈现无响应。
接下来的步骤是打开资源争用分析器(Visual Studio内置了这个功能)，并查看哪些锁导致了大多数争用。在服务器端应用程序中，锁通常不利于吞吐量，应该通过各种方式避免(使用不可变数据模型、不可变缓存、队列、CompareExchange操作、线程本地数据——有时甚至以克隆数据为代价，等等…)。
检查你的代码，看看你可以摆脱哪些锁，然后你会得到下一个瓶颈(DB可能:))
希望这对你有帮助。