4 ms·
This is terrific. In the field of web ops, I've had great success tracking the 95th percentile of request time rather than the mean, median, mode, or any other
by OliverJones 10y ago
This is terrific.
In the field of web ops, I've had great success tracking the 95th percentile of request time rather than the mean, median, mode, or any other descriptive metric.
The systems I worked with were, like many systems, ordinarily very efficient. That meant the mean and median metrics washed away the occasional troublesome request and hid it from the metrics dashboard.
But knowing the 95th percentile was out of bounds allowed my team to investigate and try to remediate the trouble spots.
This was especially useful in troubleshooting fax delivery (yeah, I know, I know: it was healthcare stuff; fax is considered secure and email is not) through unbelievably flakey private branch exchanges (big city hospitals)
- keithpeter 10y agoSounds fine to me: fits in with 'management by exception' - look for the extreme cases. Standard in the industrial quality control world (2*sd above or below).
- telotortium 10y agoGil Tene has an entire talk about this point called "How NOT to measure latency" (https://www.youtube.com/watch?v=lJ8ydIuPFeU https://www.youtube.com/watch?v=lJ8ydIuPFeU). In many circumstances, a web service (either server or client) has large numbers of dependencies, so a user only has to hit 95th-percentile latency for one dependency to have their overall latency significantly hurt. In other words, users may encounter the "rare" bad case on a majority of requests. Thus, even higher percentiles should be tightly controlled in order to truly keep a web service's overall latency under control.