Distributed Cache gets are very time consuming!!!!!

Question

We have an application that uses Coherence as a distributed partitioned cache server.
Our problem is that the access to the near cache is very fast but the access to the remote servers is very cpu consuming (maybe for the deserialization of the objects retrieved) at such point that disabling the cache and reading the objects directly from the dbms (Oracle) improves the performances.
We use coherence as the second level cache of hibernate so we have not much control on how hibernate serialize and deserialize it's objects (we cannot implement a custom externalization).
Have you any experience of performance problems with the combination hibernate/tangosol and distributed cache?

Answer 1

Hi Giancarlo,
It's Jon, not Cameron ;)
The Hibernate cache API (including 3.0) does not support bulk-fetches from cache, which means that these cache fetches are serial rather than parallel. Depending on how much of your performance problem is network related, Coherence may actually perform much better than straight JDBC as the application load increases (time per request will remain similar, but won't increase much under heavier load).
The advantage to using the Coherence API (rather than Hibernate API) is that you have far better control over how your queries run. The drawback of course is that you have to code your own queries if they become more complex than search queries. As a result, it often makes sense to use Hibernate (or equivalent) for the bulk of your queries, then code specific queries directly against Coherence when performance really matters. A simple example of this is the ability to perform bulk gets (using <tt>NamedCache.getAll()</tt>). With queries that return hundreds or thousands of items, this can have a huge impact on performance (an order of magnitude or more depending on object complexity). You also get the ability to use XmlBean/ExternalizableLite and cluster-parallel search queries.
As an aside, with the Coherence cache servers, you should avoid making your JVM heaps excessively large. As a general rule of thumb, we recommend a 512MB heap size for cache servers, using as many instances as required to reach your desired cache capacity. Also, from what I've seen, 64-bit JVMs are less efficient with memory usage than 32-bit (though performance seems a bit better on the x86-64 platforms vs the 32-bit versions).
Jon Purdy
Tangosol, Inc.