使用性能监控工具 "New Relic",我发现偶尔会出现(但太多)在 "AcquireRequestState" 中的长时间延迟。我指的是10, 20秒的延迟,有时甚至几分钟。
我知道我们没有为此事件编写自己的事件处理程序。
我应该从哪里开始查找这些延迟的原因?到目前为止,我在 msdn 上找到的少量信息并没有什么帮助。
使用性能监控工具 "New Relic",我发现偶尔会出现(但太多)在 "AcquireRequestState" 中的长时间延迟。我指的是10, 20秒的延迟,有时甚至几分钟。
我知道我们没有为此事件编写自己的事件处理程序。
我应该从哪里开始查找这些延迟的原因?到目前为止,我在 msdn 上找到的少量信息并没有什么帮助。
今天,我们的ASP.NET应用在特定页面表现出性能问题时,我的团队看到了NewRelic报告的“AcquireRequestState”延迟。
根本原因是最近部署到我们的SQL Server数据库中的存储过程发生了更改,无意中导致该存储过程执行时间非常长。该存储过程作为显示页面的一部分进行调用,进而导致页面性能问题。
我们通过识别和解决存储过程的性能问题来解决此问题。 NewRelic的“AcquireRequestState”问题实际上与问题无关,它只是问题的症状而不是原因。
这是在运行在Windows Server 2008上的ASP.NET 4.5应用程序上发生的。
简而言之: NewRelic报告的“AcquireRequestState”延迟可能是其他问题的副作用,这些问题导致ASP.NET应用程序中的一个或多个页面和/或AJAX请求加载时间较长。
请在服务器上尝试应用热修复累积更新2828841。
问题6
症状
当您发送许多具有相同SessionId的并发请求到ASP.NET 4.5 Web应用程序时,一些请求可能会意外地在RequestAcquireState阶段冻结。
解决方案
应用此热修复后,热修复将确保EndRequest事件始终触发。
此热修复适用于 Windows 7 Service Pack 1(SP1), Windows Server 2008 R2 SP1, Windows Server 2008 Service Pack 2(SP2)和 Windows Vista SP2。
我怀疑你存储过程的更改可能会突出显示一些与会话锁定相关的稍微不同的问题,我们曾经因为其他方案而报告了大致相同的情况,我真诚地希望你测试这里提到的异步会话提供程序,确保你使用每个会话应用设置的并发请求:
https://dev59.com/eFgQ5IYBdhLWcg3wvGYY#55331786
最终,任何长时间运行的进程(在您的情况下为存储过程更改)都会阻止该会话的任何进一步请求。 由于此“阻塞”发生在IIS管道的不同部分,因此NewRelic仅将其记录为“AcquireRequestState”
PS:我知道这个答案来得很晚,但我终于找到了一些解决我们类似问题的东西,并且我认为它将帮助许多人解决类似问题。