Question

我们在执行应用程序的sress测试时遇到了奇怪的问题。我们使用Application_BeginRequest和Application_EndRequest来记录Web请求的开头和结尾，以及线程ID。

但是，从我们的日志中，我们看到Application_Begin_REquest未被触发：

我们使用以下代码在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));
}

这是我们的日志文件。省略了网址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

这只在performin压力测试时发生。 CPU利用率约为60％，最多有10个concurent请求正在执行。

任何想法，可能出现什么问题？

更新：我发现其他一些也有类似的问题（不同的配置：http://forums.iis.net/t/1154954.aspx）马捷

UPDATE＃2 ：今晚与事实有关，用于打印我们日志中的线程标识符的Thread.GetHashCode（）可能会发生变化。见ASP.NET - Thread.GetHashCode() changes

Answer 1

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

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

Answer 2

可能不是因为可能存在未处理的异常导致System.Diagnostics在不终止请求的情况下崩溃，因此可能不会触发BeginRequest。

我建议找到问题的最佳方法是安装IIS Debug Diagnostics并运行崩溃或挂起报告。你不会喜欢它，因为这个东西收集了大量的数据，但如果有某种线程崩溃/挂起它肯定会抓住它。

修改
在将备份日志记录事件直接实现到系统事件日志中的自定义事件日志时，我们发现在严重压力下访问日志的权限请求导致延迟（我们的猜测是在一定数量的请求之后，活动目录连接器无法及时回应）并最终例外。这似乎是在一个单独的线程上运行，我们可以看到倾销。 W3wp.exe继续运行，页面完成了响应任务，但我们发现应该记录的3个事件中，记录的事件不一致。我们还发现事件日志本身会变忙并抛出异常。我们发现了这个，因为这个异常不时会出现在用户界面而不是与其他界面消失。我们的最终解决方案是使用本地帐户为库提供权限，以减少对域策略的请求。这甚至清除了事件日志忙碌的症状。那时我们很高兴它消失了我们没有进一步追求它。

Application_BeginRequest不会在压力环境中被触发

2 个答案: