Some Latency Measurement Pitfalls

Unrelated to the content of the article but

>The points on the plots below have been randomly jittered by +/- 0.4ms to give a better idea of the distribution at points on the plot that are very dense.

That's a very nice technique!

If what we care about is latency (and the difference between client and server), why would you plot latency on the x-axis (which by convention is the independent variable).

Rotate the axes -- then it becomes obvious that some fraction of the time, the differences between client and server wait times grows large. Don't make the viewer have to figure out that what matters is the distance on the x-axis. Put the thing you want to focus on/minimize on the y-axis where it belongs.

I have yet to find a clear high level summary of how to avoid the first key problem set out in the article (opaque latency); namely:

A. measuring latency at the server side (using traditional methods) tends to be flawed

B. measuring latency at the client (using traditional methods) also tends to be flawed

I'll reread ... let me know if I missed it.

I spent a long span of my career selling and consulting around app performance tools, so what I'm missing as I read this article is - what tools are being used to measure and aggregate the metrics? I don't see anything in the article I disagree with, other than to say that there are a lot of software tools out there in the market that attempt to take all of these issues into account. So... I'm left wondering if the author has a specific take on why all of those products aren't a good solution?