Asp.net 应用程序_BeginRequest未在压力环境中激发

在执行应用程序的可靠性测试时，我们发现了一些奇怪的问题。我们使用Application_BeginRequest和Application_EndRequest记录web请求的开始和结束以及线程id

  14.12.10 21:41:25.042 00013 00000            Request: 172.23.26.41 
  14.12.10 21:41:25.068 00013 00000            End request: 172.23.26.41 
  14.12.10 21:41:25.212 00013 00000            Request: 172.23.26.41 
  14.12.10 21:41:25.223 00013 00000            End request: 172.23.26.41 
  14.12.10 21:41:30.974 00013 00000            End request: 172.23.26.88 

但是，从我们的日志中，我们看到应用程序\u Begin\u请求没有被触发：

我们使用以下代码登录global.asax.cs：

protected void Application_BeginRequest(object sender, EventArgs e)
{
  string url = "";
  if (HttpContext.Current != null)  // this should alway be true
    url = HttpContext.Current.Request.Url.ToString();

  Dbg.WriteLine(String.Format("Request: {0} {1}", HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"], url));

  // integration calls measurement
  HttpContext.Current.Items.Add("wcfElapsed", new TimeSpan());

}

protected void Application_EndRequest(Object sender, EventArgs e)
{
  string url = "";
  if (HttpContext.Current != null)  // this should alway be true
    url = HttpContext.Current.Request.Url.ToString();

  Dbg.WriteLine(String.Format("End request: {0} {1}", HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"], url));
}

这是我们的日志文件。URL被省略。00013列是线程id

  14.12.10 21:41:25.042 00013 00000            Request: 172.23.26.41 
  14.12.10 21:41:25.068 00013 00000            End request: 172.23.26.41 
  14.12.10 21:41:25.212 00013 00000            Request: 172.23.26.41 
  14.12.10 21:41:25.223 00013 00000            End request: 172.23.26.41 
  14.12.10 21:41:30.974 00013 00000            End request: 172.23.26.88 

您可以看到，在最后两行中有两个“结束请求”，但在最后一行日志中没有（开始）请求

我们的Dbg.WriteLine使用System.Diagnostics跟踪侦听器将数据输出到文件

环境：Windows Server 2008 R2，ASP.NET 3.5

只有在进行压力测试时才会发生这种情况。CPU利用率约为60%，最多执行10个并发请求

有什么想法吗，有什么问题吗

更新：我发现其他一些也有类似的问题（尽管配置不同：） 马特

---

更新#2：今晚可能与以下事实有关：用于打印日志中的线程标识符的Thread.GetHashCode（）可能会更改。请参阅

可能不是BeginRequest没有触发，而是可能存在未经处理的异常，导致System.Diagnostics在不终止请求的情况下崩溃

我建议找到问题的最佳方法是安装并运行崩溃或挂起报告。您不会太喜欢它，因为它收集了大量的数据，但是如果出现某种线程崩溃/挂起，它肯定会捕获它

编辑：

---

在将备份日志记录事件直接实现到系统事件日志中的自定义事件日志时，我们发现在压力很大的情况下，访问日志的权限请求会导致延迟（我们猜测，在一定数量的请求之后，active directory连接器无法及时响应）最后是例外。这似乎是在一个单独的线程上运行的，我们可以看到这个线程。W3wp.exe继续运行，页面完成了其响应职责，但我们发现，在应记录的3个事件中，记录的事件不一致。我们还发现事件日志本身会变得繁忙，并引发异常。我们发现这个异常是因为这个异常会不时地出现在用户界面上，而不是随着其他异常消失。我们的最终解决方案是使用本地帐户向库提供权限，以减少对域策略的请求。这甚至清除了“事件日志正忙”症状。当时，我们非常高兴它消失了，我们没有进一步研究它。

我认为这可能是由于调试到文件，无法处理所有这些事件。写入文件有其局限性

---

我建议使用您可以在中看到的默认调试跟踪。

我们将调试信息同时输出到文件和内置的.NET侦听器，该侦听器使用OutputDebugString Win32 API（被DebugView截获）。我不相信，那个写短信的人漏掉了几行。伟大的那么您检查了在DebugView中得到的结果了吗？DebugView应该包含与TextWriter相同的结果。我不能在压力测试期间使用它，因为我们记录了太多的数据。@matra我认为您仍然需要测试它，因为它包含相同的内容，以消除textwriterlistener的线程问题。很难相信，TextWriterTraceStener会接受异常。Windbg和其他工具无法通过压力测试使用，因为它们对测试影响太大（它们截取OutputDebugString并将输出写入自己的窗口，这会使压力测试变得毫无用处）。我还使用Reflector检查了TextWriterTraceListener，它不会接受任何异常。它只是将数据转发给标准StreamWriter。@matra-我没有任何与线程相关的法医学知识，但我看到在重负载下的线程在请求周期中孤立的线程上有异常。我不知道这是发生在你的情况下，但症状是相似的，请求似乎完全完成，但出于某些原因，在中间部分要么根本没有执行或部分执行。在我的例子中，它总是发生在不相关的dll上，但从来没有发生在系统dll上。@matra-而且，不是对象或dll正在“吞咽”异常，只是如果它在孤立线程上，它没有地方报告异常。事实上，我刚刚记得，我的一个问题孩子导致了这个问题，那就是System.Diagnostics.EventLog（所以有一个系统库）。我将添加一个编辑。评论太多了。乔尔，谢谢你的更新。你说的“中间部分没有被执行”是什么意思？1）一些事件没有提出或2）IJOEL，谢谢更新。你所说的“中间部分没有被执行”是什么意思？1）一些事件没有提出或2）执行的方法的开始和结束，但不是方法的中间部分。您所说的增强线程是什么意思1）服务于HTTP请求但被中断的线程（在本例中，应用程序_beginRequest应该被调用，我们应该在out文本文件中有一个日志条目）或2）后台线程（是的，在这种情况下，它无处报告异常，但它也与http请求和BeginRequest无关）