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

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

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

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

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

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

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

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

さらに診断するには：

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

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

他のすべてが失敗した場合、wireshark.pcapからを取得してを実行できます。ただし、パケットダンプの分析は非常に得意ですが、単独で問題を特定できる保証はありません。診断の使用については、この回答を参照してください。tcptracetcptracetcptracetcptrace

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

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

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