[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3665) Multi-Listener Thread Support

Looks interesting, but I'm not able to test it at the moment. Also my main machines are single-CPU and I expect this won't have much visible impact without a multi-CPU system. Hopefully some other folks will try it out.

Reading the diff, I'm a little confused by the WAKE_LISTENER handling. Perhaps it would make sense after I apply the patch and read the resulting file. Also at the moment it appears that all of the listener threads will manipulate the slapd runqueue, and that is probably not a good idea.

Overall I'm not totally convinced that this is the right place to be dividing the labor. It would make more sense to me to keep the single listener, and hand off each triggered event to the thread pool, so that reading and parsing is multithreaded. The only time splitting the listeners would offer any benefit over a single listener is if they were actually multiple processes with independent descriptor sets, in which case each process could handle a reasonablly large number of connections without the performance degradation of a single process select()ing over thousands of descriptors. (And I'm definitely not suggesting we go there.) For now the diff strikes me as overly complicated, with the multiple sets of event controls.

slim@us.ibm.com wrote:

In order to make slapd more responsive and resilient, this patch enables the
multi-listener thread support in slapd.

The current slapd has a single listener thread and multiple operation threads.
The listener thread deals with 1) accepting incoming TCP connections and
initializing connection management data structures, 2) processing all incoming
LDAP requests, 3) waking up blocked operation threads. Moreover, most part of
the thread code is serialized. In this architecture, if the execution of the
listener thread gets stuck by the connection to an abnormal client, it will
stall the processing of other normal connections immediately. Alternatively, if
the listener thread is unable to grab CPU as soon as the blocked operation
thread becomes ready to wake up, the execution of the thread will be delayed,
increasing the response time.

So by introducing the multi-listener threads support which simply duplicates the
single listener as many as it is configured, we can not only achieve more
parallelism in the connection management of slapd but also make it responsive
and resilient to various exceptional behaviors of clients. In this multi
listener thread patch, each listener thread manages its own slapd_control which
has I/O event structures for epoll or select. The number of listener threads can
be configured in slapd.conf as follows,

numListener x

This patch has been tested for both epoll and select and passed all test
scripts. I am currently working on measuring performance and developing a load
balancing routine among listener threads.I appreciate any comments to the
patch.








--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support