4

我们有一个 ASP.Net 应用程序，它在 IIS6 下表现异常。该应用程序本身是简单的 ASP.Net 2.0 Webforms 交易，没有什么太奇怪的事情发生（管道中有几个 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 毫秒的延迟......

4

3 回答 3

4

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

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

更新：上述方法也适用于 Windows Server 2008，只需确保您已 安装 Tracing。

于 2009-02-27T00:09:19.977 回答
1

在您调用的 URL 上执行跟踪路由并比较它们。我打赌开发机器你留在机器内部，但在生产机器上你要去外部，然后通过 IP 地址返回。

如果是这种情况，请尝试将其添加到您的主机文件（c:\windows\system32\drivers\etc\hosts

www.mysite.com    127.0.0.1

这将确保您的请求不会冒险在机器之外发出请求。您应该看到响应时间开始彼此一致。

更新

鉴于新的更新。如果服务器负载不足，则在生产测试时这可能会导致差异，因为它正在积极尝试交付比仅尝试交付 1 的开发机器更多的请求。

或者可能是因为您正在测试两个不同版本的 IIS，XP 上的 5.1 和 2003 上的 6.0。除非两个环境运行相同的软件，否则真的无法解释差异。

于 2009-02-19T18:24:00.277 回答
0

应用程序是否在两个盒子上以相同的发布配置运行？

编辑：请求管道在 IIS5 和 IIS6 之间发生了巨大变化，trace.axd 只会看到它的 ASP.NET 部分，而不是新的应用程序池和 HTTP.Sys 组件。

我想在 IIS6 上可以稍微调整配置，但您可能正在查看轻量级非生产网络服务器 (IIS5) 和具有单独应用程序池管理和更多抽象层的强大网络服务器的区别。

于 2009-02-19T19:04:16.183 回答