Ehcache Server provides a RESTful API for cache operations. I am working on v0.9 and have been doing some performance benchmarks. I thought it would be interesting to compare it with the performance of that other over-the-network cache, Memcache. Now I already knew that Ehcache in-process was around 1,000 times faster than Memcache. But what would the over-the-network comparison be.
Here are the results:
Memcache and SpyMemcache Client10000 sets: 3396ms10000 gets: 3551ms10000 getMulti: 2132ms10000 deletes: 2065msEhcache 0.9 with Ehcache 2.0.010000 puts: 2961ms10000 gets: 3841ms10000 deletes: 2685ms
So, the results are a wash. Memcache is slightly slower on put, maybe because the JVM does not have to malloc, it already has the memory in heap. And very slightly faster on get and delete.
A few years ago there was a raging thread on the Memcache mailing list about Memcache versus MySQL with in-memory tables. They were also a wash. I think the point is that serialization and network time is more significant than the server time, provided the server is not that much different. And this is what we see with Ehcache.
And now for the implications:
- REST is just well-formed HTTP. Just about any programming language supports it. Without having to use a language specific client, like you need to do with Memcache. Ehcache Server was the first Java cache to support the REST API. But many others have followed. Why? It is a really good idea.
- Performance wise, REST backed by a Java App Server and Cache, is about as fast as Memcache.
- Therefore, your decision on what to use should depend on other things. And Memcache is no-frills. If you chuck Terracotta in behind Ehcache (we are one company now after all) then you get HA, persistence, and coherence expressed how you like, as a guarantee that you any reading the last write or more formally in XA transactions.
Finally, I will be giving a Webinar in a few weeks where I compare Ehcache and Memcache.
8 comments
Comments are closed.