Don't Forget the Network: Your App is Slower Than You Think
summary
Claim: user-perceived latency includes routing and network time often invisible in New Relic and can add 50% or more to response time; use New Relic queue tracking and external checks (Runscope, ThousandEyes, Pingdom) to measure end-to-end. Detect interpreter pauses with a sleep-1 thread probe to surface GC or VM scheduling stalls. Replace averages with percentiles (median, 95th/99th percentiles), breakout per-host graphs, and per-instance alerts. Netflix-style VM benchmarking can improve capacity/cost (roughly ~1/3 savings when done right).
AI-written summary · about
chapters (15)
- 0:00Start
- 6:33Routing
- 10:46Request time
- 14:22Servers
- 15:25Runtime lag
- 18:49VM lag
- 23:34Metrics
- 31:14Graph the median
- 32:27Graph 95th percentile
- 32:59Graph 99th percentile
- 34:09Aggregate graphs another average
- 35:00Breakout graphs
- 35:45Seriously, do it Visualize your data
- 37:32Breakout alerts
- 38:14Questions?
related talks
32mSoftware Performance: A Shape Not a Number
49mResponding in a Timely Manner
41mMeasuring the Moving Parts of User Experience in Java/.NET applications
48mFantastic Performance and Where to Find It
47mResolving performance issues in practice
29mClient Says Your Awesome Web App Works Slowly. Now What?
38mYour benchmark may not guide a real application performance
16m"Latency: Why You Should Worry and What You Can Do About It"