What to make of the ASYNC NETWORK IO wait type?

You’ve seen this wait type before, haven’t you? Well, it is certainly a wait type that has caused lots of confusion. The immediate focus is generally given to the word “NETWORK” but more times than not it has nothing to do with the network!
The ASYNC_NETWORK_IO wait type will typically yield two types of symptoms, the first being session workload is waiting for the corresponding client application to acknowledge/process a given set of data and let SQL Server know it is ready to process/acknowledge more data. The second symptom is that there may be a performance issue in the network between the application and database instance.Behind the scenes, SQL Server keeps the data held in an output buffer until an acknowledgement is received from the client determining whether the consumption of data is complete. ASYNC_NETWORK_IO is a tell-tale sign that the application lacks efficiency in reading data it requires from its backend database. The underlying network may also have issues which can produce lengthier waits while data is processed, and signals are being sent back from the client to the server.

Possible causes for this wait include:

• Application code not retrieving data correctly
• Large data sets being requested by the client
• Excessing filtering of data occurring on client or application side
• Poorly configured network devices such as cards, switches, etc.

At a high level, a DBA may want to check on these things:

• Review application code and ensure application is reading data correctly/efficiently. For instance, is your application pulling back a large number of rows only to process one row at a time? 
• Unnecessary data-filtering at the client/application side? Limit the rows.

If the above items check out, but the issues with ASYNC_NETWORK_IO remain, this it may be due to the network.  Here are some things you can look into:

• Inspect the network communication link between the application and backend database instance and verify the bandwidth.
• Use the sys.dm_io_virtual_file_stats to test the network for general latency due to load or distance
• Examine the NIC configuration on the database server to ensure no faults and/or settings are missing.

The ASYNC_NETWORK_IO WAIT TYPE might indeed be a network related issue, but often it may be due to a client application that is not processing its data efficiently.  If the latter is indeed the case, then this is an opportunity for DBAS and Developers to work together to understand what the application truly needs in the best interests of the back-end database’s performance.  Ensuring that most data filtering is done within SQL Server is a best practice which can be achieved through views or more specific where conditions in the transaction syntax.

Although there are many ways to monitor and measure the ASYNC_NETWORK_IO wait through the use of catalogued DMVs and Extended Events in SQL Server, we encourage our community of SQL Server DBAs to look at Quest’s Spotlight Cloud which provide efficiency in determining the root cause of wait type consumption over a historical period of time.