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


9
2017-07-30 07:59




这些请求是否需要获取嵌入图形等的正常页面视图?或者它们是仅返回单个页面的自动查询?我们实际上是在测量加载页面的时间还是响应单个HTTP请求的时间? - David Schwartz


答案:


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

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

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

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

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

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

进一步诊断:

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

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

当所有其他方法都失败时,你可以得到一个 .pcap 从 Wireshark的 并运行它 tcptrace;然而,同时 tcptrace 非常擅长分析数据包转储,无法保证您可以将问题与之隔离开来 tcptrace 单独。看到 这个答案 有关使用的信息 tcptrace 诊断。


3
2017-07-30 10:13



请参阅上面的更新。虽然您的信息在一般情况下非常有用,但我认为这不适用于此。该页面只是间歇性地缓慢,并且当我在客户端节流网络时,症状只能重现。 - Jon
firefox / chrome中的瀑布图表支持http post操作,以及curl ...我不确定你如何得出结论信息不适用,但似乎它不涉及针对问题域的工具的完整应用。 - Mike Pennington
Firefox / chrome是客户端工具。我只能访问服务器,我无法使用自己的客户端进行重新调用。我只需要从服务器告诉我,由于网络问题,特定请求是否很慢。这会留下数据包捕获,但这太重了,不能在生产中留下(考虑10,000个请求中的1个可能会很慢)。 - Jon
作为一名拥有超过15年经验的网络工程师,我可以尊重地建议您不能仅从服务器诊断客户端HTTP服务问题;你根本就没有足够的信息(这显然也是你的结论......但是,你似乎并不愿意接受这个现实:-)。 - Mike Pennington
如果服务器上的数据包捕获可以诊断网络问题(例如,通过看到缓慢的TCP确认),那么期望轻量级工具/记录器可以显示相同的情况是不合理的吗? - Jon


kb文章944884的结果是完成响应所需的实际时间可能无法准确地反映在日志中。这就是文章提到网络时间的原因。

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


0
2017-07-30 12:49



谢谢,但除了通过限制网络速度之外,它不具有可再现性,并且数据包捕获太重,无法在生产中使用。 - Jon


还有20秒延迟也可能是因为IIS必须重新启动它的w3wp.exe,它将在未使用时进入休眠状态。


0
2018-05-20 15:13



您可以通过回答“如何辨别”来改进这个答案。 w3wp.exe进入睡眠与我的情况无关,因为我已禁用该行为,但这可以帮助其他人。 - Jon