It's looking like using a single mutex-controlled thread pool is a major
bottleneck in the slapd frontend. Thinking it over, I've hit a number of
different ideas but nothing without drawbacks.
Ideally we would get rid of the distinction between listener threads and
worker threads, and only have worker threads. Each thread would be responsible
for a fraction of the open sockets, and service them directly instead of
queueing work into a thread pool. This would essentially mimic the behavior of
SLAPD_NO_THREADS, just duplicated N times.
The upsides of such an approach are numerous; a whole slew of locks completely
disappear from the design and we'd be keeping work local to the CPU that
originally received a request. The obvious downside is that Abandon/Cancel ops
would never be useful (as they currently are not useful in single-threaded
slapd). I.e., since the thread responsible for a connection will always be
occupied in actually processing an operation, it will never come back to read
the next request on the connection (e.g. Abandon) until the current op is
A possible solution to that would be to always do a quick poll in
send_ldap_response() etc. to check for new requests on a connection before
sending another reply.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/