EhCache vs Memcached caching for JEE Applications

Caching is a building block of modern JEE applications. In order to handle any significant load you will need to establish a 2nd level cache. Let's just clear a common confusion. A 2nd level cache is not the same as the cache implemented by databases. Those are 1st level caches and they usually cache data blocks, not specific objects. 2nd level cache is the cache implemented outside of the database.

In the JEE world caching is specified by the the JCache JSR. The two major open source providers of caching are TreeCache from JBoss and EhCache. Both allow the creation of a distributed cache and provide built in mechanisms to deal with dirty data. Also, both libraries work with Hibernate as 2nd level cache providers.

I have had good experiences with both libraries as an architect. The overhead of both libraries is small and they both implement JCache making them interchangeable. Both, EhCache and TreeCache work in the same JVM as the application server. Surprisingly, in the last few months I have encountered more and more JEE applications using Memcached instead of EhCache or TreeCache.

Memcached is a C++  program that acts as a 2nd level cache. It is the default standard for caching in the LAMP stack. Wikipedia and Facebook base their entire caching infrastructure on Memcached. Besides that, Memcached has APIs for PHP, Perl, Ruby and of course Java. Memcached can also work as cache inside MySQL to keep tables in memory. The Java APIs are pure Java APIs. Memcached also has a distributed mechanism implemented via smart hashing.

I can understand using Memcached in a JEE application to access Memcached infrastructure that many LAMP applications are using. But, to use Memcached as the first option for a JEE application just seems strange to me for the following reasons:

• The Memcached Java APIs are not JCache compliant. Which means you can't change your mind about them later on without paying a major price.
• The application server needs to connect to the Memcached process via sockets calls. This requires the serialization and transmission of objects between processes. Something avoided with the Cache being inside the application server.
• The JCache solutions just appear to be much faster with Java.

In order to see if my last point was valid I ran a small test. In a Linux dual core box with 4 Gigs of memory, I created a small Java application that tested both options. The application is a just a simple engine that puts and gets objects from the cache. The objects that it puts are a simple class representing personal information.

Memcached was running in the same machine as the Java program doing the testing. I first started by testing 10000 puts and 10000 gets. Then I moved to 20000 puts and 20000 gets. I kept doing the same until I got to 100000 puts and gets. I measured the average time in milliseconds to do 10000 puts and 10000 gets from the cache. I compared the results of the Memcached test against running the same test for EhCache. The object I was placing in the cache was exactly the same in both cases, and the engine did not know what type of cache it was using due to an abstraction. I used the spymemcache Java API for Memcached.

These are the results. The numbers represent the average time it takes to perform 10000 puts or 10000 gets in milliseconds.

	EhCache	Memcached
put	31	545
get	16	2072

As we can see EhCached is one order of magnitude faster for put operations and two orders of magnitude faster get operations.

I was planning to do a more complete test using various caching servers to test the distributed capabilities of each solution. But, after the results I decided I had enough information. I believe that we should not use Memcached for a JEE application unless, there is a necessity to interact with an existing Memcached cache.

Please email me if you want the source code of my tests.

Links

EhCache

Memcached

Java API for Memcached   

Comments

no

[Hugo Troche]

No? You mean that you don't agree with the results or that I should do more extensive testing?

[googlebot]

You should have tried to run either caches on a separate machine, so your app server would access them via tcp/ip.
I believe memcached was so slow in your example because it used serialization and ehcache did not. Serialization is a serious bottle neck, you should consider using externalization instead.

[Hugo Troche]

Thank you for commenting. You are right, the equation is different when the cache is in a different machine that the application server.

The question then is: in a distributed cache environment, will Memcached be faster?

It could be an interesting test to try it out. On the other hand, the performance of the cache in the case where the cached object is in the same box as the application server will be orders of magnitude better. So, if the application has two servers, 50% of the cache calls should be local. If the application has 3, 33% should be local, etc. That along could be a big performance difference in the system. Also, EhCache does not distribute objects like Memcached and that would have to be taken into account. Again, without actually testing this is just speculation.

[vpupkin]

This comparison is not really clean. Memcached was designed to increase performance for multi-server enviroment, but not for only one JVM. For sure additional serialisation will produce additinal performance-leak, but...

...it is nothing in comparison with pure( for ex. ) database access. Try to improve your tests with 10000 DB-selects from 2,4,8.. different servers with and without both of caches...

and then pls share your test-resuls! ;)

[Doug]

Hi,
You are not comparing apple to apple here. EhCache is residing in the same JVM with your app server, memcached is not. I would said that in a distributed test, memcached would beat ehcache. But how to put EhCache in a distributed environment is a myth to me!

memcached is as much a *scaling* solution as it is a performance solution. This is like testing mapreduce using a single box.

[Steve]

As of today, ehcache's JCache page says,

"Ehcache provides a preview implementation of JSR107 via the net.sf.cache.jcache package."

AFAIK it's not yet standardised.

[Steve]

Another thing you don't mention is the GC churn caused by an in-process cache. With a large heap, this can be big performance problem. Use of an out-of-process cache can mitigate this problem.

[Sameer Charles]

To me this test just does not make any sense, a single box test on a highly scalable distrubuted caching system like memcached? hmm.

In addition I agree with Steve that JCache is not yet final and its "inactive" which means nothing happens there since 1.5 years. This basically means that either the expert committee is not able to agree on the spec or the spec reached a level where it has serious problems.

Personally I like ehCache implementation of JCache but this does not mean that I will just select it for any J2EE application.

[sreenath venkataramanappa]

What about TreeCache? TreeCache supports transactional caching which neither EHcache nor MemCache supports as of this writing...

[Cheap Computers Canada]

We get to learn the latest on the innovative technology through blogs.

[James Bowman]

As already said above, this is not a fair comparison. Whilst EHCache works well as a near cache (Hibernate level 2 cache) and supports the JCache specification, it does not as standard function as a distributed cache (see Coherence, Gigaspaces, Gemfire, Infinispan, etc.). In order to use EHCache as a distributed cache, it must be combined with another product called Terracota.

[Naidu Bs]

All my Caching needs are not always distributed cache. If your system architecture recommends to have a distributed ehcache then we need to compare between ehcache and memchached. Again this depends on type of distributed architecture. If it is a centralised cache is expected, then i would prefer go for memcahced.If it is requirement to replicate caching details between instances (though this is not exactly a disributed option - without any centralized cache), then i would go for ehcache/treecache.

If it is requirement to have a simple caching within a single instance of JVM, then memchached would have been a overhead compared to ehcache.

End of the day, I have never found a single solution in this world that can solve all my needs.

[Air Jordan]

The worst kind of love is the one when you want someone but you know you can’t have them. Best wishes for you.

[coach bags]

The blog is nicely done. Attractive written shows its quality. Keep it up in this way. Thanks a lot
http://coachhandbagsoutlets.com/
http://www.newchristianlouboutinshoes.com/

[BRYANRebekah35]

This is perfect that people can receive the home loans and this opens completely new chances.

[Retro Jordan]

I love the comparison you made between the colors! I'm personally looking forward to the Daffodil Delight as I'm a sucker for anything yellow. I wish it was more lemon-y! As for the Marina Blue, that'll be another favorite of mine I think! now link my name to see something about jordan shoes,they are also good and you will like them,come on!

[ugg boots outlet]

How great minds think alike.

[coach outlet]

I wish you great blessings and love.*

[ugg boots]

just go around, but surprised by your blogs, the information is so interesting,I deeply attract by it.

[Air Jordans]

Be to act , that each tomorrow.

[cheap air jordans]

I want to bring out the secrets of nature and apply them for the happiness of man . I don't know of any better service to offer for the short time we are in the world .

[Kids puzzle]

Everyear,when the Christmas coming ,the gifts is neccesery.So i think

[wholesale Juicy Handbags]

VENDO UM HOMEM INTERESSANTE:
Mulher fina : Muito simpático!
Mulher comum: Que homem liiiindo!
Mulher vulgar : Dessa fruta eu chupava até o caroço!
Mulher deprava : Ah, se eu pego... deixo ele fazer barba, cabelo e bigode.