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

根据 http://support.microsoft.com/kb/944884,“当通过慢速网络连接向客户端发送大响应或大响应时,时间字段的值可能超过预期”.

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

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

更新：

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

2)另外,我通过在客户端限制网络速度来重现这一点,并且症状完全相同.

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

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

I have a situation where a client will say,“I sent a request to your web server at 10:03:24 and it took 20 seconds,why?”. I can see this in the IIS logs as well,but the server’s ASP.NET module logged it as taking 100ms,and CPU and Disk counters were low.

I suspect that it’s due to a slow network connection. How can I prove this?

首先查找客户端浏览器与上述网页的所有图像/脚本/ html源之间的数据包丢弃.如果您发现一致的数据包丢失,那么您肯定知道网络中有某些东西需要修复…即使它只是一个超载的链接.丢包不是网络速度慢的唯一原因,但它是我体验中最常见的来源.其他来源可能是配置错误的代理或缓存引擎.可悲的是,我无法列出所有可能的网络罪魁祸首.

然而,人们常常责怪网络,事实上速度问题完全在他们自己的控制之内.可能的解释：

>假设该页面的HTML编写得很糟糕,并且它以错误的顺序加载所需的脚本,因此整个页面渲染速度很慢,即使几乎所有资源都是就地的.
>页面正在等待一个根本不存在的资源,并在等待时超时.
>脚本处于慢速循环中,会阻塞一段时间
>缓存引擎需要很长时间才能传送图像
>您的CGI正在查找数据库中的某些内容,并且查找本身很慢
>您正在使用google analytics,由于页面的编写方式,它会减慢速度

我可以继续,但重点是你必须确定页面为什么慢慢的确切原因.一个有缺陷的网络是可能的;其他因素也可能导致性能下降.

进一步诊断：

>如果页面在Firefox中加载良好,则Firebug中的“网络”选项卡是您的朋友(按F12,然后转到“网络”选项卡并重新加载页面). Firebug为您提供了一个很好的瀑布图,用于显示页面加载方式和延迟时间
>如果页面在Chrome中加载良好,您可以执行类似操作(点击CntlShiftI,单击网络选项卡,然后重新加载页面).
>如果页面仅在IE中支持(顺便说一下,HTML开发人员的羞耻感),最好的办法就是用curl开始单独加载每个ASP页面元素,直到找到看起来太慢的东西,然后找出原因.特殊元素很慢.

顺便说一下,Chrome和Firefox的例子使用的是CGI query from Debian.org;这是来自CGI查找的延迟的一个很好的例子.

当所有其他方法都失败时,你可以从wireshark获得一个.pcap并运行到tcptrace;但是,虽然tcptrace非常擅长分析数据包转储,但无法保证您可以单独使用tcptrace来解决问题.有关使用tcptrace诊断的信息,请参阅this answer.

（编辑：ASP站长网）