Re: [infinispan-dev] DataContainer performance review

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.