asp.net - 为什么我的 Web 应用程序出现延迟？

Question

我们有一个 ASP.Net 应用程序，它在 IIS6 下表现异常。该应用程序本身是简单的 ASP.Net 2.0 Webforms 协议(protocol)，没有什么太奇怪的事情发生(管道中有几个 HTTP 模块，但我不会认为那些奇怪的 :) )。我不明白的是页面执行时间，或者更具体地说，是 ASP.Net 跟踪 (trace.axd) 报告的时间与客户端 (Fiddler) 观察到的时间之间的差异。当应用在开发者的盒子(WinXP、IIS5.1)上运行时，ASP.Net和Fiddler报告的时间非常接近:

页面执行时间:0.0919834
Fiddler 总序列时间:0.1560980

我可以理解花费 60 毫秒将 5KB 的数据从 IIS 传输到 Fiddler(两者都在同一台机器上运行，顺便说一句)。现在，当我们将代码移动到服务器(Win2k3、IIS6)时，画面发生了巨大的变化:

页面执行时间:0.1702014
Fiddler 总序列时间:0.5156283

这是同一页面，Fiddler 再次与代码在同一台机器上运行。为什么传送相同的 5KB 突然需要 350 毫秒？

PS。在两台机器上，结果都是通过通过实际机器的主机名访问 URL 来获得的，例如http://machinename/app/page.aspx (相对于 http://localhost/app/page.aspx )。

聚苯乙烯。配置方面，开发盒和服务器的设置尽可能接近——两者都使用完全相同的 web.config。两者都使用集成的身份验证访问数据库(sql server)，因此，该应用程序在域帐户下运行。该应用程序使用表单例份验证，并且不会模拟(即它始终在同一帐户下运行)。现在，它在 IIS5 上的工作方式与 IIS6 不同——在 IIS5 上，帐户在 machine.config 的标记中指定，而在 IIS6 上，它是 AppPool 设置。两种环境的设置似乎都很典型，我无法想象它会导致 350 毫秒的延迟......

Answer 1

在花费了我们通过 MSDN 订阅获得的宝贵的少数支持事件之一之后，我终于知道了“所有这些时间都花在了哪里”问题的正确答案。简而言之，时间花在了我们管道中的 HTTP 模块上。 ASP.Net trace.axd 报告的时间测量仅记录在 .aspx 页面本身所花费的时间，模块为 不是 包括。

确定这一点的一种简单方法(并查看每个模块完成其工作需要多长时间)是使用 ETW(Windows 事件跟踪)。这里是 explanation (我强烈怀疑这篇文章是在他们查看我们的案例之后写的 :))我可以添加到上面出色描述中的一件事是我使用了 SvcTraceViewer而不是 LogParser 来分析跟踪输出。

更新:上述方法也适用于 Windows Server 2008，只要确保你有 Tracing installed .