April 28, 2009 at 8:42 am
I'm seeing a lot to ASYNC_NETWORK_IO is activity monitor.
I know this related to the network or client being slow. The network seems fine based on the looking at the following Network Interface counters:
Current BandWidth = 10,000,000
Output Queue Length = 0
Packets Outbound Discards = 0
Packet Outbound Errors = 0
Packet Recieved Discard = 0
Packet Recieved Errors = 0
So I'm guessing this status means the client is slow in processing the records. So how might I go about identifying the client is slow in processing the records?
What I have found is the command being run returns around 5000 rows.
I also notice that when watching a specific SPID that has a suspended status that by running the following command the wait_time keeps getting reset. So does this mean the client is processing records each time the wait_time resets?
select * from sys.dm_exec_requests where status = 'suspended'
What else should I consider to clearly identify this is not a DB problem and is a application problem.
Keep in mind this is a canned application that can't be changed.
April 28, 2009 at 3:13 pm
Heather (4/28/2009)
I'm seeing a lot to ASYNC_NETWORK_IO is activity monitor.I know this related to the network or client being slow. The network seems fine based on the looking at the following Network Interface counters:
Current BandWidth = 10,000,000
Output Queue Length = 0
Packets Outbound Discards = 0
Packet Outbound Errors = 0
Packet Recieved Discard = 0
Packet Recieved Errors = 0
So I'm guessing this status means the client is slow in processing the records. So how might I go about identifying the client is slow in processing the records?
What I have found is the command being run returns around 5000 rows.
I also notice that when watching a specific SPID that has a suspended status that by running the following command the wait_time keeps getting reset. So does this mean the client is processing records each time the wait_time resets?
select * from sys.dm_exec_requests where status = 'suspended'
What else should I consider to clearly identify this is not a DB problem and is a application problem.
Keep in mind this is a canned application that can't be changed.
Run the client app in a different computer. If that computer is faster or the resources in it are less constrained it may process the rows at a faster pace therefore reducing your server waits due to ASYNC_NETWORK_IO.
* Noel
April 28, 2009 at 4:09 pm
Sounds like reasonable advice. Only problem is the application is run via Citrix with 100's of users. I really think it has to do with clients waiting for a long period of time on each screen and not processing all the results right way, or a dog of server for the Citrix application. I'm thinking that one solution is really to re-write the application to not return 5000 and only display a few to the user. But since it is a canned application this is not possible.
April 29, 2009 at 2:45 am
Hey Heather,
If the wait time is being reset frequently as you say, and if the wait times are low (say 50 or less), the issue is most likely that the client is only processing one or a few rows at a time, and the waits are due to the latency caused by this.
It is also not unheard of for server network card drivers to mysteriously switch themselves to half-duplex or something daft, so that is worth checking too.
My money is on the first option, but that's just my estimation of the probable cause, not a statement of fact 🙂
If you are not experiencing problems with the server, and if the clients are happy with the performance of the application, I would be tempted to put it down to less-than-brilliant design. Unless there are truly silly numbers of connections waiting on aync_network_io, I can't think of any problems it might cause you.
Cheers,
Paul
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply