Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

I've been working with Coherence quite a bit over the past few weeks so I got curious about how well its distributed cache schemes compare to one another. I decided to run a quick test to check how long put() operations took when using the replicated and optimistic cache schemes.

For the replicated scheme I ran a test both with locking and without locking. All tests used the standard java serialiser. The test itself was very straight forward, a loop that put unique String values into the cache, something like this...
 Java
for (int i = 0; i < iterations; i++) {
String key = "key" + i;
cache.put(key, key);
}


Caches were cleared between each run of the test and I collected 5 results for each iteration. The iterations were 100, 1000, 10000 and 100000 put() operations. These are the average timings to complete these (in milliseconds)...
coherencetiming1.png


The replicated scheme (without locking) was consistently about 2x slower when compared to the optimistic scheme. However with locking it was about 4x slower.

Even with these limited data points the numbers showed something interesting when plotted...
coherencetiming3.png


Each of the schemes scaled more or less linearly, even when locking was used on the replicated cache. Now these results are only for a single node Coherence cluster so may change as more clusters are added into the mix. This is something I plan to investigate some time in the future.

These tests were run on WebLogic 12.1 with the Coherence option installed.



-i

Skip down to comments...
A quick disclaimer...

Although I put in a great effort into researching all the topics I cover, mistakes can happen. If you spot something out of place, please do let me know.

All content and opinions expressed on this Blog are my own and do not represent the opinions of my employer (Oracle). Use of any information contained in this blog post/article is subject to this disclaimer.
 
comments powered by Disqus
Other posts you may like...