c# - NewRelic、异步 http 处理程序和 AcquireRequestState

Question

分布式 ASP.NET Web 应用程序中的一个异步处理程序有问题。首先让我解释一个用例:

• 应用程序在装有 .NET Framework 4.5.2 的 win 2012 机器上使用 IIS 8

• 应用程序像这样通过 web.config 禁用了 session 和身份验证模块

       <system.webServer>
         ....
         <modules>
              <remove name="WindowsAuthentication" />
              <remove name="Session" />
              <remove name="FormsAuthentication" />
          </modules>
       </system.webServer>
  

• 应用程序使用自定义异步网络处理程序来处理特定请求

• 应用程序的流量非常大(每台服务器每分钟约 5 万个请求，异步处理程序每​​台服务器每分钟约 1 万个请求，所有请求均从 NewRelic 跟踪)
• 应用程序通过多个 w3wp 进程(2 个 w3wp 进程)和多个虚拟服务器(大约 10 个服务器)分发
• 应用程序有大量连接

所有正常(同步请求)都工作正常，但做更多工作的异步请求(这就是我们使用异步请求的原因)通常很慢，但 NewRelic 报告说它很慢，因为“AcquireRequestState”。现在我查看了谷歌和堆栈溢出，这个事件与创建 session 有关，但我们在 web.config 中禁用了 session 。有谁知道“AcquireRequestState”还能做什么？我们是否缺少删除 session 状态的地方？将它从 web.config 添加到 machine.config 什么也没做...

这是 NewRelic 中请求的片段:

   **Slowest components   Count Duration     %   **
     AcquireRequestState    1   12,600 ms   100%  --> WTF?
     ExecuteRequestHandler  1   5.01 ms     0%
     Integrated Pipeline    1   0.334 ms    0%
     UpdateRequestCache     1   0.3 ms      0%
     EndRequest             1   0.168 ms    0%
     AuthenticateRequest    1   0.161 ms    0%
     Total time                 12,600 ms   100%

编辑:我有<sessionState mode="Off" />在 web.config(<system.web> 部分)所以不是这样。

Answer 1

我已经调查过了，因为我们有类似的问题，我发现了这个 forum post ，有趣的回复是这样的:

Unfortunately, the issue is not as simple as just turning sessionState off. In fact, one of the key phrases when describing the challenges with AcquireRequestState is the phrase for example, session state when it comes to when this event is raised. In digging deeper into this (actually looking at the .NET source) we can see that this is called when an EventHandler is executed or a RequestNotification object is created. I daresay there are other methods and/or events that, when called, will raise an AcquireRequestState event. Tracking down all of them represents something of a struggle. It seems this is something not talked about a lot outside of the more normalized session state discussions. The most common place we see this event raised is certainly related to session state management. But there are very obviously outliers where these event can still be raised. It can even be called directly from application code. The thing the agent grapples with is that it can identify the event, but rarely the source. When it is raised as part of the ASP pipeline, the only notification the agent gets is that this is one segment of the transaction. The source, or the methods executed inside of the event, is something the agent is rarely instrumenting by default. I wish we could offer more insight for you on this. There are a lot of moving parts inside of a .NET application, some of which involve the operating system itself, IIS, the version of .NET, whether or not the methods are asynchronous, application pool settings, execution modes, permissions, etc. While I don't want to open a second can of worms here, this harkens to the issue with the lack of stack traces for 500 errors. The agent provides a stack trace when it is offered and/or available. Where the stack trace, if one even exists, occurs within the ASP pipeline is extremely important. Sometimes it occurs before any actual application code is executed. In such cases the error is reported to the application, which in turn lets the .NET agent see and report that an error occurred, but no other details are provided. The agent simply sees that it happened and reports as much information as is possible. Beyond that the agent simply has no further details it can offer.

我们放弃了，所以我很想知道您是否想通了!