ASYNC_NETWORK_IO待機タイプは心配することはありますか？

実行に長い時間がかかるストアドプロシージャのリストを見ると、待機時間が最も多いことが際立っています。ただし、その待機時間のほとんど（81％）はASYNC_NETWORK_IOであり、その理由はわかっています。ストアドプロシージャは約400 MBの情報を転送します。

ドキュメントでは、ASYNC_NETWORK_IOの原因は、クライアントがデータのフラッドに追いつくことができないことであり、それはおそらく真実であると述べています。クライアントがADO.NET経由でストアドプロシージャを呼び出してからデータセットを処理するだけなので、クライアントを維持する方法がわかりません。

したがって、この情報が与えられた場合、この手順のASYNC_NETWORK_IO待機タイプについて心配する必要がありますか？実際にサーバーのパフォーマンスに影響しますか？

追加情報：

• SQL Server 2005のサービスパック2を使用しています。
• クライアントアプリは、SQL Serverと同じボックス上にあります（私は知っています...知っていますが、それについては何もできません）。

前述のように、この待機タイプは、アプリケーションがSQL Serverに追いついていないことを示します。これが本当に意味するのは、SQL Serverがネットワーク経由でデータを必要な速度で送信できないことです。

2つの根本的な原因が考えられます。

1. アプリは非効率的に記述されており、行を十分に高速に処理しません。
2. ネットワークが限界に達しました。

アプリケーション自体が遅すぎる場合、他のクエリのパフォーマンスに大きな影響はないか、まったく影響しません。一方、パイプが小さすぎる場合、他のクエリも結果を送信できず、待機する必要があります。

ただし、後者の場合、すべての接続がASYNC_NETWORK_IOで待機します。その影響を明確に確認できるはずです。