This article is also available as a Podcast on "The RootCause" podcast series available on iTunes.

The issue of latency of any kind, is a complex issue. Latency measurements in multi-tiered designs are the most complex of all. That being said, below are Five Concepts to help you get started.

FIRST: You need to have a clear understanding of the various types of latency. As I have covered this in other articles and podcasts, I will only include a bulleted list of the most critical types.

— LAN

— WAN

— Server

— Application

— Database

— Proxy

— Workstation & Browser

SECOND: You need to have a clear vision of what you are looking for. It is unlikely that you will be able to monitor all those areas simultaneously (except possibly through logs). Are you looking as part of a troubleshooting process, or a baselining process, or are you setting up a monitoring process?

THIRD: Think in terms of elimination. What can you eliminate from the equation? Breaking out the various forms of latency from a set of WireShark (or other) Trace Files is a subtractive process. You are trying to separate metrics.

For example, let's say you want to separate the WAN from the LAN. You will need to have metrics of the same transactions from as close to the point where a packet gets onto the WAN as possible. Simultaneously, you need to capture the same transactions, performed on the other side of the WAN. If your testing is tight, your timing exact, and your process in both locations identical, you will be able to subtract the LAN metrics from the WAN metrics and have a glimpse of the WAN Only metrics.

Unfortunately this is not always as easy as it seems. In the example used above, it is accurate with minimal work—but only from the First Tier to the Client. Once you need metrics from the Second, Third or other Tiers—it gets much more complex. That is why one short article is limited to the big picture of concepts. Details require more space—but are also available

FOURTH: Once you have figured out where the traffic you want to measure is—specifically, its Physical Data Path—you are in a position to determine where to place your Packet-Sniffers. At minimum, you will always need two. You want to see the packet leave its source and arrive at its destination—both ways. Seeing only one side or the other may be able to tell you a great deal about the nature of the traffic and help you determine the cause of problems—but you need both sides to measure latency. Sometimes—you need several sides.

FIFTH: Once you are past the First Tier—identification of your test packets becomes more difficult. The Back-End Tiers will probably use protocols very different than the front. Additionally, depending on how the application is threaded, you may see many different users and connections funneled through a single connection on the Back-End. So, how do you separate them? The key is to find something that can be unique. If you have the ability to work directly with the Test Users (Human or Simulated) and can get them to put in certain text or numerical values, then you can look in the traces for those values and learn the specific TCP's involved. It is best to speak to the Subject Matter Experts (SME) for the Application and Database, as they will know where you might be able to place such dummy data.