Did you ever face any scenario where you found no issues in CPU, memory, Disk IO or network, still some users are facing slow response and SQL Server has high ASYNC_NETWORK_IO wait type? At first glance, it may seem like SQL Server is the problem—but in reality, this wait type usually points outside the database engine. It occurs when SQL Server has results ready to send, but the client application (or the network in between) cannot consume the data fast enough. This may result-in query slowness, blocked sessions, and frustrated users.
In this article you will walk through what ASYNC_NETWORK_IO is when it occurs, simulate it and share some techniques to reduce them. Let's start.
Figure-1: ASYNC_NETWORK_IO Wait
ASYNC_NETWORK_IO
Historically, ASYNC_NETWORK_IO first shipped with SQL Server 2000 version. Initially, it was called NETWORKIO. From SQL Server 2005, it was renamed as ASYNC_NETWORK_IO. As initial name suggests, it was related to slow network IO. Especially, when an application demands a large data set from SQL Server over network, SQL Server prepares the data and put it in a buffer. Then the client application fetch it from the buffer. If the data is not fetched or there is any lag in data fetching, SQL Server will wait for acknowledgment from client side before sending more results and mark this wait type as ASYNC_NETWORK_IO.
Impact of ASYNC_NETWORK_IO
Excessive amount of ASYNC_NETWORK_IO has negative impact on your workload and may reduce overall performance as:
- Client applications fetch data slowly so overall query execution time will be increased.
- SQL Server holds allocated locks on resources longer which prevents other queries to acquire those resources. Result-in locking, blocking or even deadlocking.
Simulation of ASYNC_NETWORK_IO
We will use free tools like SQLQueryStress and Clumsy to simulate ASYNC_NETWORK_IO wait type. Download both tools and run them as per their instructions. In this simulation, client application will fetch large dataset frequently and there will be network lag and packet loss so that client application cannot receive dataset timely.
- SQLQueryStress (client application) will be used to generate stress on SQL Server by running below query repeatedly which will fetch large dataset.
- Clumsy (network disruption tool) will be used to simulate network disruption like lag, packet loss etc.
Combination of both tools will ultimately produce our expected ASYNC_NETWORK_IO wait type.
Put Query Snippet-1 in SQLQueryStress query window and run on AdventureWorks2022 database. Press GO button as shown in Figure-2.
SELECT * FROM [Person].[Person]
-- Query Snippet-1
Figure-2: Running simulated query in SQLQueryStress
Now run Clumsy as Administrator and configure and run it as shown in Figure-3 to simulate network lag.
Figure-3: Running Clumsy for simulating network lag
In SSMS, now execute Query Snippet-2 for gathering ASYNC_NETWORK_IO wait type data as shown in Figure-4.
SELECT wt.session_id, wt.wait_type, wt.wait_duration_ms, wt.resource_description,
r.command, r.database_id, DB_NAME(r.database_id) AS DbName,
r.blocking_session_id
FROM sys.dm_os_waiting_tasks wt
JOIN sys.dm_exec_requests r ON wt.session_id = r.session_id
WHERE wt.wait_type = 'ASYNC_NETWORK_IO'
ORDER BY wt.wait_duration_ms DESC
-- Query Snippet-2
Figure-4: ASYNC_NETWORK_IO wait type
Causes and Resolutions of ASYNC_NETWORK_IO
ASYNC_NETWORK_IO occurs when client side process data slower than SQL Server throws to them. This slowness could be for many reasons. Mostly,
Large Dataset
When a client application requests for large dataset which transmit over network, due to network latency this wait type likely to occur. You should pay attention to:
- Client applications fetch huge data then process the results by applying filters, sorting, and aggregations.
- Using slow VPN connectivity.
- Applications like Microsoft Access or ORM software may request the large datasets.
- Even pulling large data using ad hoc query via SSMS.
Resolution
- Process data in a balancing way between SQL Server and clients. Use proper TOP, WHERE clause, Aggregate functions to make the result set small. In client side, do further computations on the data, presentation and formatting which will distribute the load.
- Check network connectivity between client and SQL Server. Analyze your network performance.
- Check what query is actually arrives from application side specially when you are using ORM.
- Use NOLOCK hints (where applicable) in case you pull large result sets for ad hoc purpose.
Applications Processing Data at Their Own Pace
If application process data slowly and does not acknowledge SQL Server timely about data receipt, in that case ASYNC_NETWORK_IO may occur. For example, SqlDataReader of ADO.net fetch data row by row. So, using SqlDataReader if an app process row one by one and wait for an user input or write to disk or do another network IO. There will be ASYNC_NETWORK_IO.
Resolution
Adjust the application logic like fetch all the data together, store it application side memory then go for processing.
Busy Application Servers
Application will consume data slowly if the application server is in stress like CPU is rocketed, memory is exhausted or slow Disk IO. In either case, ASYNC_NETWORK_IO will occur due to slow processing of data.
Resolution
Check which process is creating resource scarcity in application server. It is better to allocate dedicated server for application. In case of hardware constraints optimize them. If it is required, optimize the application also.
Network Issues
Slow network will lead to ASYNC_NETWORK_IO wait and do real damage to your SQL Server. Keep an eye on below stuffs:
- Analyze your network performance.
- Monitor the bandwidth between client and your database server. Based on your requirements, use gigabit network adapters.
- Check configurations of all networks equipments such as routers, switches, cables, network adapters etc.
- Examine the Batch requests per second counter values.
- Batch Requests per second > 1000 is considered as busy system.
- Batch requests per second > 3,000 and 100 Mbps bandwidth indicates network speed is the bottleneck and leads to high ASYNC_NETWORK_IO waits values.
Final Words
The ASYNC_NETWORK_IO wait type is not always a SQL Server problem—it is often a sign that something downstream, like the application, client, or network, is struggling to consume data efficiently. As DBAs, our role is to identify whether the slowdown is inside SQL Server or outside of it, and then work with developers and infrastructure teams to address the real root cause. By applying the right monitoring, analyzing client-side behavior, and ensuring efficient query design, you can reduce this wait type and deliver faster, smoother performance for end users.
References
Going Further
If SQL Server is your thing and you enjoy learning real-world tips, tricks, and performance hacks—you are going to love my training sessions too!
Need results fast? I am also available for 1-on-1 consultancy to help you troubleshoot and fix your database performance issues.
Let’s make your SQL Server to take your business Challenge!
For any queries, mail to mamehedi.hasan[at]gmail.com.