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