In looking at the list of stored procedures that take long time to execute, one stands out as causing the most wait. However, most of that wait (81%) is ASYNC_NETWORK_IO and I know why: the stored procedure transfers roughly 400 MB of information.
In the documentation, it states that the cause of ASYNC_NETWORK_IO is that the client can’t keep up with the flood of data and that is probably true. I am not sure how to make the client keep up since all it does is call the stored procedure via an ADO.NET and then just processes the dataset.
So given this information, should I worry about the ASYNC_NETWORK_IO wait type for this procedure? Does it actually have an effect on the server performance?
Additional pieces of information:
- I am on service pack 2 of SQL Server 2005.
- The client app is on the same box as SQL Server (I know, i know…but I can’t do anything about it).
As you said, this wait type indicates that the application is not keeping up with SQL Server. Now what that really means is, that SQL Server can’t send the data over the network as fast as it would like.
There can be two underlying causes:
- The app is written inefficiently and does not process the rows fast enough.
- The network is maxed out.
If the application itself is too slow there will be no or no significant impact on the performance of other queries. If on the other hand the pipe is too small, other queries can’t send their results either and have to wait.
In the latter case however you would have all connections waiting on ASYNC_NETWORK_IO. You should be able to see that impact clearly.