Chapter 6. Static Content Serving for Speed and Glory

6. Static Content Serving for Speed and Glory

Application developers place so much focus on efficient web application design that it is easy to ignore an important and simple truth: Most content, by volume and by count, is static. From industries such as online pornography to common news sites, static content rules the screen, and the approaches to serving dynamic content are typically inefficient when used in the realm of static content serving.

What does it mean if static objects are served inefficiently? Pages on a website will appear to "hang" while loading or look incomplete during the process of acquiring all the embedded static objects. Some argue that good page coding can ensure that a page will load and display immediately, and the images will trickle in. Although this is important for users over slow dial-up connections, it is crazy to think this is a "solution" to the problem. Simply put, the images on a web page are there for a reason; if they haven't loaded yet, the user hasn't seen what you intended.

To understand what is efficient and what is not, it helps to establish some specific performance goals. So, let's assume that we are building a news serving site capable of servicing 3 million unique visitors per day. Let's also assume that, based on external research, during the peak hour, 15% of all traffic is served, so that 450,000 new visitors arrive during that hour. The average visitor visits five pages and then leaves the site.

Servicing 3 million visitors each with an initial page load and four subsequent page loads requires a capacity of 450,000/1h * 1h/3600s or 125 initial page loads per second. And the four subsequent page loads yield 500 subsequent page loads per second.

Why treat the initial page loads differently? The answer is browser cache. Browser caches hold images locally so that no time needs to be spent reloading the same image from the server to render it on a subsequent page that requires the same static content. We will look later at how to better estimate the peak requests per second.