Troubleshooting a real issue: the slow server.

In this fifth post on Wireshark, I’ll examine two common real issues that wireshark will help you understand. Slow http requests and slow TCP packets.

In the case of slow http requests, we can set up a filter that measures time since request.

This is the way to find slow http connections — and examine your server response times.

1. A client sends a GET

2. After some period the server will respond with the result of that request.

3. In the image, I’m showing a Wireshark trace while in a browser window, I’m entering the URL for Bestart.app.

4. By pressing command-F, I can search for the string bestart, and locate the first packet, which is the DNS request for the website.

5. I want to know how fast the response time is for my bestart.app website. The filter for this is http.time > 0.01. I’m checking for all responses that come back in more than 0.01 seconds. If the site were slow, I could filter with a higher value, such as 1 or 2 seconds. In this case, the site is responding nicely, so if I were to put in a higher value, we wouldn’t see any packets at all.

6. I’ve highlighted packet #25930. Look in the lower left detail section for that packet. You can see the time since request is 0.07414 seconds. This is indeed greated than 0.01 seconds, so it passed the filter.

The reason this helps you identify site problems is that, in the first place, the packets can help you identify the exact request that is being made. Is it a delay because the request is asking for data that requires an inner join on four tables in your database? and maybe one of those is a super large logging table?

Once you have identified the source of the problem. Write down the http.time values or just make a screen shot. And when your database administrators have optimized the query, you have real numbers to examine the second time around: Is the optimized query actually reducing the time between requests?

That is the power of wireshark.