« Debit/Credit application using partitioning | Main | Google, partitioning and replication »

March 26, 2006

The advantages of remote caches versus local caches

Normal caches are simple in-process affairs. These caches are pretty simple. Usually, they are arranged in a peer to peer fashion if clustered. JMS can be used to push asynchronous invalidation messages between peers to keep the caches kind of up to date.

The problems with these caches can be summarized to the limited size of the cache, the impact to garbage collection on the application and startup/cache warming.

Cache size is restricted and GC pauses
These caches are constrained to only caching objects that can fit in the available memory of the JVM. This JVM hosts the application server, the application and the objects used normally by the application. If the application needs to cache more data than will fit in memory then we're out of luck. Plus, the cache adds more objects to the already full application JVM heap. This can cause longer than acceptable garbage collection pauses if the cache is large. Newer JDKs like Java 5 don't really help with this as the objects in the cache can be long tenure objects and if even a small percentage of the cached objects change frequently then you'll see JVM pauses as the long tenure heap is compacted.

JVM startup cause backend spikes
JVM startup is also a problem as the cache will not have the data in memory and this can cause a spike type load on the backend while the cache warms up which can take a while. If there are several JVMs running on a cluster then worst case backend load is seen when the cluster starts.

ObjectGrid as a flexible solution

ObjectGrid can be used as a simple in memory cache is thats whats needed. But, it can also run in a multi-tier cache. This usually means the application uses the ObjectGrid client jars to communicate with a remote ObjectGrid server.

The ObjectGrid client has full local cache capabilities and it can place a local or near cache in the JVM. The size of this can be tuned to only cache recent data or limit the age of this data. Data not present in this near cache is fetched from the remote cache. The remote cache can be partitioned or run in 64 bit JVMs allowing very large data sets to be cached.

As data not present in the ObjectGrid near cache is fetched from the remote ObjectGrid server then local misses now pull from the ObjectGrid and not the backend. This helps greatly with the startup scenarios as the ObjectGrid server takes the load rather than the backend. This is usually a better place to take the load than the backend. The remote ObjectGrid server can be replicated so that if it fails then we also don't get a backend spike as it will fail over to the replica.

A remote cache tier has many advantages over simple local in memory caches. Applications using the ObjectGrid for caching can easily switch to a remote cache rather than a local one with configuration changes only. Such a hybrid cache using a near cache and a remote cache can be very good behavior in the edge cases such as application start as well as allow very large cache sizes through partitioning.

March 26, 2006 | Permalink


Does ObjectGrid come with WAS6 (if yes which one)? I'm really curious to evaluate it.

Especially to see how it performs in comparison to Coherence cache.

Would be nice performance research project.

Posted by: Ruslan Zenin | Apr 4, 2006 10:12:33 AM

ObjectGrid comes with WebSphere XD. You get it with a full XD install or you can install just the ObjectGrid with the Mixed Server Environment option. The MSE install gives us just the jars and then you can use it with any J2SE or J2EE environment.

Posted by: Billy | Apr 6, 2006 10:44:18 AM

Post a comment