Most IT organizations have a slow application or two, either persistently or intermittently. The tough part is getting the blame off the network and onto whatever system or component is the real culprit.
One way to do this is by analyzing application response time to end user requests.
When combing through a blur of packets in Wireshark, measuring application response time can be a pain. It requires filtering and focusing on individual transactions to an application server, while ignoring the non-essentials.
In this quick tip, we will show how to quickly identify slow application response time with Wireshark. Note – this tip assumes that DHCP, DNS, and other network services were not the root cause.
Filtering on the right conversation
When interacting with an application, an end user will connect to one or more application servers. The first thing to find out is the number of connections the end user makes. To do this, use the conversation statistics in Wireshark, located under Statistics | Conversation List | TCP (IPv4 and IPv6). This will give a good idea as to the number of connections the client has made to the server. If there are too many conversations from end users, set an IP filter for only one client and export only those packets to a new trace file – you captured while an end user was having the problem, right? This will reduce the number of connections in the trace file.
In the conversation list, look for the connections to the application server and right-click the first one. (Hopefully there aren’t too many to click through). Select Follow Stream at the bottom of the conversation window. This will set a filter for the TCP connection the client used to communicate with the server. Close the Stream Data.
Determine Network Latency
If it was captured, the TCP handshake will be the first packets displayed. If the capture was taken client-side, use the delta time displayed timer to measure the delay between the SYN and SYN / ACK packets. This gives you a benchmark network roundtrip time.
In the screenshot below, this timer is measured at 105mSec. Following the TCP handshake, the client will usually send a request to the server. This request may span more than one packet. If the first packet is large, or around 1518 bytes, then the following packet is also a part of the request. In the screenshot below, the client sent a two-packet request to the server.
Measure Application Response Time
The server will acknowledge the request from the client with a 64 byte TCP ACK packet. This will prevent the client from retransmitting the request, as long as the ACK was received. The following time measurement is the way to analyze the application response time. Look at the delta time between the server ACK and the first packet of response. You will see this packet because typically it will have some data in it – in the screen above, this packet is 572 bytes. Note the time between this packet and the ACK above it.
In the example above, the application server is taking 20 full seconds to respond to the client request! This timer includes the network roundtrip time, so mentally we can subtract 105mSec from the total response time to analyze only the application time. This is approximate, but will give you a good idea.
Using the value for network latency vs. application response time, we can identify slow server response time with Wireshark.
This process will need to be repeated for all TCP connections to the server, which can take some time. With practice though, you will get faster and faster at identifying these response times and finding slow applications.
In a future article, we will look at how to automate this process with the ClearSight Analyzer from Fluke Networks.