What's Up With Ehcache 2.4
Ehcache is the de facto caching standard for Java that everyone uses (500,000+ production deployments; the majority of enterprise Java applications). Ehcache 2.4 is coming out soon and includes some capabilities that will make it even easier to use, more powerful, while still maintaining it's light weight.
The highlights include:
- Search - Quickly find entries based on the criteria of your choosing. String matching, dates, ranges, sums, averages etc.
- Fast local transactions - Improved performance of JTA and added a new non-jta transaction api for user level control
- Even more capacity and performance
What I've been Testing
I've written before about BigMemory for Enterprise Ehcache and how it solves the problem of long, unpredictable GC pauses in Java. The first release of BigMemory was… well, big. In Enterprise Ehcache 2.4, BigMemory has gotten even bigger.
Using the Enterprise Ehcache Big Memory Pounder I was able to show that Enterprise Ehcache 2.4 now easily handles:
- Entry Count: > 2 billion entries (I reached 2 billion on the hardware I had; with bigger hardware, I could probably have gone much higher).
- Throughput: 1.3 million operations per second (symmetric read and write; CPU bound)
- SLA/Predictability: No GC pauses and a predictable 38-42 ops/thread/millisecond throughout the test
- Data Size: 1-350 GB in-memory cache (again, I was limited by the hardware I had; with more RAM, I could probably have gone much higher)
- Flexible Efficient Entry Sizes: The cache can now dynamically handle very large (10-100 MB) and very small entries (just a few bytes) together more efficiently with no tuning (This test used small entries in order to fit as many entries as possible into the memory I had. I also ran tests with fewer entries in order to validate wide ranging sizes)
- Tuning: All tests were done with NO TUNING. Right out of the box.
Here's the hardware and software stack I used for my testing:
Cisco UCS C250 Server
Dual Intel x5670 2.93 Ghz CPU
384 GB RAM ( 8 GB x 48)
Redhat 5.4 Enterprise Edition
Sun JDK 1.6_22
For this test, all of the data was in memory.
A Bit About Ehcache BigMemory
BigMemory is 100% pure Java and in process with a Java application. No magic or special JVMs (works on IBM and JRocket as well). The cache data is safely hidden away from Java GC and the pauses that occur with large heaps by instead storing data in a BigMemory off-heap store.
Embedding
BigMemory got it's start as a component in the Terracotta Server Array and as a result it is particularly useful for embedding. It's performance characteristics and no tuning approach improves "The Out Of The Box Experience" and saves money on support by removing tuning required by users and problems caused by GC pauses.
You may be thinking...
"I don't have 2 billion entries in my caches?"
That's ok. Ehcache is a lightweight core library (under 1MB) for caching that's ubiquitous and easy to use. When it's needed, Ehcache lets you scale up and out to billions of entries and terabytes of data. It does so at a manageable server density without changing code/architecture and without a bunch of tuning and learning. This protects not only your knowledge investment but your code investment.
More about BigMemory for Enterprise Ehcache:
http://terracotta.org/bigmemory
More about the 2010 Ehcache user survey:
Ehcache User Survey Whitepaper
Posts
5 comments:
Was this a test with the open-source Ehcache version or DX/EX? It looks like these tests were all done within a single JVM with an in-memory Ehcache instance, is that correct? Are there metrics that compare performance for given cache sizes across the different versions/strategies?
Hello,
These tests were done using Ehcache core ee 2.4 beta2 (enterprise version of ehcache standalone) using BigMemory (One process and all in memory). The pounder I used is open source and highly configurable to try what ever one wants. It's linked to the blog.
Hope this helps
Cheers,
Steve
Symmetric read/write means write after read or 50-50 read/writes?
Hi, when I said symmetric read/writes I mean that the performance of read operations and write operations are the same. In other words, in my testing, access to off heap has the same performance for both reads and writes so the mix has almost no impact.
Thanks, these (1.3M) number is pretty consistent with my own (690K, but for less powerful server). The most interesting part of all of this is the fact that pure on-heap works faster (900K) than BigMemory for caches up to 30G in size, but there are occasional GC pauses up to 70 secs.
Post a Comment