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:
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!).
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.
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).
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).
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."