Java Scalability 101: Page Fragment Caching

Note: this is the second in a series of articles on achieving a faster application response and scalability for small businesses, concentrating upon free or inexpensive solutions that are easy to implement.

One of the rising stars in the open source world is memcached, billed out as “a high-performance, distributed memory object caching system”. Memcached has an API that can be accessed via nearly every web programming environment, and is a valuable tool for storing frequently-accessed objects, large pieces of content, and other items that need to be retrieved quickly (versus grabbing them from a database).

What many Java programmers may not be aware of is a comparable system that runs natively inside your application framework. OSCache allows for nearly all of the same functionality as memcached, and it doesn’t require a separate process to be running; everything runs within the context of your web app (or your container). It can also be accessed remotely, or clustered across servers (via native clustered shared memory in solutions such as Jboss or the newer Tomcat).

One of the better uses for OSCache, however, is its JSP Tag library. Assume for a moment that you have the following:

Hello,
<%
// extremely expensive JSP logic that winds up
// returning the word "world"
%>

If the “extremely expensive JSP logic” portion of that code were something that did a large SQL query, or had to go grab data off a remote service, or had to parse XML, etc etc, and the resulting output didn’t actually change that often, you could use OSCache to cache that individual page fragment into memory, like so:

Hello,
<cache:cache>
<%
// extremely expensive code
%>
</cache:cache>

The first time this JSP page was run, the expensive logic would be run, and the results would be displayed. However, on each subsequent access (up to a period of time) the resulting HTML would simply be pulled from an in-memory cache and immediately displayed to the user, a much faster operation (resulting in a much faster page load time).

What does this mean for real world sites? It means that even if you were to set the cache timeout to something extremely low, eg 5 seconds, any bottleneck caused by this expensive piece of code should go away. This helps with traffic spikes, eg getting mentioned on the larger social news sites, in traditional media, or even helping to prevent denial of service attacks. A few well-placed page fragment caches on each page can speed up that page immensely.

The OSCache site details all of its functionality, but for mid-sized JSP-based sites, adding a page-level cache can increase response times by an order of magnitude, especially under heavy load. Caching smaller fragments of a page, while not as effective as caching an entire page, can still be useful in that all of the content on your page that doesn’t change very often is much better served by being pulled directly from memory 99% of the time.

Are you using OSCache? Share your experiences in the comments below.