The document discusses how to handle spike events in web traffic. Standard cloud elasticity can adjust to gradual load changes but not unexpected spikes, which can lead to lost revenue from slow page loads. When traffic spikes, cloud platforms take 15 minutes to boot new server instances, during which pages are slow and users leave the site. They also bill in hourly increments, charging for unused resources long after spikes. To address this, the document recommends platforms with faster boot times under 10 minutes, sub-hourly billing increments, and metrics that provide timely performance feedback to optimize for spikes and calculate return on investment from recovered and lost revenue.

1. *
Handling Spike Events
Reza Rassool, CTO Kwaai Oak

2. *
Kwaai Oak
2
12/13/2013

3. Sun
Mon
MIN
Sat
Kwaai Oak
Tue
Wed
Thu
Fri
*
3
12/13/2013

4. Recovered revenue (x$100)
Lost revenue (x$100)
Servers
ROI% (x100)
Page load time (s)
Bounce Rate% (x10)
Traffic (100s)
8.00
7.00
6.00
5.00
4.00
3.00
2.00
1.00
0.00
0
Kwaai Oak
1
2
3
4
*
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23
Hour of the day
4
12/13/2013

5. *
Kwaai Oak
5
12/13/2013

6. Standard cloud elasticity can
cope with slowly* varying loads
But what about unexpected
spikes?
*
Kwaai Oak
6
12/13/2013

7. 300.00
* Linux boot
latency
results in lost
revenue
250.00
Total Traffic (x100)
Servers
200.00
* Cloud billing
Bounce rate %
unfairly pads
charges long
after the
spike is over.
Cloud
Cost
150.00
100.00
Not to
scale
50.00
500
550
600
650
700
750
800
Linux Boot
time 15mins
Kwaai Oak
7
12/13/2013

8. * Faster booting nodes – see GCE
* Sub hour billing
* Google GCE (10 min)
* MS Azure (1 min)
*
Kwaai Oak
8
12/13/2013

9. *
Kwaai Oak
9
12/13/2013

10. * Faster boots
* Sub-hour billing
* Also
* Timely feedback metrics
* User centric performance metrics
* Load test (SOASTA)
* Don’t be afraid to compute ROI
* Lost revenue
* Recovered revenue
*
Kwaai Oak
10
12/13/2013