Writing to the same the subtree is not an issue. Trying to update the same entry at the same time might slow it down a bit. The access log "etime" result(microsecond logging) will tell you more during these bulk updates.We have a customer that has been multi-threading behind multiple servers and writing to our Master server. These writes come in the form of heavy spikes (1k over 5 second intervals) very much burst traffic and all the writes are adding new items to the same ou. While we have plans to throttle them I had a few questions:a) If they're writing to the same ou / updating the same indexes are they blocked on one items success before another succeeds?
This setting usually doesn't need to be adjusted, as the performance impact is not related to the number of threads, but what is being updated in the db. Look at the "cn=monitor" output for the backend(e.g. cn=monitor,cn=example,cn=ldbm database,cn=plugins,cn=config). You really want the cacheHitRatios to be as close 99% as possible. Then adjust the cache sizes if needed.So in this case multi threading behind multiple boxes does not give them any performance impact. I would guess this is the case, but I want to be sure. Because replication seems to be fine which goes through a single thread iirc.b) are there any performance tweaks that can help? I thought maybe looking at nsslapd-threadnumber.
-Jeff
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- Mark Reynolds 389 Development Team Red Hat, Inc mreynolds@redhat.com