我们在 AcquireRequestState 中获取了大量的 ajax 调用，花费了大量时间，在我们的旅行中，我们偶然发现了 ASP.Net 中的 session 锁定 gem，因此我们实现了一个自定义 session 状态处理程序(基于下面的链接) .
进行更改并部署后，我们看到 AcquireRequestState 急剧下降，但它已被 PreExecuteRequestHandler 取代。
今天早上我突然意识到我们已经包括了 OWIN，这可能是 PreExecuteRequestHandler 占用这么多时间的原因。然后我继续删除它，在我部署代码的那一刻，PreExecuteRequestHandler 从列表中消失了。可悲的是，它现在又被 AcquireRequestState 所取代，成本几乎完全相同。
我们似乎确实在返回部分 View 的 AJAX 调用上受到了相当大的打击，尽管吞吐量更高，但返回原始类型或 JSON 对象的 AJAX 调用似乎基本不受影响。
所以这给我留下了 3 个我绝对难以回答的问题，我认为一个问题的答案会引导我们找到另外两个问题的答案。
1) 为什么在安装 OWIN 时成本从 AcquireRequestState 转移到 PreExecuteEventHandler？ OWIN 上是否标记为 IRequireSessionState？ (据我了解，AcquireRequestState 应该更早出现在托管管道中)
2) 我们如何获得有关 AcquireRequestState 内部实际发生的事情的更多信息？或者我们的时间是否更好地用于返回 JSON 对象并使用它来呈现我们在 UI 上需要的内容？
3) 我们确实看到一些请求(虽然很少)映射到 New Relic 中的/{controller}/{action}/{id}，然后在上面提到的请求期间完全卡住.尽管对我们的路由设置了限制以仅路由到我们在项目中拥有的 Controller 和操作，但这仍然存在。
附言: 这看起来确实与以下内容非常相似，我们在 New Relic 中也看到了这一点:long delays in AcquireRequestState
自定义 session 模块来自: I just discovered why all ASP.Net websites are slow, and I am trying to work out what to do about it
最佳答案
如果有人试图排除我们最终面临的 session 问题，但仍然需要依赖 session 值(因此您不能只在 Controller 级别禁用 session )，请查看以下 session 状态提供程序:
https://github.com/aspnet/AspNetSessionState
请特别注意以下应用程序设置:
<add key="aspnet:AllowConcurrentRequestsPerSession" value="[bool]"/>
您需要升级到 .Net Framework 4.6.2，但在我们的例子中，这是一个很小的代价。
关于c# - AcquireRequestState 与 PreExecuteRequestHandler，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42300438/