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