我从质量检查团队那里收到一份报告，该报告显示ASP.NET应用程序的特定部分在同时只有10个用户的情况下显示出很高的CPU使用率。正在报告的其他症状是：
高争用速率/秒（.NET CLR LocksandThreads计数器）。
观察到应用程序花费29％的时间执行运行时检查（RT检查中的时间百分比-.NET CLR安全）
浏览代码并运行SQL Trace，同时重新运行屏幕上的单个AJAX调用，使我看到一些调用进行了许多单独的同步SQL调用（在一种情况下为60+），其中一些非常快，而有些则相当慢。
其他详细信息：此代码使用Windows身份验证。
因此，我很清楚，从性能的角度来看，大量单独的SQL往返可能是一个问题，但是事实可能是代码必须一遍又一遍地等待来自SQL框的响应才能完成。 RT检查中的争用率和时间百分比高吗？我还有其他问题要问吗？
最佳答案
如果您的应用程序安装在与数据库不同的服务器上，则您所描述的症状表明当前瓶颈与数据库无关。
我之所以强调“当前”瓶颈，是因为性能改进是一个反复的过程，您会发现一个瓶颈，将其修复并解决下一个瓶颈（可能有完全不同的症状），依此类推，直到客户满意为止。
如果将CLR锁和线程性能计数器设置为仅监视您的应用程序进程，则描述的结果将意味着您在应用程序代码中有很多争用，在数据库中则没有。
长查询具有相反的症状，大量的IO和等待线程，CPU较低（因为它主要等待数据从DB /网络返回），而吞吐量仍然较低。
您没有提到每秒的争用率是多少，但是假设您声明只有10个用户连接到该应用程序，那么任何数目都将是一个很大的数目，并且增加10个用户，应用程序将无响应。
下一步将打开资源争用分析器（Visual Studio内置了此功能），并查看引起大多数争用的锁。
在服务器端应用程序上，锁定通常不利于吞吐量，应通过各种方式避免使用锁定（使用不可变数据模型，不可变缓存，队列，CompareExchange操作，线程本地数据-有时甚至以克隆数据等为代价... ）。
遍历代码，看看可以摆脱哪些锁，然后进入下一个瓶颈（DB可能是:)）
希望这对您有帮助，Ofir。
关于c# - 过多的SQL调用是否可能导致高水平的.NET争用率和CLR安全RT检查，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/23659633/