This article was originally published in net magazine in 2016.
In 1948, the Olympic Games was broadcast live on television for the first time. Somehow, in post-war austerity with scarce resources and little money, the BBC broke technological boundaries. Live coverage came from two venues in North London, in what was at the time the largest outside broadcast ever made.
It was a milestone in sports coverage. The beginning of a revolution, you could say, into the limitless sport on TV and online today.
70 years on, we at the BBC continue to push how we can bring the Olympics to the UK and the world. And today, of course, it’s more than TV. A wide range of Olympic content is offered over the BBC’s websites and apps, and it’s phenomenally popular. Over 100 million devices accessed our Rio 2016 site.
Offering a great online service to over 100 million devices is not easy. High levels of web traffic puts huge load on the underlying systems. Fortunately, we were prepared. We knew the summer of 2016 was going to be our biggest ever, and made sure we had a website that could scale to handle it. This article explains how we did it.
01. Caches are your best friend
Let’s start with the basics. A cache is the single most important technology in keeping sites scalable and fast. By storing copies of data and providing them when they're next needed, caches reduce the number of requests that make it to the server. And that allows the server to handle more users.
Everyone knows the cache inside a web browser. It’s perfect for any common content between web pages, such as CSS. As a user moves between pages on your site, the browser’s cache will ensure they don’t repeatedly download the same file. This means there are fewer requests to your web servers, freeing up capacity to handle more users.
During the Rio Olympics, the BBC offered thousands of web pages and over 3,000 hours of video to watch on its website Caches (including CDNs) are great for content that normally stays the same. But if content changes frequently, or from person to person, a cache is limited in what it can safely do. If a web page includes a user’s sign-in details, for example, a cache cannot share it, or else one user may see another user’s details.
All this means that, even with the best caches and CDNs, web servers still have to pick up much of the work. So you’ll likely need several of them. Having multiple servers allows the work to be shared, and also prevents a server failure from breaking your site. A load balancer then ensures each one takes their share of the work.
If your servers are running on the cloud, take advantage of the fact new virtual machines can be requested on demand, and paid for by the minute or hour. This elastic nature of most cloud providers allows you to have more web servers when traffic is high, and fewer when it’s quiet.
As an example, we at the BBC have hundreds of cloud-based web servers, the exact number continually changing based on traffic levels to different parts of the site. We’ve learned that other systems must be able to scale too. A database or API that the site uses, for example, will also need to handle moments of high traffic.
04. Optimise page generation
For all but the simplest of sites, there is some dynamic generation: code that runs to create the contents of a page. Optimising this process can allow a web page to be created quicker, which enables a server to handle more requests. Consider:
- Can the code be changed to be more efficient? Is it handling more data than necessary, or creating more content than is actually shown?
- Are there are any database or API calls that can be made faster or removed?
- Could any content be prepared ahead of time and stored in a database, file or cache?
05. Split the work
The strong JavaScript support in today’s browsers is a resource we can make use of. By getting the client – the in-page JavaScript – to do some work, we can reduce how much is happening on the server. This can have a number of benefits.
During high traffic, pick the right thing to compromise on. Which probably isn’t speed
You can make fewer page requests by, for example, filtering rows of a table in JavaScript rather than on the server. Also, rather than having large pages that take time to create, consider making smaller ones that only include the initial content, then use JavaScript and APIs to load additional content separately. Facebook does this extensively.
Finally, it enables you to offer the same thing to everyone. If a page has small parts that are unique to a user (e.g. a shopping cart or recommendations), arrange for those parts to be added client-side. This way the base page can be the same for everyone, so it can be cached and the web server won’t have to recreate it for every user.
06. Find your limit
BBC Radio 1's Big Weekend arrives with chaotic GIFs
Thank you for reading 5 articles this month* Join now for unlimited access
Enjoy your first month for just £1 / $1 / €1
*Read 5 free articles per month without a subscription
Join now for unlimited access
Try first month for just £1 / $1 / €1