Diagnosing Application Performance Problems

In IT, when you get those reports that “everything is slow,” you need to define two critical things: What is "everything" and what is slow? In many cases, "everything” can be straightforward. The trick is to ask some specific questions to determine if it's all the applications, or just one. You also should always ask if others are experiencing the same issue to identify bigger problems.

When traditional monitoring tools don’t point to anything specific, you might have to get into the nitty-gritty packets. If you are extremely fortunate, you might be able to capture packets from the server and client computer. If not, you will have to go back to your TAPs or SPAN ports to intercept the traffic.

In this video demonstration, I have Wireshark installed on the server and client computers and had my customer simply download a file to get a baseline. As always, make sure to plan and properly calculate your transfer sizes.

Having a clear and concise goal is critically important. In this case, all I want to do is get a baseline and document response times. I never try to find the answer; I simply eliminate what it isn’t. Then I investigate what is left. I know; easier said than done! 

My methodology for this trace file would be different if some variables change. For example, the client and server could traverse a router, proxy, NAT or load balancer, which requires a different approach.

In this example, the client and server are on the same subnet, VLAN, and switch to make things a bit more straightforward.

When possible, use the same trace file to prove how the various layers are performing. I used TCP and HTTP commands and responses to compare response time. And lastly, it really helps to have the trace side by side to compare.