SQL Server Wait Types – Causes of Async_Network_IO

entity-frameworksql serversql-server-2008

Last week something strange happened on our database. All of a sudden, the application blocked for our users who were not able to save new entities etc. After looking at the Activity Monitor of the SQL Server (2008 with compatibility mode 2005) I saw the following three entries:

async_network_io wait types

After some time, the users got a connection timeout. When I killed the process 64, they could save normally again.

The problem is that the entities they tried to save during the block were inserted into the DB more than once (up to 3 times) even though there is code which should prevent this from happening (number column which has to be unique but without a constraint… the check happens in the code).

We use Entity Framework 6.0.

  • Does anyone of you know why and when these ASYNC_NETWORK_IO wait types occur and how to avoid them?
  • And what exactly do they mean?

Best Answer

ASYNC_NETWORK_IO somehow indicates that the client application isn't processing results as fast as SQL Server feeds them. This could be caused by an issue with the client application or with the network connection between the server and the client application.

Please refer to a post by Thomas LaRock

The ASYNC_NETWORK_IO wait indicates that one of two scenarios are happening. The first scenario is that the session (i.e., SPID) is waiting for the client application to process the result set and send a signal back to SQL Server that it is ready to process more data. The second is that there may be a network performance issue.

or this post by Joe Sack

As you may already be aware, the ASYNC_NETWORK_IO (seen in SQL 2005) and NETWORKIO (seen in SQL 2000) wait types are associated with either a calling application that is not processing results quickly enough from SQL Server or is associated with a network performance issue.

Since you are using entity framework this post by Brent Ozar may be useful too

Looking at the wait stats for these queries, I saw there was a lot of ASYNC_NETWORK_IO — often 1000+ milliseconds. That didn’t make any sense either! How can a query with so little CPU time and so few reads take so long to complete? It’s not like the application was asking for millions of rows and couldn’t consume the results fast enough.

Related Question