web-dev-qa-db-ja.com

IISの "SendResponse"状態のリクエストが長時間スタックしました。遅いIIS 7.5 / ASP.NET 4.0 Webアプリケーション

Windows Server 2008 R2およびIIS 7.5。

問題：リクエストの処理に非常に長い時間がかかる場合があります。ユーザーはブラウザが回転しているように見え、明らかにIISから応答がありません。

いくつかの統計と解決の試み：

  • サーバー（ホストとVM）の負荷は無視できます。 CPUが5％を超えることはなく、10 GB以上のRAM=が使用可能です。すべてがMPIO経由で高速SANに接続されています。
  • 1秒あたり30から50のリクエストがあり、動的コンテンツと静的コンテンツが混在していますが、GETとPOSTのみです。ほとんどのヒットはキャッシュされる（ヒット率80％）ので、ファブリック/ SAN/IOの負荷はほとんどありません。
  • ホストと仮想マシンのTCPオフロードは、ネットワークアダプターと無効化の両方で無効化されていますTCP Chimney
  • WebアプリケーションはASP.NET 4.0統合モードで実行されています。サードパーティのWebサービスなどに長時間の呼び出しを行うことはありません。
  • 私は、processModel autoConfigと、maxWorkerThreads、maxConnections、maxIOThreadsなどを非常に高い数値に設定して、違いがないことを試しました。
  • データベースクエリはすべて1秒未満で完了しています。私は丸一日プロファイリングを行い、時間がかかる単一のクエリをキャプチャしませんでした。
  • 大量のパフォーマンスモニターカウンターを見てきました。 ASP.NETキューとアプリケーションキューは常に空であり、何もキューに入れられていないように見えます（サーバーがまったく汗をかいていないことを考えると、とにかく意味がありません）。
  • IISの「SendResponse」ステージでリクエストが20〜60秒間「スタック」することがあるappcmd listリクエストを使用して特定しました。これまでに見つけた唯一のことで、意味のあることです。移動中にユーザーが動けなくなる理由について。ただし、ほとんどのリクエストは高速に処理されていることに注意してください。異なるアプリケーションプールからのランダムなリクエストがここでスタックしているように見えます。

他に何を見ることができますか？ IISの 'SendResponse'ステージでリクエストがスタックする原因は何ですか？

iisasp.netiis-7.5requestresponse-time
7
ALA

これに対する解決策を見つけましたか？ JS、PNG、GIFなどの静的コンテンツが「IIS Webコア」モジュールの「SendResponse」状態でスタックしている今、かなり同じことを定期的に目にしています。私はIIS 7/ASP.NET 4.0で同じ状況にあります。私はこれらをappcmdではなく このMicrosoft.Web.Administrationコード で監視しています。

更新：さらなる調査の結果、私が思いついた可能性の1つは、ネットワーク接続が切断されている可能性があることです。 このスレッド で、人は彼のIISログで、Win32ステータスコード1236を報告します。これは、「ネットワーク接続がローカルシステムによって中止されました」です。） mただし、これがリクエスターがリクエストをキャンセルしたか、Webサーバーがリクエストを中止したかはわかりません。おそらく、リクエスターは、ページコンテンツ（画像、JSなど）に対するすべてのHTTPリクエストが完了する前に、サイトの別のページに移動する可能性があります。これはおそらく、Webサーバーへのすべての保留中の要求を中止します（つまり、ページが最初に表示されたときに、ページ上のリンクをクリックします）私のIISログにいくつかの1236 Win32ステータスコードが見つかりました（ほとんどがGIF、PNG、JSなどの静的コンテンツで、そのうちのいくつかはASPXページに関連付けられています）ただし、これらが「SendResponse」状態でスタックしているのと同じリクエストかどうかはわかりません。

2
Ben Amada

これは通常、モバイルデバイスが低速のデータ接続で大きなアセットファイルをダウンロードしていることが原因です。 「大」と言うときは、接続の速度を基準にしています。

リクエストは「ハング」しているのではなく、ユーザーのネットワーク速度に依存しているため、時間がかかっているだけです。ユーザーが切断した場合、リクエストはダンプされるため、おそらくページのロードを辛抱強く待っています。

「ハンギング」リクエストの横にリストされているIPを確認して調べてみてください。おそらく、それらは携帯電話事業者に属していることがわかります。

2
greg84