This is a part of a report I wrote last month; the full report is available here.
Mike Belshe – [email protected] – 04/08/10
When choosing an Internet connection, it is intuitive to focus on network bandwidth – â€œSpeeds up to 5Mbps!â€ Bandwidth is important, but it isnâ€™t the only factor in performance. And given the way that HTTP uses short, bursty connections, it turns out that the round-trip-times dominate performance more than bandwidth does.
Of course, bandwidth speeds are very important for video, music, and other large content downloads. These types of content, unlike web pages, are able to utilize the network because they are large, whereas web pages are comprised of many short connections. This report is only concerned with the effect of bandwidth and RTT on the loading of web pages.
Two Factors in Web-page Downloads: Bandwidth and Round-Trip Time
If we make an analogy between plumbing and the Internet, we can consider the bandwidth of the Internet to be like the diameter of the water pipe. A larger pipe carries a larger volume of water, and hence you can deliver more water between two points.
At the same time, no matter how big your pipe is, if the pipe is empty, and you want to get water from one point to the other, it takes time for water to travel through the pipe. In Internet parlance, the time it takes for water to travel from one end of the pipe to the other and back again is called the round trip time, or RTT.
While it is easy to install a bigger pipe between two points to add more bandwidth, minimizing the round trip time is difficult because physics gets in our way. If your server is located in London, for example, and you are in San Francisco, the time it takes to send a message is gated at least by the speed of light (even light would take ~30ms to travel that distance, or 60ms for a full round-trip). On the internet today, round trip times of 150ms to 250ms is common. And no matter how big your pipe is, the RTT will take this long.
Test #1: Vary the Bandwidth
The first test we ran was to see the effect on web-page download times when you change the bandwidth of the network. In this test, weâ€™ve chosen fixed values for packet loss (0%) and round-trip-time (60ms) so that we can isolate the variable under test, bandwidth. In this test weâ€™re downloading a simulation of 25 of the webâ€™s most popular web pages.
Here are the raw results, using HTTP to download the web page:
Page Load Time via HTTP
Figure 1: This graph shows the decrease in latency (page load time) as the bandwidth goes up. As you can see, there are diminishing returns as the bandwidth gets higher. According to the Akamai Internet Report Q2â€™09, the average bandwidth in the US is only 3.9Mbps.
Figure 2: Here we see the incremental percentage decrease in latency as we add more bandwidth. An increase from 5Mbps to 10Mbps amounts to a 5% improvement in Page Load Times.
Figure 3: This graph shows the effective bandwidth of the web page download as the raw bandwidth is increased. At 1Mbps, web pages can be downloaded at ~69% of the total bandwidth capacity. At 10Mbps, however, web pages can only be downloaded at ~16% of the total capacity; and weâ€™re tapering off.
Test #2: Vary the RTT
For this test, we fix the bandwidth at 5Mbps, and vary the RTT from 0ms to 240ms. Keep in mind that the worldwide average RTT to Google is over 100ms today. In the US, RTTs are lower, but 60-70ms is still common.
Page Load Time via HTTP
Figure 4: In this graph, we see the obvious effect that Page Load Time decreases as the RTT decreases. Continued reductions in RTT always helps, even when RTT is low.
Figure 5: This graph shows the % reduction in PLT for each 20 milliseconds of reduced RTT. Unlike improvements to bandwidth (figure 2), where benefits diminish, reducing the RTT always helps the overall PLT. In these tests, with bandwidth fixed at 5Mbps, each 20ms yielded 7-15% reduction in PLT.
Figure 6: This chart shows the increased overall effective bandwidth as RTT is reduced. With high RTT, bandwidth of a page load was as low as 550Kbps, which is a little more than 10% of the 5Mbps theoretical throughput. With low RTT, web page downloads still only achieve ~54% of the total bandwidth available. This is due to other factors of how web pages are loaded.
As you can see from the data above, if users double their bandwidth without reducing their RTT significantly, the effect on Web Browsing will be a minimal improvement. However, decreasing RTT, regardless of current bandwidth always helps make web browsing faster. To speed up the Internet at large, we should look for more ways to bring down RTT. What if we could reduce cross-atlantic RTTs from 150ms to 100ms? This would have a larger effect on the speed of the internet than increasing a userâ€™s bandwidth from 3.9Mbps to 10Mbps or even 1Gbps.
9 thoughts on “More Bandwidth Doesn’t Matter (Much)”
Wow, that’s great data. I’ll certainly keep that in mind as I build customer facing systems. Thus the importance of geographically dispersing your systems has been fortified.
Pingback:Ajaxian » More Bandwidth Doesnâ€™t Matter Much (Above ~5Mbps)
Shouldn’t be the conclusion that one should do less (serial)requests, because latency is unlikely to improve(because of physics)?
I did a similiar test some time ago where I varied the size of the request e.g. in high latency scenarios (RTT >100ms) it helps very much to have small responses, because the response time jumps at certain response sizes (8, 16Kbyte etc).
one more point.
Isn’t it also a major problem that HTTP pipelining is not properly working with many browsers/proxies.
Did you use HTTP pipelining?
@markus: I don’t test with pipelining since none of the major browsers support it (due to the proxy points you mention). A test should be done with pipelining – the number will go up. But, pipelining has so many problems (HOL blocking, prioritization failures, and deployment practicality) that it may not be interesting. Soon, I’ll do the same study showing SPDY performance.
this is great work. Two quick questions, did you know the “detailed report” link doesn’t work any more?
Secondly, do you have your detailed research methodology or scripts available anywhere? I’d love to see your research methodology in detail.
Pingback:Is it time to give up Internet Explorer 7 as our default test scenario? — Web Performance Today
Pingback:Internet Application Performance: The Results Are In | InterConnections - The Official Equinix Blog
Pingback:Performance Calendar » Make your mobile pages render in under one second