Lightning in the Cloud: A Study of Transient Bottlenecks on n-Tier Web Application
summary
Experimental study uses the rubis benchmark with passive router box timestamps at 50 ms resolution to show that tens-to-hundreds-of-milliseconds bottlenecks (e.g., JDK 1.5 stop-the-world GC for 50–100 ms driving CPU to 100%) cause queue amplification across a four‑tier Apache/Tomcat/MySQL stack and produce VLRTs (over 2% of requests exceed 2 s at 9,000 users with ~61% CPU). Identified causes: stop-the-world GC, VM consolidation “noisy neighbors”, and DVFS anti‑synchrony; fixes tested include upgrading to JDK 1.6/1.7 and VM migration, with tradeoffs in component configuration.
AI-written summary · about
chapters (21)
- 0:00Start
- 0:36Resource Utilization Paradox
- 2:04Measured Large Response Time Fluctuations
- 3:19Talk Thesis
- 3:55Experimental Setup: 4-Tier System
- 5:07Passive Message Timestamping Infrastructure
- 6:19Measured Average System Performance
- 7:28Large Response Time Fluctuations Case 1: Java GC
- 8:55Java Garbage Collection Very Short Bottlenecks
- 12:05Long Queues/Dropped Packets Long Requests
- 13:41Push-Back: Upstream Queuing Amplification
- 15:20Impact of Very Short Bottlenecks
- 16:54Case 2: VM Consolidation
- 19:45Response Time Fluctuations Measured in Sys-Original
- 20:40VM Workload Bursts
- 22:39Very Short Bottlenecks Queued Requests, Long Queues
- 23:26Queued Requests/Dropped Packets Long Requests, RT Fluctuations
- 24:30Case 3: DVFS
- 25:30DVFS Experimental Setup
- 25:45Delay of DVFS Adjustment Very Short Bottlenecks
- 26:05Queued Requests Response Time Fluctuations
related talks
29mSite Availability is for Everybody
45mPerformance Testing and Tuning of Web Applications
38mPractical Performance Analysis
49mResponding in a Timely Manner
53mComet, Ajax, web browsers limitations and web apps performance factors
30mAbove the Clouds: Investigating Systems from 32,000 ft.
54mReal-World HTTP Performance Benchmarking, Lessons Learned
26mTuning Your Cloud: Improve Global Network Performance for Applications