根据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)我只能访问服务器，并且需要向客户端提供尽可能多的信息，以便他们接受问题不在服务器上，并知道在客户端上运行什么日志/工具来找到根本原因。
答案1
我遇到过这种情况，客户会说：“我于 10:03:24 向您的 Web 服务器发送了一个请求，花了 20 秒，为什么？”我也可以在 IIS 日志中看到这一点，但服务器的 ASP.NET 模块记录它花费了 100 毫秒，并且 CPU 和磁盘计数器很低。
我怀疑这是由于网络连接速度太慢造成的。我该如何证明这一点？
它首先会查找客户端浏览器和全部上述网页的图像 / 脚本 / html 来源。如果您发现持续的数据包丢失，那么您肯定知道网络中存在需要修复的问题……即使只是一个超载的链接。数据包丢失不是网络速度慢的唯一原因，但根据我的经验，它是最常见的原因。其他原因可能是配置错误的代理或缓存引擎。遗憾的是，我无法在此列出所有可能的网络罪魁祸首。
然而，人们经常将网速问题归咎于网络，而事实上网速问题完全在他们自己的控制范围内。可能的解释如下：
- 假设该页面的 HTML 写得很糟糕，并且它以错误的顺序加载所需的脚本，因此整个页面呈现缓慢，即使几乎所有资源都已到位。
- 该页面正在等待根本不存在的资源，并且在等待时超时。
- 脚本处于缓慢循环中，会阻塞一段时间
- 缓存引擎需要很长时间才能传送图像
- 你的 CGI 正在数据库中查找某些内容，而查找本身很慢
- 您正在使用谷歌分析，由于页面的编写方式，速度会变慢
我可以继续说下去，但重点是你必须自己找出页面变慢的确切原因。网络故障是可能的；也有可能是其他因素导致了性能变慢。
进一步诊断：
- 如果页面在 Firefox 中加载良好，则萤火虫是你的朋友（点击F12，然后转到“网络”选项卡并重新加载页面）。Firebug 为你提供了一个漂亮的瀑布图，显示了页面的加载方式以及延迟的位置
- 如果页面在 Chrome 中加载良好，您可以执行类似操作（点击CntlShiftI，单击网络选项卡，然后重新加载页面）。
- 如果页面只支持 IE（顺便说一句，你的 HTML 开发人员太可恶了），你最好的办法是开始单独加载每个 ASP 页面元素，方法是
curl直到你发现某些东西看起来太慢了，然后找出那个特定元素慢的原因。
顺便说一下，Chrome 和 Firefox 示例使用了来自 Debian.org 的 CGI 查询；这是由 CGI 查找引起的延迟的一个很好的例子。
当所有其他方法都失败时，你可以.pcap从wireshark并运行它tcptrace；然而，虽然tcptrace它非常擅长分析数据包转储，但并不能保证您可以tcptrace单独隔离问题。请参阅这个答案有关使用tcptrace诊断程序的信息。
答案2
知识库文章 944884 的结论是，完成响应所需的实际时间可能无法准确反映在日志中。这就是文章提到网络时间的原因。
如果症状可重现，我将在服务器端（最好也在客户端）执行数据包捕获，以查看客户端确认连接的实际时间。
答案3
20 秒的延迟也可能是由于 IIS 必须重新启动其 w3wp.exe 造成的，因为 w3wp.exe 在未使用时会进入睡眠状态。