Part 1 – High availability cache
This is the first of a two-part blog, giving an introduction to the high availability cache at the front-end of the website.
The new responsive TfL Website is not just a mobile make-over, it has been re-developed from the ground up. The site is a fundamentally brand-new, structurally re-designed, responsive website for the modern needs of the travelling public in London.
Living in a fast-moving age can sometimes make us impatient, especially so with the internet and website page loads – no-one wants to see the dreaded “buffer face” expression. That’s why we designed the new TfL website with a high availability front end cache (Varnish), partnered with an auto-scaling solution (via AWS cloud) for the back-end components. This formidable combination powers the TfL website, serving page loads quickly and repeat page loads even quicker, 24/7 and 365 days a year.
Varnish is a web accelerator which allows our website to sustain very high traffic and load many times faster by caching static & dynamic content. We use it in the new TfL website at the web application tier, to cache all incoming requests, and its capable of handling 2000 to 3000 requests per second.
Delivering content via cache is much faster than delivering it all the way down through the infrastructure from a web server at the back-end of the website. It’s rather like having to go to the back of the shop each time you want a sweet, better to have them stored up front because we know, and you know, that you’ll always want them!
What gives us performance gains is that the cache can store responses from the back-end for future use, quickly serving the next response directly from cache without placing any needless load on the back-end servers. The result is that the load on the back-end is significantly reduced, therefore response times improve, and more requests can be served per second. One of the things that makes the cache so fast is that it keeps its data completely in memory instead of hard disk.
This enables our web pages to load very quickly, and repeat page requests are typically served twice as fast, even at high-volume peak commute times. This is exactly what the travelling public wanted and what you’d expect from a top website.
A lot of Londoners and visitors to London rely on tfl.gov.uk, and any outage can be a real pain, so for example, if there was problem with the back-end of the website, rather than having a “Sorry website is unavailable” holding page, we can serve up the last good version of the home page for a period, whilst we fix the back-end. That’s a great feature to have because we are a 24/7 service and need to be available 100% of the time.
In part 2 of this blog, I’ll look more at what we have done to help the back-end of our website cope better under load.