All Things WebSphere

Caching is a very common design pattern to improve the performance of a web application. Caching can be done at multiple tiers, application, database, edge of the network.... Caching done right can improve the performance of your web application by 2x-5x. Yes sir that is correct!!! Let me lead you to the road of redemption.

Say your application is an old school J2EE style application composed of with JSP, Servlets, JSF et al. Most of the time your app. is housed in an application server. All application servers have caching frameworks that you can leverage to cache web application JSP/JSTL/Servlet responses.

1. Look at your web application and determine what is cacheable and what is not. This is not an enjoyable activity. Its like asking someone what they want to become after growing up. At least try to determine all the obvious fragments of your site like headers, footers or relatively unchanging JSPs etc.. that can be cacheable.
2. Employ tag libraries or configure servlet caching to start caching the web responses from these cacheable artifacts.
3. Plugin a filter/handler/interceptor/thingamajig/custom code that interacts with caching framework that determines for every URI/request coming into the webcontainer, whether the request was a CACHE MISS, CACHE HIT or was UNELIGIBLE for caching.
4. Log this information in some file and gather these statistics over a suitable period of time like a week.
5. WTF do I do with this data ? 1. Determine the cacheability of your website. cacheability= no. of cache miss/no. of cache hits. The smaller this no. the better your website will be able to handle user load. 2. Most importantly look at all the URIs or requests that were demmed to be uncacheable and consider adding caching for those web fragment responses.
6. Scrub and Repeat
   

Once you start watching what is cacheable and what is not, you will learn a LOT about your website and its load/user characteristics. You will be add caching for every web response that can be cached thereby improving performance and reaching nirvana.

One hint of caution about adding more caching....Please look at JVM heap usage before you start caching the whole world. Please also put in place a cache invalidation strategy. You dont want users to buy an out-of-stock item.

More on these pesky cache issues later.....

I am excited about the new Dynacache heap management feature in WAS7. The primary motivation for introducing this feature is for serviceability. Many times customers trip up on themselves by caching too much stuff. I have lost count of the number of critical situations where I have been hauled from the bed, by some customer critical situation where the server was down due to an OOM error. It is extremely important to size the cache well. Unfortunately this is not an easy thing to do and pre-production stress testing in some cases does not simulate real world traffic which leads to an unutilized cache and thus false confidence in the capacity utilization of the cache.

This is not an easy problem to solve. There is no sizeof operator in Java which will tell us the size of an object in the JVM heap. Therefore we have to use all sorts of smarts, trickery and some help from the application developer to determine the total amount of memory on the JVM heap taken up by the cache. All earlier techniques to determine cache size rely on serializing the cached objects and metadata because that is the only way to accurately determine the size of the objects. In WebSphere 7 we have taken a much light weight patented approach which does not rely on serialization to determine cache heap size.

Most application servers allow cache size to be controlled by no.of entries. We are taking cache size management to the next level in WebSphere Application Server 7.

What exactly does Dynacache provide ?
WAS Dynacache component will provide an ability to constrain the cache in terms of the JVM heap. In addition to specifying the cache size in MB, Dynacache will also allow customers to set a high water mark and a low water mark for the cache heap consumed. Once cache heap memory reaches the high water mark, dynacache will either discard or evict the least recently used items to disk, till the cache is brought down to the low water mark. This functionality of limiting the cache in terms of the JVM heap will be available if the objects put into the cache that implement the com.ibm.websphere.cache.Sizeable interface. When servlet caching is enabled, all the cached JSP and servlet responses will be Sizeable. This interface will have one method which will return the size of the Object in bytes put into the cache. Dynacache will use the Sizeable interface to estimate the heap size of the cache. This feature will be OFF by default. A customer will have to explicitly enable and set cache limits and watermarks.

How to enable this feature ?

On the Dynacache service panel, WebSphere exposes the Dynamic Cache object cache service and Dynamic Cache servlet cache service. The Dynamic object cache service is always started at server start up. The Dynamic servlet cache service is started when the servlet caching is enabled in WebContainer panel. There is now a checkbox for Memory Cache Size which will control the memory cache size with high/low threshold. In addition to specifying the size the customer can also specify a range for the heap by setting threshold limits. The Servlet and Object Cache instance under the Resources -> Cache Instances have also include the Memory Cache Size control feature.