Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.


Network Response Time Vs Application Response Time

I am sure that most of us have heard the cries of the end user community when their important applications' respond time is slow. Currently I have one Java application stored in servers behind 6500. Users of this application are spreaded accroos entire WAN cloud. Users are complaining about slow response of this application. So I am assigned to proove that network is not responsible for this slowness. Is there any method by which I can measure network response vs application response. Any help on this will be greatly apprecaited.


Re: Network Response Time Vs Application Response Time

You can ping and traceroute between the router at the sites, which should give you a pure network response through the WAN.

You can run Wireshark on a client and capture the traffic flow while the application is up & working. Wireshark and other similar analyzers give you absolute and delta time and can track specific TCP sessions.

If the application is stalling, you'll see it.

Wireshark is free (

Good Luck


Re: Network Response Time Vs Application Response Time

In addition to Scotts sugestions..which is a very effective quick way to see responce latancecy, sometimes one have to take it a little into more depth investigation.

From personal experience responce time and latency may be the cause of many factors, so other question arises in terms of whether slowness is a sudden event or if it had developed in time, either way you have to arm yourself with a systematic process to create a baseline of your network in every angle you can think of, that is, switch performance, local links performance, WAN links performacen and so on.. throughut all your WAN connections. By creating and having a baseline it will be much easier to pin point where the problem could be, believe it or not most of server slowness complains at least in my watch is either because of poor server/database architecture deployment or becuase of duplex miss matches, or some remote switch local uplinks are droping packets affecting the whole remote site.

I use several tools for monitorin WAN links and downstream links utilization as well as servers port utilization including down to the very switchport of users PRTG is one of these tools.

In some cases you may find that issues could reside in the switches users ports poor connections, or remote WAN links are over utilized from what they used to be, or again

duplex missmatches on users switches which contributes to generating more retransmission requests and of course generating more traffic,so I would start with the very basics checking users switches, ports stats, uplink stats, WAN link stats etc.. then move onto pings and extended pings from different locations to the server in question.

refer to this link for some other tips,%20Routing%20and%20Switching&CommCmd=MB?cmd=display_location&location=.1ddfa244/0

PRTG is a very good graphical tool, this can measure application and network responce in graphical means by creating baselines.

There is a freeware version called MRTG