HTTP Proxy Caching Vs Application Caches

Developers love redeveloping the wheel and writing caching code is a typical example of this. I have seen several examples of developers writing custom caches inside their web applications without considering if they would be better off using standard proxy caching.

Sometimes you do need to write your own caching code. One case you might need to write your own cache (or wrap ehcache) is if you need partial page caching - but for a lot of cases using standard HTTP proxy is a much better option.

Here are some of the many advantages of using standard HTTP proxy caching:

• Faster pages since resources can be served from the Web-browser cache, ISP caches, office caches and various other caches on the internet which are closer to the client than your server.
• Save bandwidth since you have to serve less content from your origin server(s).
• You can add caching directly on your server by installing one of several free high performance reverse-proxy caches.
• Configure expiry times for resources in one place on your server for *all* the caches, and have all these caches work in a hierarchy right back to your server cache - totally transparently.

That is the beauty of using standard proxy caching.

So, how does it work and what do you need to do?
Let's look at the steps involved to make use of all the caches between your server and the client and to add an additional cache on your server (a cache of last resort!).

Step 1 - Set Correct Expiry Headers for Web Pages you Serve.

For each resource you serve that you want cached, you need to set caching header that the server will use in the HTTP response. There are various headers related to caching but one that you can use is the cache-control with the max-age directive. You can google to find out how to set this for a resource on your particular application server or web server.

Step 2 - Test the Expiry Headers are Working.

There are many ways you can test if the headers are being set successfully. The easiest may be to check in the browser cache to see when the content expires. If the content is not being cached properly you probably want to check that the server does actually send the headers correctly that you tried to configure in step 1. You can install livehttpheader to see headers in firefox or you can use ethereal to scan the network traffic and get the headers from that (ethereal can take a while to get to grips with but it is really neat).

Step 3 (Optional) - Adding a Reverse Proxy server

If you want additional caching on your server to further offload resources from your application server you can install a reverse proxy cache. This article explains how to configure squid as a reverse proxy, I have done this for viralvideochart.com and it works nicely acting a cache that sits in front of our application server.
There are many other reverse proxy caches around (the full version of the Resin application server has one built in for example).

Step 4 - Enjoy Blistering Fast Serving Speeds!

That's right with the correct HTTP headers set and a reverse proxy configured on your server, as the load on the cacheable resources goes up a reasonable reverse-proxy should be able to approach static file serving speeds! Thus offloading a lot of needless work from your application and database server without the need to write yet another application cache.

"...when this baby hits eighty-eight miles per hour... you're gonna see some serious shit."