[infinispan-dev] DataContainer performance review

[Vladimir Blagojevic]

On 11-06-30 6:08 AM, Mircea Markus wrote:
> On 30 Jun 2011, at 01:18, Vladimir Blagojevic wrote:
>
>> Hey, good news!
>>
>> I have found that a main culprit of a poor DataContainer performance for
>> large caches (100K entries +) is in fact use of default concurrency of
>> 32.
> Does that cause BCHM to create only 32 segments, that resulting in lots of contention on concurrent updates?

Yes, only 32 segments! Much of that performance impact in BCHM comes 
from node tracking overhead per segment (queues, lists etc etc) as well. 
When we increase segment count this overhead falls substantially. CHM 
performs well with both 32 and 512 segments under these tests. It is 
just that BCHM basically grinds to a stop for large caches if we have 32 
segments only.

>> If users are going to use caches with many entries then they should
>> also increase concurrency level. I found that concurrency of 512 works
>> fairly well for caches up to million entries. Also note that if users
>> are using such large caches (1M+ entries) I do not see the point of
>> having eviction, they should just use unbounded DataContainer.
> I'm not sure this is true for all use cases: e.g. 1M Integers occupy cca 4Mb, and people might want to allocated up to Gb to cache data.
> What I think we can do is suggest them(log), based on the  DC size, to increase the concurrencyLevel when needed.

True, both of these parameters (object size and object count) should be 
considered!