IIS：如何判断缓慢的时间是否是由于网络连接缓慢造成的

Question

根据http://support.microsoft.com/kb/944884 的说法，“当一个或多个大型响应通过慢速网络连接发送到客户端时，time-taken 字段的值可能会超过预期”。

我遇到过这样的情况，客户会说，“我在 10:03:24 向您的 Web 服务器发送了一个请求，花了 20 秒，为什么？”。我也可以在 IIS 日志中看到这一点，但是服务器的 ASP.NET 模块将其记录为耗时 100 毫秒，并且 CPU 和磁盘计数器很低。

我怀疑这是由于网络连接速度慢。我怎样才能证明这一点？

更新：

1) 这些是 SOAP Web 服务请求，因此没有嵌入图形，只是带有单个 XML 结果页面的 HTTP POST。

2）另外，我已经通过在客户端限制网络速度来重现这一点，并且症状完全相同。

3) 问题是间歇性的，这意味着客户端的相同请求通常很快，但偶尔会很慢。除了限制网络之外，我自己无法重现这一点。服务器的 ASP.NET 日志显示它总是很快，但是当客户端说它很慢时，IIS 日志显示它很慢。

4）我只能访问服务器，并且需要向客户端提供尽可能多的信息，以便他们接受问题不在服务器上并知道在客户端上运行哪些日志记录/工具以查找根本原因。

Answer 1

我遇到过这样的情况，客户会说：“我在 10:03:24 向您的 Web 服务器发送了一个请求，花了 20 秒，为什么？”。我也可以在 IIS 日志中看到这一点，但服务器的 ASP.NET 模块将其记录为花费 100 毫秒，并且 CPU 和磁盘计数器很低。

我怀疑这是由于网络连接速度慢造成的。我怎样才能证明这一点？

首先寻找客户端浏览器与上述网页的所有图像/脚本/html 源之间的数据包丢失。如果您发现一致的数据包丢失，那么您肯定知道网络中存在需要修复的问题......即使它只是一个过载的链路。丢包并不是网络缓慢的唯一原因，但根据我的经验，这是最常见的原因。其他来源可能是配置错误的代理或缓存引擎。遗憾的是，我无法在这里列出所有可能的网络罪魁祸首。

然而，人们经常指责网络，而事实上速度问题完全在他们自己的控制范围内。可能的解释：

• 假设该页面的 HTML 编写得不好，并且以错误的顺序加载所需的脚本，因此整个页面呈现缓慢，即使几乎所有资源都就位。
• 该页面正在等待一个根本不存在的资源，并且在等待过程中超时。
• 脚本处于缓慢循环中，会阻塞一段时间
• 缓存引擎需要很长时间才能传递图像
• 您的 CGI 正在数据库中查找某些内容，并且查找本身很慢
• 您正在使用谷歌分析，由于页面的编写方式，它会减慢速度

我可以继续说下去，但重点是您必须自己确定页面缓慢的确切原因。网络可能存在缺陷；也可能有其他因素导致性能缓慢。

进一步诊断：

• 如果页面在 Firefox 中加载良好，那么Firebug中的“网络”选项卡就是您的朋友（点击F12，然后转到“网络”选项卡并重新加载页面）。Firebug 为您提供了一个漂亮的瀑布图，显示页面如何加载以及延迟在哪里
• 如果页面在 Chrome 中加载良好，您可以执行类似的操作（点击CntlShiftI，单击网络选项卡，然后重新加载页面）。
• 如果该页面仅在 IE 中受支持（顺便说一句，这对您的 HTML 开发人员来说是耻辱），那么您最好的选择是开始单独加载每个 ASP 页面元素，curl直到您发现某些看起来太慢的内容，然后找出该特定元素的原因是慢的。

顺便说一句，Chrome 和 Firefox 示例使用了来自 Debian.org 的 CGI 查询；这是 CGI 查找造成的延迟的一个很好的例子。

.pcap当所有其他方法都失败时，您可以从wireshark获取并运行它tcptrace；然而，虽然tcptrace它非常擅长分析数据包转储，但不能保证您可以tcptrace单独隔离问题。有关使用诊断的信息，请参阅此答案tcptrace。