web-dev-qa-db-ja.com

IIS：時間のかかる原因がネットワーク接続の速度の低下によるものかどうかを確認する方法

http://support.Microsoft.com/kb/944884 によると、「1つまたは複数の大きな応答が低速のネットワーク接続を介してクライアントに送信されると、所要時間フィールドの値予想を超える可能性があります。」.

「10:03:24にリクエストをWebサーバーに送信しましたが、20秒かかりましたが、なぜですか？」とクライアントが言う状況があります。これはIISログでも確認できますが、サーバーのASP.NETモジュールが100msと記録し、CPUとディスクのカウンターが低くなりました。

ネットワーク接続が遅いことが原因だと思います。どうすればこれを証明できますか？

更新：

1）これらはSOAP Webサービス要求であるため、埋め込まれたグラフィックスではなく、結果の単一のXMLページを持つHTTP POSTです。

2）また、クライアント側でネットワーク速度を調整してこれを再現しましたが、症状はまったく同じです。

3）問題は断続的です。つまり、同じ要求は通常クライアントでは高速ですが、場合によっては低速です。これを自分で再現するには、ネットワークを調整する必要があります。サーバーのASP.NETログでは常に高速であることが示されますが、クライアントが低速であるとIISのログでは低速と示されます。

4）私はサーバーにしかアクセスできず、クライアントにできるだけ多くの情報を提供して、問題がサーバー上にないことを受け入れ、根本原因を見つけるためにクライアントで実行するロギング/ツールを知っている必要があります。

windowsnetworkingiisperformanceiis-7.5
10
Jon

「10:03:24にWebサーバーにリクエストを送信しましたが、20秒かかりましたが、なぜですか？」とクライアントが言う状況があります。これはIISログでも確認できますが、サーバーのASP.NETモジュールが100msと記録し、CPUとディスクのカウンターが低かったです。

ネットワーク接続が遅いことが原因だと思います。どうすればこれを証明できますか？

まず、クライアントのブラウザーと前述のWebページの画像/スクリプト/ htmlのソースallの間のパケットドロップを探します。一貫したパケットドロップが見つかった場合は、ネットワーク内に修正が必要な何かがあることは確かです。それが単なる過負荷のリンクであってもです。パケットドロップが遅いネットワークの唯一の理由ではありませんが、これは私の経験では最も一般的な原因です。他のソースは、誤って構成されたプロキシまたはキャッシュエンジンである可能性があります。悲しいことに、私はここにすべての可能なネットワーク犯人をリストすることはできません。

ただし、速度の問題が実際には自分の管理の範囲内にある場合、人々はネットワークを非難することがよくあります。考えられる説明：

  • そのページのHTMLが適切に記述されておらず、必要なスクリプトが間違った順序で読み込まれるため、ほとんどすべてのリソースが配置されていても、ページ全体のレンダリングが遅くなります。
  • ページは、単に存在しないリソースを待機しており、待機中にタイムアウトします。
  • スクリプトが遅いループにあり、しばらくブロックしています
  • キャッシュエンジンが画像の配信に長時間かかる
  • CGIがデータベースで何かを検索していて、検索自体が遅い
  • google analytics を使用しているため、ページの記述方法が原因で速度が低下している

私は続けることができますが、要点は、ページが遅い理由を正確に突き止める必要があるということです。ネットワークに欠陥がある可能性があります。他の要因がパフォーマンスの低下の一因となっている可能性もあります。

さらに診断するには：

  • Firefoxでページが適切に読み込まれる場合、 Firebug の[ネットワーク]タブが友だちです（ヒット F12、[ネットワーク]タブに移動し、ページを再読み込みします）。 Firebugは、ページがどのようにロードされ、どこに遅延があるかを示す素晴らしいウォーターフォール図を提供します Firebug waterfall
  • Chromeでページが適切に読み込まれる場合は、同様のことができます（ヒット CntlShiftI、[ネットワーク]タブをクリックし、ページを再読み込みします）。 Chrome
  • ページがIE（HTML開発者にとっては残念）でのみサポートされている）場合、最善の策は、これらの各ASPページ要素を個別にロードすることです。 curl を使用して、非常に遅く見えるものが見つかるまで、その特定の要素が遅い理由を見つけます。

ところで、ChromeおよびFirefoxの例では Debian.orgからのCGIクエリ を使用しました;これはCGIルックアップによる遅延の良い例です。

他のすべてが失敗した場合、.pcap from wireshark そしてそれを実行 tcptrace ;ただし、tcptraceはパケットダンプの分析に優れていますが、tcptraceだけで問題を特定できるという保証はありません。 tcptrace診断の使用については、 この回答 を参照してください。

4
Mike Pennington

KB記事944884の要点は、応答を完了するために必要な実際の時間が正確にログに反映されない可能性があるということです。そのため、この記事ではネットワーク時間について言及しています。

症状が再現可能な場合は、サーバー側（できればクライアント側も同様）でパケットキャプチャを実行して、クライアントが接続を確認した実際の時間を確認します。

0
Greg Askew

20秒の遅延は、IISを再起動する必要があるため、未使用時にスリープ状態になるw3wp.exeによっても発生する可能性があります。

0
Steve Rollins