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

| Views: 92
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

Have comments or feedback on what I wrote? Please share them below! Found this useful? Consider sending me a small tip.
comments powered by Disqus
Other posts you may like...