Richard Dallaway's Blog Avatar
Richard Dallaway's Blog

Java caching APIs

Last month I attended a superb presentation on JBoss Cache by the project lead, Manik Surtani. Luckily only six people showed up, so were were able to chat to Manik, and really pick his brains on this stuff. Talking to Manik gave me a huge amount of confidence in the JBoss Cache product.

Some background to all of this: we’ve all probably kept something that’s frequently used, and infrequently changing, in memory to save a trip to a database. That’s one of the things you can use a cache like JBoss Cache for, but that are other benefits too: the preference for code that’s been written elsewhere (many eyes etc); a smart way to do invalidation; a way to distribute a cache between servers; reporting tools… and so on.

JBoss Cache isn’t the only solution out there. There are a bunch of APIs you can use to add caching into your application, and maybe one day the Java Temporary Caching API (JSR 107) standard will mean you can use one API across all the implementations. I was wondering… how do they compare. I decided to have quick look at performance for three of the popular ones.

I’m looking at:

I have a scenario in mind, where there are a lot of cache hits and only a few cache stores. In particular I wanted to know how the implementations perform under concurrent access, such as a heavily loaded web site: what happens to the cache performance as load increases.

To set the stage here’s a graph showing the performance of a work load when using the ye olde synchronized Hashtable, the spanky new ConcurrentHashMap and a “noop” implementation that neither stores nor returns anything. The idea here is just to provide a sanity check of how my laptop performs under increasing load.

java