我们有一个ASP.Net应用程序，在IIS6下表现得很奇怪。应用程序本身是简单的ASP.Net 2.0 Webforms交易，没有什么太奇怪的在那里（管道中有几个HTTP模块，但我不会考虑那些奇怪的:)）。我不明白的是页面执行时间，或者更具体地说，是ASP.Net跟踪（trace.axd）报告的时间与客户端（Fiddler）观察到的时间之间的差异。当应用程序在开发人员的框中运行时（WinXP，IIS5.1），ASP.Net和Fiddler报告的时间非常接近：
Page exec time : 0.0919834 Fiddler Total Sequence time: 0.1560980
我可以理解60ms用于从IIS向Fiddler获取价值5KB的数据（两者都在同一台机器上运行，BTW）。现在，当我们将代码移动到服务器（Win2k3，IIS6）时，图片发生了巨大变化：
Page exec time : 0.1702014 Fiddler Total Sequence time: 0.5156283
这是同一页面，Fiddler再次使用代码在同一台机器上运行。为什么突然需要350ms才能提供相同的5KB？
PS。在两台机器上，通过实际机器的主机名访问URL，例如，获得结果。 http://machinename/app/page.aspx（与http://localhost/app/page.aspx相对）。
PPS。在配置方面，开发盒和服务器的设置尽可能接近我们 - 它们都使用完全相同的web.config。两者都使用集成的auth命中了DB（sql server），因此，应用程序在域帐户下运行。该应用程序使用表单身份验证，并且不模拟（即它始终在同一帐户下运行）。现在，它在IIS5上的工作方式与IIS6不同 - 在IIS5上，帐户在machine.config中的标记中指定，而在IIS6上，它是AppPool设置。对于这两种环境来说，这种设置似乎很典型，我无法想象它会导致350ms的延迟......
答案 0 :(得分：4)
在花费了我们的MSDN订阅所支持的少数几个支持事件之后，我终于知道了“所有这些时间花在哪里”问题的正确答案。简而言之，我们在管道中使用的HTTP模块花费了大量时间。 ASP.Net trace.axd报告的时间测量仅记录.aspx页面本身所花费的时间，模块包含 NOT 。
确定这一点（以及查看每个模块需要多长时间才能完成此任务）的一种简单方法是使用ETW（Windows事件跟踪）。这是explanation（我强烈怀疑这篇文章是在他们查看我们的案例后写的:) :)我可以添加到上面的优秀描述中的一件事是我使用SvcTraceViewer而不是LogParser来分析跟踪输出。
更新：上述方法也适用于Windows Server 2008，只需确保您拥有Tracing installed。
答案 1 :(得分：1)
对您要调用的URL执行跟踪路由并进行比较。我打赌你在机器内部的开发者机器，但在生产机器上，你是外部的，然后通过IP地址返回。
如果是这种情况，请尝试将其添加到主机文件中（c：\ windows \ system32 \ drivers \ etc \ hosts
www.mysite.com 127.0.0.1
这将确保您的请求不会在机器外冒险提出请求。您应该看到响应时间开始相互一致。
<强>更新
鉴于新的更新。如果服务器负载不足，那么在生产测试时可以解决这个差异，因为它正在积极尝试提供比仅仅尝试交付1的开发机器更多的请求。
或者可能是因为您正在测试两个不同版本的IIS，XP上的5.1和2003上的6.0。除非两个环境运行相同的软件，否则真的无法解释差异。
答案 2 :(得分：0)
应用程序是否在两个盒子上以相同的版本配置运行？
编辑：请求管道在IIS5和IIS6之间发生巨大变化，trace.axd只会看到它的ASP.NET部分，而不是新的应用程序池和HTTP.Sys组件。我认为可以在IIS6上稍微调整一下配置，但是您可能正在研究轻量级非生产Web服务器（IIS5）与强大的Web服务器之间的区别，这些Web服务器具有单独的应用程序池来管理和更多的抽象层。