使用性能监视工具“New Relic”我在“AcquireRequestState”中偶尔会看到（但是太多）长时间延迟。我说的是10秒，20秒延迟，有时是几分钟。
我知道我们没有为此活动编写自己的事件处理程序。
我在哪里开始寻找这些延迟的原因？我到目前为止在msdn上发现的一些小信息都没有用。
我的团队今天早些时候看到了NewRelic报告的“AcquireRequestState”延迟，当时我们的一个ASP.NET应用程序在特定页面上出现了性能问题。
根本原因结果是我们最近部署到SQL Server数据库的存储过程的更改，这无意中导致该存储过程需要很长时间才能执行。存储过程被称为显示具有性能问题的页面的一部分。
我们能够通过识别和修复存储过程的性能问题来解决该问题。原来，NewRelic的“AcquireRequestState”问题无关紧要;这是问题的症状，而不是原因。
这是在Windows Server 2008上运行的ASP.NET 4.5应用程序。
tl; dr：NewRelic报告的“AcquireRequestState”延迟可能是导致ASP.NET应用程序中的一个或多个页面和/或AJAX请求需要很长时间才能加载的其他问题的副作用。
尝试在服务器上应用Hotfix Rollup 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。
我怀疑你的存储过程更改可能突出了一个稍微不同的会话锁定问题，我们报告了大致相同的不同场景，我真的很想鼓励你测试这里提到的async会话提供程序和确保您使用每个会话应用程序的并发请求设置：
https://stackoverflow.com/a/55331786/7581050
最终，任何长时间运行的进程（在您的情况下，存储的proc更改）都会阻止对该会话的任何进一步请求。由于这个“块”发生在IIS管道的不同部分，NewRelic只是将其记录为“AcquireRequestState”
PS：我知道这个答案来得太晚了但我终于找到了解决类似问题的东西，我怀疑将来会帮助很多人。