IIS：如何判断时间是否缓慢是由于网络连接速度慢

根据http://support.microsoft.com/kb/944884，“当通过慢速网络连接将较大的响应或较大的响应发送到客户端时，花费的时间字段的值可能会超出预期”。

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

我怀疑这是由于网络连接速度慢所致。我如何证明这一点？

更新：

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

2）另外，我通过限制客户端的网络速度来重现此错误，并且症状完全相同。

3）问题是断断续续的，这意味着相同的请求通常对于客户端来说是很快的，但有时却很慢。我只能通过限制网络来复制自己的内容。服务器的ASP.NET日志记录始终显示为快速，而客户端说的很慢时，IIS日志记录显示为慢。

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

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

我怀疑这是由于网络连接速度慢所致。我如何证明这一点？

首先从寻找客户端浏览器和上述网页的所有图像/脚本/ html源之间的数据包丢失开始。如果您发现一致的数据包丢弃，那么您可以肯定地知道网络中有些东西需要修复……即使它只是一条链路过载。数据包丢失不是网络速度慢的唯一原因，但这是我的经验中最常见的来源。其他来源可能是配置错误的代理或缓存引擎。可悲的是，我无法在此处列出所有可能的网络罪魁祸首。

但是，人们通常会把责任归咎于网络，而实际上速度问题是在他们自己的控制范围之内的。可能的解释：

• 假设该页面的HTML编写不正确，并且以错误的顺序加载了所需的脚本，因此即使几乎所有资源都就位，整个页面的渲染也很慢。
• 页面正在等待的资源根本不存在，并且在等待时超时。
• 脚本处于缓慢的循环状态，可能会阻塞一段时间
• 缓存引擎需要很长时间才能传递图像
• 您的CGI正在数据库中查找内容，查找本身很慢
• 您正在使用Google Analytics（分析），这会由于页面的编写方式而减慢速度

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

要进一步诊断：

• 如果页面在Firefox中加载良好，则Firebug中的“网络”选项卡是您的朋友（点击F12，然后转到“网络”选项卡并重新加载页面）。Firebug为您提供了一个漂亮的瀑布图，用于说明页面的加载方式以及延迟的位置
• 如果页面在Chrome中的加载效果很好，则可以执行类似的操作（点击CntlShiftI，点击“网络”标签，然后重新加载页面）。
• 如果该页面仅在IE中受支持（顺便说一句，您的HTML开发人员感到羞耻），最好的选择是开始逐个加载这些ASP页面元素，curl直到您发现看上去太慢的东西，然后找出为什么该特定元素是缓慢的。

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

当所有其他方法都失败时，您可以.pcap从wireshark获取一个a 并将其运行tcptrace；但是，尽管tcptrace非常擅长分析数据包转储，但不能保证可以tcptrace单独解决问题。有关使用诊断的信息，请参见此答案tcptrace。

知识库文章944884的结果是，完成响应所需的实际时间可能未准确反映在日志中。这就是为什么文章提到网络时间。

如果症状是可重现的，我将在服务器端（最好也是客户端）执行数据包捕获，以查看客户端确认连接的实际时间。

20秒的延迟也可能是由于IIS必须重新启动w3wp.exe而导致的，该w3wp.exe在不使用时将进入睡眠状态。