System.Web.HttpApplication.BeginRequest() 中的间歇性延迟，与 SessionState 无关答案

【问题标题】：Intermittent delays in System.Web.HttpApplication.BeginRequest(), not SessionState relatedSystem.Web.HttpApplication.BeginRequest() 中的间歇性延迟，与 SessionState 无关
【发布时间】：2013-10-24 21:52:32
【问题描述】：

我们有两个 Web 应用（Azure Web 角色），它们在 System.Web.HttpApplication.BeginRequest 期间都偶尔会出现长时间延迟（40 到 60 秒）。我们知道这一点是因为我们使用 NewRelic 来监控我们的网络应用程序。 The usual culprit is thread agility issues 由于 ASP.NET 的会话状态锁定机制，但是我们不使用 ASP.NET 会话状态，并且在其中一个站点上我们根本不使用会话。

一个应用程序比另一个应用程序复杂得多，延迟也更多，但我将在这个问题中使用简单的应用程序来缩小根本原因。

简单的网络应用程序是一系列基于 ServiceStack 的网络服务。它不使用会话。它仅充当基于 WCF 的服务层的中介。它主要将请求引导到 WCF 服务，然后将响应映射到视图以传输回代理。服务器在运行负载时甚至都不会出汗（最多 2.5% CPU）。

请问，可能的原因是什么？

我最好的猜测是这是一个线程敏捷性问题，因为它似乎在等待某些东西，这表明某处有锁。但是如果不是会话状态，它还在等什么？ NewRelic 或 ServiceStack 导致锁定？
NewRelic报错，没有问题。好吧，当我们过去使用 ASP.NET 会话状态时，NewRelic 正确地报告了问题，并且得到了更多这样的延迟。

【问题讨论】：

我们遇到了完全相同的问题。你的问题是什么，你是如何解决的？谢谢

标签： asp.net servicestack newrelic

【解决方案1】：

New Relic 没有特定于 ServiceStack 的工具，而 WCF 是非常基本的，没有自定义工具。没有更多信息，很难提供任何建议。线程敏捷性也是罪魁祸首，我建议先调查该路线。

New Relic 可能将时间归因于它不应该的方法。我可能会首先使用 New Relic Support 开一张票，并包含您的所有信息（代理日志、IIS/ASP.NET 配置、自定义处理程序？以及指向您的 New Relic 图的永久链接）。

【讨论】：

谢谢，这听起来是一个明智的起点。我会看看 NewRelic 是否可以帮助找到解决方案。我不会标记答案，以防有人提出一些具体的潜在原因。
我们发现，除非您为受影响的页面添加 New Relic 自定义工具，否则 New Relic 往往会将内容归入 BeginRequest/BeginProcessRequest 之下。这是因为这是 New Relic 代理内置的最后一个功能，因此就 New Relic 代理而言，此后的任何延迟都被视为此功能的一部分。引用 New Relic 的话：“就代理而言，这可能是它所知道的关于交易的全部信息。因此，我们将使用该方法报告时间。”