caching in a clustered environment

[ctassoni]

The application I'm developing will supposedly be clustered when it comes time to release it to production. So far I've done whatever caching I've needed in the app with ehCache, which is not a cluster-aware cache. I've done that because I figured that

1) A cache that communicates between nodes in a cluster can't be much better than just getting data directly from the database.

2) It's ok for data such as drop down list choices to sometimes be different on different cluster nodes

3) Whenever a particular cached object must be synchronized across clusters, I can find some way to communicate across the clusters and tell each cache to release its version of that object. This sporadic intra-cluster communication must be less hurtful to performance than having a cluster-aware cache that is constantly communicating between cluster nodes.

But when I think about it for a bit, I become unsure. I don't really know much about the performance of cluster-aware caches. And I have trouble figuring out when it's ok to have unsynced data in different clusters. Not only that, I think something's wrong with trying to make this assessment for all the different categories of cached objects. It's not code smell, but it's some kind of conceptual smell. Come to think of it, it will end up as code smell that comes from a faulty concept.

But in practice I haven't been making that assessment because I'm not really sure how I'm going to communicate between cluster nodes, although I guess I'll probably end up using JGroups.

So what do people in the forum do about caching inside a cluster? Can you get away with a cache that's not cluster aware? If not, what have you used that's worked?

[katentim]

1) A cache that communicates between nodes in a cluster can't be much better than just getting data directly from the database.

That's not necessarily true. Generally you cache to improve response times, because the data takes too long to retrieve (it also reduces load on the data source). It just depends on how long the data takes to retrieve compared to inter-cluster cache communication. You'll have to test on your system.

2) It's ok for data such as drop down list choices to sometimes be different on different cluster nodes

Depends on the consequences of using out-of-date data from the drop-down.

3) Whenever a particular cached object must be synchronized across clusters, I can find some way to communicate across the clusters and tell each cache to release its version of that object. This sporadic intra-cluster communication must be less hurtful to performance than having a cluster-aware cache that is constantly communicating between cluster nodes.

A good cluster cache should operate efficiently.

[bnewport]

Buy something, don't build it. I have 12 guys working on ObjectGrid for the past 18 months. I'm sure Tangosol has a similar number of people. These are complex beasties and I wouldn't enter in to it with out a hard think of where this is going.

I wouldn't only look at it from a performance point of view. Cost is an issue also. The database tier is typically the most expensive tier in a solution (box + db licenses). Caching can reduce the load on that tier and signficantly lower it's cost as a result. It may or may not improve performance from a response time point of view, but the system will cost less. It's not always about absolute performance, everything comes at a price.

Billy (IBM)
http://www.billynewport.com

[Colin Yates]

And (just to be controversial), are you sure you *need* caching.... I have found sometimes that caching is just a plaster to hide an inefficient design

flame away

[katentim]

Buy something, don't build it.

..or use a free framework. You might want to check out JBoss TreeCache.

[croco]

or OSCache ...