[infinispan-dev] [infinispan-internal] Performance based on contention

[Manik Surtani]

This is great stuff, Radim.

Awesome work Mircea and Sanne, on the non-tx case. This really seems to have paid off. 

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?

- M

Sent from my mobile phone

On 4 Jan 2013, at 09:23, Radim Vansa <rvansa at redhat.com> 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
> 
>