How I Learned to Stop Worrying and Love Misery
summary
Monitoring percentiles lie because of coordinated omission that drops stalled requests from measurements, so 95/99 percentiles and averages hide real pain; a five-click session example shows 99.997% of sessions see at least one response worse than the reported percentile, and using “three nines” still leaves ~18% of users worse off. The fix is to measure failures and retries as counts (percent of misery) and instrument real response times during stalls rather than averaging censored samples.
AI-written summary · about
chapters (11)
- 0:00Start
- 5:04A real world, real time example
- 7:21What (TF) does the Average of the 95% lie mean?
- 8:4999% lie: a good indicator, right?
- 10:08Gauging user experience
- 11:47Coordinated Omission in Monitoring Code
- 13:27Measurement in practice
- 14:03Proper measurement
- 14:16Better" can look "Worse
- 20:32Looking at misery
- 21:14This is a Microservice
related talks
23mYou Get What You Measure—Why Metrics Are Important
37mLies, Damn Lies, and Metrics
37mMonitoring the Health of Your App
39mThe Many Ways Your Monitoring Is Lying to You
18mLook at Your Data
32mSoftware Performance: A Shape Not a Number
21mShow Me the RIGHT Numbers! Are Our Users Happy?
33mThe Problem with MTTR: Learning from Incident Reports