Description of problem: Lock contention on the connection mutex between listening thread handling the network events and the worker threads handling the ldap operations sometime impacts the global server performance. How reproducible: Setup an instance (named standalone1) and having suffix dc=example,dc=com with default tests entries generated by dscreate" Run: dsconf standalone1 config replace nsslapd-accesslog-level=4 (To turn off the log of standard operations and turn on the log of internal operations) Run: ldclt -p 389 -e esearch -b "dc=example,dc=com" -f "cn=demo" In another windows run a loop on: ldapsearch -Q -LLL -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-standalone1.socket -b dc=example,dc=com cn=demo Actual results: Then you should see the ldclt performance dropping significantly: ldclt[416127]: Average rate: 14371.20/thr (14371.20/sec), total: 143712 ldclt[416127]: Average rate: 14527.00/thr (14527.00/sec), total: 145270 ldclt[416127]: Average rate: 8274.10/thr (8274.10/sec), total: 82741 ldclt[416127]: Average rate: 4551.20/thr (4551.20/sec), total: 45512 ldclt[416127]: Average rate: 4191.30/thr (4191.30/sec), total: 41913 Expected results: Should not have a significant performance drop. Additional info: Problem is very similar to the BZ 2224505 issue but when doing a SASL bind with EXTERNAL method instead of a paged result search and was first detected during code review when looking for other piece of code that may have the same contention issue. But the impact is much less serious: usually not perceptible with standard default configuration. (I needed to slow the internal operations (by enabling the log of these operation) to see clearly the performance impact.