Main Content

Web server efficiency - saving repetition through caches

Archive - Originally posted on "The Horse's Mouth" - 2013-05-30 22:19:17 - Graham Ellis

A thousand to one is an impressive increase in performance. And at times it can be achieved in web based applications if you employ caching.

Let's say that a user asks about... current train running on our First Great Western Coffee Shop site. They'll get a diagram like the one that's to the side here. Another user asks for the same information... gets the same diagram. Fair enough - it's not likely to have changed within a few seconds.

But the data for the original query isn't stored on our system - it's sourced from elsewhere such as Network Rail, and it's needlessly repetitive for it to be called up and recalculated, perhaps identically, for the second requester. And it's not just two people - I have 19 people looking at present, and it can rise to over a hundred people at times.

Best to get the information once and store it - "Cache" it - for a limited time - perhaps 2 or 3 minutes for this particular data set; perhaps half an hour for tomorrow's weather forecast, perhaps no more than 10 seconds for breaking news.

But where to store it? There are a number of places - staring from the user's end

1. Cache at browser
2. Squid / Varnish Cache

3. Page application - Front Cache (complete page)
4. Page application - Middle Cache (components)
5. Page application - Back cache (results from services)

6. Very Back end in service layer

Which of these should you use? Each / any / ALL are valid.

1. User's browsers store images and other data, and it's worthwhile signalling that an image or slowmoving page element doesn't need to be reloaded every time.

2. A Varnish or Squid server takes requests of the web server and stores a copy before sending out to the browser. It sits in front of your regular server or server farm, and means that identical incoming requests can be answered with "one I prepared earlier". Code must be carefully written (and look up etags) to ensure that the request is identical not only in terms of URL, but also parameters, browser, cookies, and geographic region to ensure a correct feed

3. The web server main layer may also store a completed response just to resend it if required. Where there's load balancing / clustering, this may be less efficient that using Squid / Varnish as each system will have a copy

4. Intermediate calculations within the main layer that are useful from one request to the next may be stored.

5. Where you're pulling in a feed, store the feed results for an appropriate time... don't keep asking. Again, speeds things up / reduces work and requests. Also avoids irritating the feed supplier ;-)

6. And - subject for another day - there's the whole business of caching database responses / service layer responses too.

The graphic you saw at the top is generated from a feed that's cached in our server, and indeed we cache the completed image too - we're using (1), (3) and (5). And it's possible that (6) is in use too by our feed supplier. There may be a couple of minutes delay in the updates as we've got some quite long timings set, but it gives a pretty good general impression - telling me as I write that there's an issue with a train between Gatwick and Reading, but across the rest of the South West, no big problems.