ASYNC_NETWORK_IO待機タイプは心配する必要がありますか？
実行に長い時間がかかるストアドプロシージャのリストを見ると、最も待機時間が長いのが目立ちます。ただし、その待機のほとんど（81％）はASYNC_NETWORK_IOであり、理由はわかっています。ストアドプロシージャは約400 MBの情報を転送します。
ドキュメントでは、ASYNC_NETWORK_IOの原因はクライアントがデータのフラッドに追いつけないことが原因であり、それはおそらく本当であると述べています。クライアントがADO.NETを介してストアドプロシージャを呼び出してから、データセットを処理するだけなので、クライアントを維持する方法がわかりません。
したがって、この情報が与えられた場合、このプロシージャのASYNC_NETWORK_IO待機タイプについて心配する必要がありますか？実際にサーバーのパフォーマンスに影響がありますか？
追加情報：
- SQL Server 2005のService Pack 2を使用しています。
- クライアントアプリはSQL Serverと同じボックスにあります（わかっています、わかっていますが、それについては何もできません）。
先ほど述べたように、この待機タイプは、アプリケーションがSQL Serverに追いついていないことを示しています。これが実際に意味することは、SQL Serverはネットワークを介して必要な速度でデータを送信できないということです。
2つの根本的な原因が考えられます。
- アプリの記述は非効率的で、行の処理速度が不十分です。
- ネットワークがいっぱいです。
アプリケーション自体が遅すぎる場合は、他のクエリのパフォーマンスにまったくまたは大きな影響はありません。一方、パイプが小さすぎる場合、他のクエリも結果を送信できず、待機する必要があります。
ただし、後者の場合は、すべての接続がASYNC_NETWORK_IOで待機することになります。その影響をはっきりと見ることができるはずです。