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. 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 am also looking to chart these for easy review, forum post, and
DataContainer performance tuning wiki. Tomorrow I'll determine impact of
passivation on DataContainer performance.
Cheers,
Vladimir
On 11-06-28 10:20 AM, Vladimir Blagojevic wrote:
On 11-06-28 10:06 AM, Galder ZamarreƱo wrote:
> Vladimir,
>
> I think it's better if you run your tests in one of the cluster or perf machines
cos that way everyone has access to the same base system and results can be compared,
particularly when changes are made. Also, you avoid local apps or CPU usage affecting your
test results.
>
> I agree with Sanne, put ops for LIRS don't look go in comparison with LRU. Did
you run some profiling?
>
Hey,
Very likely you are right and it is a better approach but it does not
take much to notice a trend of deteriorating BCHM performance for large
map/cache size. Looking to do some profiling now.
Cheers
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev