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

[Radim Vansa]

| 
| 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 <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
| > 
| > 
|