Re: [infinispan-dev] DataContainer performance review

Hi Vladimir, this looks very interesting, I couldn't resist to start some runs. I noticed the test is quite quick to finish, so I've raised my LOOP_FACTOR to 200, but it still finishes in some minutes which is not long enough IMHO for these numbers to be really representative. I've noticed that the test has some "warmup" boolean, but that's not being used while I think it should. Also, the three different operations need of course to happen all together to properly "shuffle" the data, but we have to consider while interpreting these numbers that some operations will finish before the others, so some of the results achieved by the remaining operations are not disturbed by the other operations. Maybe it's more interesting to have the three operations run in a predictable sequence? or have them all work as fast as they can for a given timebox instead of "until the keys are finished" ? Here where my results, if any comparing is useful. To conclude something from this data, it looks to me that indeed the put operations during LIRS are having something wrong? Also trying to add more writers worsens the scenario for LIRS significantly. When running the test with "doTest(map, 28, 8, 8, true, testName);" (adding more put and remove operations) the synchronizedMap is significanly faster than the CacheImpl. Performance for container BoundedConcurrentHashMap Average get ops/ms 1711 Average put ops/ms 63 Average remove ops/ms 1108 Size = 480 Performance for container BoundedConcurrentHashMap Average get ops/ms 1851 Average put ops/ms 665 Average remove ops/ms 1199 Size = 463 Performance for container CacheImpl Average get ops/ms 349 Average put ops/ms 213 Average remove ops/ms 250 Size = 459 Performance for container ConcurrentHashMap Average get ops/ms 776 Average put ops/ms 611 Average remove ops/ms 606 Size = 562 Performance for container SynchronizedMap Average get ops/ms 244 Average put ops/ms 222 Average remove ops/ms 236 Size = 50000 Now with doTest(map, 28, 8, 8, true, testName): Performance for container Infinispan Cache implementation Average get ops/ms 71 Average put ops/ms 47 Average remove ops/ms 51 Size = 474 Performance for container ConcurrentHashMap Average get ops/ms 606 Average put ops/ms 227 Average remove ops/ms 246 Size = 49823 Performance for container synchronizedMap Average get ops/ms 175 Average put ops/ms 141 Average remove ops/ms 160 As a first glance it doesn't look very nice, but these runs where not long enough at all. Sanne 2011/6/26 Vladimir Blagojevic<vblagoje(a)redhat.com>: > Hi, > > I would like to review recent DataContainer performance claims and I was > wondering if any of you have some spare cycles to help me out. > > I've added a test[1] to MapStressTest that measures and contrasts single > node Cache performance to synchronized HashMap, ConcurrentHashMap and > BCHM variants. > > > Performance for container BoundedConcurrentHashMap (LIRS) > Average get ops/ms 1063 > Average put ops/ms 101 > Average remove ops/ms 421 > Size = 480 > Performance for container BoundedConcurrentHashMap (LRU) > Average get ops/ms 976 > Average put ops/ms 306 > Average remove ops/ms 521 > Size = 463 > Performance for container CacheImpl > Average get ops/ms 94 > Average put ops/ms 61 > Average remove ops/ms 65 > Size = 453 > Performance for container ConcurrentHashMap > Average get ops/ms 484 > Average put ops/ms 326 > Average remove ops/ms 376 > Size = 49870 > Performance for container SynchronizedMap > Average get ops/ms 96 > Average put ops/ms 85 > Average remove ops/ms 96 > Size = 49935 > > > I ran MapStressTest on my Macbook Air, 32 threads continually doing > get/put/remove ops. Fore more details see[1]. If my measurements are > correct Cache instance seems to be capable of about ~220 ops per > millisecond on my crappy hardware setup. As you can see performance of > the entire cache structure does not seem to be much worse from a > SynchronizedMap which is great in one hand but also leaves us some room > for potential improvement since concurrent hashmap and BCHM seem to be > substantially faster. I have not tested impact of having a cache store > for passivation and I will do that tomorrow/next week. > > Any comments/ideas going forward? > > [1] https://github.com/infinispan/infinispan/pull/404 > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev