| | As for the low contention cases, I think they're all about the same | as the probability for contention is all very low given the number | of threads used. Perhaps if these were cranked up to maybe 50 or 100 | threads, you'd see a bigger difference?
Right, I think that there should be no difference between 24k and 80k, but as you can see in the no-tx case there was some strange behaviour so I added one more case to see the trend in the rest of results. Perflab was bored during xmas anyway ;-) Nevertheless the overall result is pretty surprising for me, as infinspan can handle contention so smoothly that except for really extreme cases (as number of keys == number of threads) contention rather improves the performance (Is there any explanation for this? Some memory caching stuff keeping the often accessed results still occupy near-CPU caches? Can this really affect such high-level thingie as ispn?). Radim | On 4 Jan 2013, at 09:23, Radim Vansa <[email protected]> wrote: | | > Hi, | > | > I have created a comparison how JDG (library mode) behaves | > depending on the contention on keys. The test runs standard (20% | > puts, 80% gets) stress test on different amount of keys (while | > there are always 80k keys loaded into the cache) with 10 | > concurrent threads on each of 8 nodes, for 10 minutes. Regarding | > JVM heating there was 10 minute warmup on 80k shared keys, then | > the tests were executed in the order from the table below. TCP was | > used as JGroups stack base. | > | > The variants below use pessimistic transactions (one request per | > transaction), or no transactions in 6.1.0 case (running w/o | > transactions on JDG 6.0.1 with high contention wouldn't make any | > sense). The last 'disjunct' case has slightly different key format | > evading any contention. Before the slash is number of reads per | > node (sum for all 10 threads) per second, the latter is number of | > writes. | > | > Accessed keys | JDG 6.0.1 TX | JDG 6.1.0 TX | JDG 6.1.0 NO TX | > 80 | 18824/2866 | 21671/3542 | 22264/5978 | > 800 | 18740/3625 | 23655/4971 | 20772/6018 | > 8000 | 18694/3583 | 21086/4478 | 19882/5748 | > 24000 | 18674/3493 | 19342/4078 | 19757/5630 | > 80000 | 18680/3459 | 18567/3799 | 22617/6416 | > 80k disjunct | 19023/3670 | 20941/4527 | 20877/6154 | > | > I can't much explain why the disjunct sets of keys have so much | > better performance than the low contention cases, the key format | > is really just key_(number) for shared keys and | > key_(node)_(thread)_(number) for disjunct ones (and the rest of | > the code paths is the same). The exceptionally good performance | > for 80k keys in non-tx case is also very strange, but I keep | > getting these results consistently. | > Nevertheless, I am really happy about the high performance increase | > between 6.0.1 and 6.1.0 and that no-tx case works intuitively (no | > deadlocks) and really fast :) | > | > Radim | > | > ----------------------------------------------------------- | > Radim Vansa | > Quality Assurance Engineer | > JBoss Datagrid | > tel. +420532294559 ext. 62559 | > | > Red Hat Czech, s.r.o. | > Brno, Purkyňova 99/71, PSČ 612 45 | > Czech Republic | > | > | _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
