I've got a number of treats for you guys today.
Firstly, I've just released 3.0.0 BETA1. The public API is finally stable and all major features are in. A few minor bugs and performance tweaks (and documentation) pending, this is pretty much what Naga will look like. Expect it to rock your world! ;)
Second, after much discussion with the community, I have decided to make Naga API compatible with 2.x releases (Poblano, Alegrias and Habanero). This means a somewhat more cluttered API and a pile of old, deprecated methods, but at least it means you can just drop in a Naga jar into an app compiled against 2.x and expect things to work. You could then update your code to use more "current" APIs at your leisure. Keep in mind though that Naga runs with MVCC by default. If you wish to use PESSIMISTIC locking (the previous default) please make sure you specify this explicitly in your config file.
Finally, at long last, I have pretty pictures for people. Benchmarks comparing 3.0.0.BETA1 against 2.2.0.GA (released just last weekend), and 2.1.1.GA. And, for kicks, against the latest EHCache release as well. So far I just have the standalone benchmarks. Expect replicated benchmarks coming your way very soon.
The release
So, lets get started. Download the release in the usual place, feedback on the forums please. The more feedback the better, it helps us make JBoss Cache a better product. The changelog is in JIRA.
Notable features include:
- a new batching API (JBCACHE-991)
- the ability to persist transient state upon startup when fetchPersistentState is false (JBCACHE-131)
- redesigned eviction, where you can now provide not just policies on how to select nodes for eviction, but also how that eviction behaviour is manifested (JBCACHE-1398). In plain English, this means you can now set the cache up such that nodes are completely removed upon eviction.
Benchmarks, part 1 : Standalone (LOCAL mode) benchmarksAs for benchmarks, these were generated using the Cache Benchmark Framework that I wrote. I actually encourage people to
download the framework and perform these benchmarks on their servers as well to help validate my numbers. The benchmarks were performed on the JBoss clustering lab, with the following configuration:
- Server running RHEL 4 and Sun JDK 1.5.0_11 with default settings
- Max heap size of 2GB
- 4 Xeon CPUs with 4GB of RAM
These benchmarks were measured using simple puts and gets on random keys and values, with
20% write and
80% read, using
25 concurrent threads. The test was performed over a sample size of
10 million operations.
Read (GET) performance
(smaller is better)Write (PUT) performance
(smaller is better)
As you can see, JBoss Cache is still a
very viable standalone in-memory cache, which is highly concurrent. With
Naga, this is even more so, given the huge performance gains realised thanks to our
MVCC implementation.
Expect to see replicated benchmarks here very soon. In the meanwhile, enjoy
Naga's first beta and let us know what you think!
Cheers
Manik