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 https://www.opends.org/wiki/page/Caching https://www.opends.org/wiki/page/AdvancedProperties#section-AdvancedProperties-LocalDBBackend and then for further tuning you can tweak https://www.opends.org/promoted-builds/latest/OpenDS/build/docgen/configuration_guide/ldap-connection-handler.html#num-request-handlers https://www.opends.org/promoted-builds/latest/OpenDS/build/docgen/configuration_guide/traditional-work-queue.html#num-worker-threads 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.