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
