Web Content Caching Explained

The minefield that is web content caching can be confusing and complicated!

It’s one of those features that really sits between the network and the application. In many businesses this grey area has no real ownership and as such, mistakes are often made.

I want to take a little time to explore and hopefully simplify this complex area.

So firstly one must address the question of what is a content cache and why bother using it?

A content cache is a piece of software or an appliance designed to sit in front of the application server. Its job is to intercept certain requests and respond on behalf of the application thus reducing the number of hits sent to the backend severs.

Typically the requests that are intercepted have already been seen before, so the cache will store responses to these requests and if it intercepts a similar request it can respond in the same way.

A simple example would be an image cache. The client (ie browser) would make a response to the web server for an image. The first time this image is requested the cache will have to get it from the web server however for subsequent requests it will simply serve it directly.

The idea is that the web server will have a lot less work to do as the cache can serve a lot of the content. The implications of this really depend on the exact setup, application and content however they typically fit into the following:

1. Reduce load on the web/application servers – Save on application server hardware and licensing costs.

2. Reduce load on middleware and Backed DB systems.

3. Serve the content faster – Caches can be very fast!

4. Cache the content closer to your users. This is an interesting one. The cache does not always have to be at the same location as the rest of the system. You could use a good cache to build your own simple content distribution system to ensure your users get the content from a source as close to them as possible. Who said that a CDN (Content Distribution Network) has to cost the earth!

OK so you have decided that you may want to use a cache, so what next? The biggest problem with content caching is simply deciding what and for how long you want to cache content for. It sounds simple but failure to do this in the past has given many a network manager / application owner a genuine fear of caching. You don’t want one user getting the account balance of the previous user!

However to really make the most of the capabilities that a modern content cache can offer we must understand the full picture. The application behaviour, the cache setup and the browser behaviour.

Let us take a quick look at typically what happens when an image is requested from a web server by a browser.

1. The user requests an image to look at.

2. The Cache will notice that it has not seen this request before and therefore will request it from the web server.

3. The web server will get the image and send it back to the cache.

Important. The web server will decide if this image can be cached or not. It will instruct the upstream devices such as the cache and ultimately the client if it should be cached it or not. It does this by using specific HTTP header. (I won’t geek out on this, in this article as it can get overly complex.)

4. Now it gets interesting because the cache will need to decide on which way to go. Does it obey the rules from the web server or does it override it with its own rules? We will discuss this later on.

5. So the image is now sent back to the client and just to complicate things the client will also cache the content and also look out for the cache control header.

So we can see that not only do we have to decide on the application caching rules but also how we want the cache to behave upstream. If we do this right we can even reduce the number of hits reaching the cache and thus network in the first place.

So now we have a rough idea of what is going on, so how do we implement a cache?

A general method is described in “light” detail below.

1. Decide what you want to cache and for how long – So I want to cache all images for 24hours or all *.asp for 2seconds etc. These can get complicated.

2. Be certain you are happy with these rules.

3. Now check again.

4. Configure the cache to remove all cache control headers from the response from the web server. In other words ignore any caching control setup on the webserver – We assume we know how to create more accurate set of rules.

5. Configure the cache with these new rules and also expiry dates/ durations.

6. Configure the cache to add some new cache controls for the Client. Client side cache control is tough as browsers respect these rules with varying degrees of success. This is not really in the scope of this paper but I may revisit it.

7. Document – These rules can be complex and can involve speaking to people in different parts of the business to understand the application, therefore it’s worth documenting this info whilst it is fresh.

8. Test and test again – The more testing the better. Remember part of testing is to manually empty the content cache’s cache but also the client’s too.

That’s it for now folks.

I am writing a follow up on this talking in a little more detail about typical cache settings and also helping to answer questions such as, ‘will a cache be of any help for my application and if so what type of cache should I be looking at?’