服务器 Gind.cn
  1. 服务器 Gind.cn
  3. IIS：如何判断缓慢的时间是否由于networking连接速度较慢
Intereting Posts
在Samba服务器上的Windows 7 x64中设置“打印”设置 为什么在尝试获取服务器状态时遇到404 Not Found？ 在确认主机/服务时，什么是check_mk粘滞注释？ 内置帐户操作员和“用户无法更改密码”属性 确定CRON未运行的问题 如何在可用磁盘空间上创build警报策略，仅在根文件系统上创build Windows NFS性能与Windows文件共享？ Sharepoint 2010 – “我们没有find任何关于”关键字的结果 如何select文件的date范围并将其归档？ 全局拒绝Apache上的某些文件 Linux iptables根据mac地址丢弃stream量 在DC上运行TS（RDP）是一个非常糟糕的主意？ KVM网卡我可以在哪里看到eth编号？ 使用超过50％的CPU的LSASS.exe停止Active Directory服务器 什么是广域网知识产权相关的静态IP租约？

IIS：如何判断缓慢的时间是否由于networking连接速度较慢

根据http://support.microsoft.com/kb/944884 ，“当通过较慢的networking连接向客户端发送大型响应或大型响应时，所需时间字段的值可能会高于预期值”。

我有一个情况，客户会说：“我在10:03:24发送了一个请求到你的web服务器，花了20秒，为什么？”。 我也可以在IIS日志中看到这一点，但服务器的ASP.NET模块将其logging为100ms，CPU和磁盘计数器为低。

我怀疑这是由于networking连接速度缓慢。 我怎样才能certificate这一点？

更新：

1）这些是SOAP Web服务请求，因此没有embedded的graphics，只有一个带有单个XML页面结果的HTTP POST。

2）另外，我已经通过在客户端节制networking速度来再现这一点，症状也完全一样。

3）问题是间歇性的，这意味着对于客户端而言相同的请求通常是快速的，但是偶尔会很慢。 除了通过限制networking之外，我不能再现这个。 服务器的ASP.NET日志logging显示它总是很快，但是当客户端说速度很慢时，IIS日志logging显示它很慢。

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

我有一个情况，客户会说：“我在10:03:24发送了一个请求到你的web服务器，花了20秒，为什么？”。 我也可以在IIS日志中看到这一点，但服务器的ASP.NET模块将其logging为100ms，CPU和磁盘计数器为低。

我怀疑这是由于networking连接速度缓慢。 我怎样才能certificate这一点？

它开始寻找客户端的浏览器和上述网页的图像/脚本/ html的所有来源之间的数据包丢失。 如果发现一致的数据包丢失，那么您肯定知道networking中有某些东西需要修复，即使它只是一个超载的链接。 数据包丢失不是缓慢networking的唯一原因，但是这是我的经验中最常见的来源。 其他来源可能是错误configuration的代理或caching引擎。 可悲的是，我无法列出所有可能的networking肇事者。

然而，当事实上速度问题在他们自己的控制范围内时，人们往往会责怪networking。 可能的解释：

  • 假设该页面的HTML编写得很差，并且以错误的顺序加载了所需的脚本，所以整个页面渲染缓慢，即使几乎所有的资源都在原地。
  • 该页面正在等待一个根本不存在的资源，并在等待时超时。
  • 脚本处于一个缓慢的循环中，阻塞一段时间
  • caching引擎需要很长时间才能传送图像
  • 你的CGI正在查找数据库中的东西，查找本身很慢
  • 你正在使用谷歌分析 ，这减慢了由于页面的写入方式

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

进一步诊断：

  • 如果页面在Firefox中正常加载，那么Firebug中的networking标签是你的朋友（点击F12 ，然后转到networking标签并重新加载页面）。 Firebug为您提供了一个不错的瀑布图，展示了页面加载的方式以及延迟的位置 Firebug瀑布
  • 如果页面在Chrome中正常加载，您可以做类似的事情（点击Cntl Shift I ，点击networking标签，然后重新加载页面）。 铬
  • 如果页面只支持IE浏览器（顺便说一句，你的HTML开发人员感到羞耻），最好的办法是用curl逐个加载这些ASP页面元素，直到find看起来太慢的东西，然后找出为什么元素很慢。

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

当所有其他的失败，你可以从wireshark获得一个.pcap并通过tcptrace运行; 但是，虽然tcptrace非常擅长分析数据包转储，但不能保证tcptrace单独使用tcptrace来解决问题。 有关使用tcptrace诊断的信息，请参阅此答案 。

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

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

20秒的延迟也可能是由于IIS不得不重新启动它的w3wp.exe而导致的，它将在未使用时进入hibernate状态。