On 09/06/2018 07:50 AM, isabella.ghiu...@nrc-cnrc.gc.ca wrote:
This does not justify this since running 1 tread takes 0.1564msec/op and running 10 threads takes 0.0590ms/op
Yes, but that's an average. Running 10 threads doesn't make individual searches take less time.
When you're running just one thread, you're getting the result of one CPU core. When you increase the number of threads in rsearch, the server will use more CPU cores. You'll see more searches completed in the same amount of time, which rsearch will report as a lower average time/op. When you increase threads enough to saturate the CPU cores in the server, then average time will start to increase again.
and the last one will require the access.log to be flush more frequently I think for 10 threads and I do not see the spike in exec time showed for 1 thread. Maybe something else ?
With access logging enabled, I see similar spikes in search time reported by rsearch. When I turn access logging off, I don't. Try it yourself and see if you can reproduce the behavior you reported:
# ldapmodify -h localhost -D 'cn=Directory Manager' -W dn: cn=config changetype: modify replace: nsslapd-accesslog-logging-enabled nsslapd-accesslog-logging-enabled: off _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
