website content performance modeling html5 conference 2014

©2014 AKAMAI | FASTER FORWARDTM

Website Content

Performance Modeling

HTML5 Conference, Oct. 21st, 2014Pierre Lermant, Akamai Technologies

@plermant


What problem are we trying to solve?

● Help IT organizations optimize their serving infrastructure

by modeling website dynamic resource download times


Existing Models:

● Can be too simple:○ It is bounded by the speed of light !

● Can be too theoretical

● As a result, no reliable and practical ways to predict

download times of dynamic website resources


Trivia Question

● How long does it take to download a 50K resource

from New-York to San-Francisco (~2,500 miles)?


What parameters are at play?


What parameters don’t really matter

● Last Mile bandwidth is rarely a download bottleneck

Sources: https://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/

Akamai State of the Internet report, Q2 2014

https://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/


What parameters don’t really matter, contd.

● Client receiving window buffer size○ i.e. how much data can be ‘in flight’ between a server and a client

○ Typically set at 65 K, larger than most website resources

● Network loss○ Assuming here it’s negligible for small resources

Source: httparchive.org


What parameters have most impact

● New or reused connection, HTTP vs HTTPS○ TCP connection establishment can require many round trips

● Round Trip Times○ Last mile latency: Can vary greatly, from ~0 to 100s of ms

○ Middle Mile RTT: Has most impact over long-haul distances


What parameters have most impact, contd.

● Origin server initial TCP congestion window○ How many packets can be sent at the start of data download

● Content size and distance client-server


Middle Mile RTT

● Proven difficult to model○ Cannot be approximated by mathematical equations

○ Is driven by peering negotiations between ISPs

● -> Built an experimental setup to model its value


RTT modeling experimental setup

Ping agents (ICMP)

Ping targets, distribution

matching internet usage


RTT/Distance typical distribution


Middle-Mile RTT (ms) ~ 3.1 % * Distance (miles)For distances > 500 miles

SF - NY RTT

at speed of

light = 27 ms

SF - NY RTT

thru internet ~

80 ms


Impact of content size & connection type, part 1

Client Server



Initcwnd = 3 Initcwnd = 10



● Total download size (KB), per number of Round Trips

50 K


Connection Reuse: CDN Intermediary Paradigm


Download times of a 50 KB resource*

● Direct is ~ 400 ms (Initcwnd=3), ~ 300 ms (Initcwnd=10)

● Thru CDN intermediaries ~ (80+10+10) ~ 100 ms

* New http connection, 2,500 miles client-server distance, no network loss, no first

or last mile latencies


Take Aways


Main take aways

● Median Middle Mile RTT ~ 3 % of Distance Client-Server○ This is the primary performance driver over long distances

● Client bandwidth and TCP buffer size are rarely a

download bottleneck


Main take aways, contd.

● Critical impact of TCP initial congestion window

(=Initcwnd) for new connections.○ Recent server builds (Linux > 2.6.39) set initcwnd to 10

● Dramatic differences between new and re-used

connections over long distances○ Set permanent connections at your origin if possible

○ Consider CDN intermediaries for far-away end-users


Live Model, Screenshot 1

Source: http://www.akamai.com/html/ms/delivering-dynamic-web-content.html