Why do async_network_io wait types occur? 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:



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?
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.