[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: concurrency tests

dont bother too much with entry caches unless you can squeeze your
entire dataset into the cache or your test/s iterate over some
portion of your dataset that fits into the cache nicely [ which is
not the case here with your test/s ]. otherwise you gonna get alot
of GC churn that gonna offset any cache gains. the other use case
would be heavy objects like groups since we do have very flexible
cache config so you can target specific things for cache retention.
best thing you can do is allocate as much as you can to BDB cache,
maybe do a pre-load as well
and then for further tuning you can tweak
to get the most out of your specific h/w. write and mixed load
tuning is more complex than that tho and you are welcome to ask
about any of that further on OpenDS mailing lists of course.

On 13/08/2010 23:30, Howard Chu wrote:
Also for comparison I've done a run against OpenDS 2.3.0 build 3, using
Sun JRE 1.6. I'm very impressed with OpenDS's results; I configured the
jvm with 32GB of heap and it only used 17GB but returned very good
performance. Aside from allocating a few GB for the BDB cache it's
basically in stock tune. (Also with access logging disabled for these
runs.) I didn't try yet with entry caching enabled; in previous runs I
had poor experience with entry caching. I guess I should ask on the
OpenDS forums for further tuning advice.