hibernate second level cache is slow

Question

I am using hibernate second-level caching with in-memory ehcache, and it is slow. I mean, not slower than SQL, but not really faster either given a fast database on an SSD. The actual speed increase is less than a factor of 2, and sometimes unnoticeable.

It seems that others had the same problem, but got no answer: http://forum.spring.io/forum/spring-projects/data/44353-hibernate-second-level-caching-slow-no-really-slow https://forum.hibernate.org/viewtopic.php?t=985913

After some profiling, it seems that hibernate always de/re-hydrates the cache elements, instead of directly storing them, which leads to this abysmal performance (over a factor of 100 compared to direct use of ehcache).

So, my questions are:

• Can hibernate store and restore the cached objects directly?
• Is there some other way to speed up the second level cache?
• Is there a relatively simple alternative mechanism for faster hibernate caching?

Answer 1

Can hibernate store and restore the cached objects directly?

No, it can't, because that would mean that concurrent sessions would use the same object instances, thus stepping on each other toes.

Is there some other way to speed up the second level cache?

There are probably thousands of ways to speed it up. Most of them depend on the specific requirements of your application.

Is there a relatively simple alternative mechanism for faster hibernate caching?

No, at least not for the time being.

Answer 2

This is an old question but other people seem to have performance issues with Hibernate + Ehcache. I took me a while to figure out the problem so I'm adding what I found here, hopefully this might help someone.

The JCache/JSR-107 specification says that by default caches must store by value while Ehcache defaults to store by reference . When using Ehcache 3, Hibernate uses the jcache interface so Ehcache enforces the specification by using a serializing copier: before storing any key or value, they are serialized in a byte buffer. This operation takes quite a few CPU cycles for each cache get() and each put().

Ehcache switches to store-by-reference (ie essentially put the objects straight into the cache) when the default copier is the IdentityCopier , see the source of CompleteConfiguration .

So in order to avoid the serialization/deserialisation, I added a default-copiers element to my ehcache.xml:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ehcache.org/v3" xmlns:jsr107="http://www.ehcache.org/v3/jsr107">

    <service>
        <jsr107:defaults enable-management="false" enable-statistics="false" default-template="default" />
    </service>

    <default-copiers>
        <copier type="java.lang.Object">org.ehcache.impl.copy.IdentityCopier</copier>
    </default-copiers>
    
    <cache>...</cache>
    <cache-template name="default">...</cache-template>
</config>

Answer 3

Have you figured out the Hibernate second level cache performance issues?, in some application diskPersistence and overFlowToDisk were on and noticed clone/serialization/deserialization in TRACE logs. Don't see why Hibernate/Ehcache had to clone/deserialize local JVM objects again.

Answer 4

We have this problem, too. If you store and retrieve many objects from the 2nd Level cache you must take into account the time for hydration and dehydration.

It is not cheap. But it is needed as you can't put the real entity into the 2ndLC. First the object is bound to the session and might have some proxies and other hibernate magic stuff. Second the object would be shared across multiple sessions/transactions. So you could "see" the changes another session is doing concurrently. Therefore hibernate hydrates and dehydrates.

What we have done to have a faster solution in some circumstances: We build a "Third Level Cache" with Spring @Cacheable, where we place DTOObjects (DataTransferObject as we call it) which are read-only. So if we have a Member entity we have a MemberDTO which is the object for the third level cache. It is mostly a copy of the real entity just for caching reasons.