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

Re: HEADS UP Re: slapd lightweight dispatcher

At 05:55 PM 5/12/2006, Howard Chu wrote:
>Howard Chu wrote:
>>Quanah Gibson-Mount wrote:
>>>I've done a lot of testing in the last several days on a binary with the lightweight dispatcher code enabled (2.3 base), and I just want to say I'm a very big fan of it.  It allows slapd to scale under high load at a rate I've not previously seen.  I've also played with the multi-conn flag as well, and haven't seen it particularly affect the rates when only it is enabled, but I haven't tried the lightweight dispatcher without it being enabled at the same time.
>>>One thing I'll note about multi-conn is that it requires a variable in connection.c to be set to the number of cpu's on the system where slapd will be run.  I think this should instead be changed to a parameter in slapd.conf (slapd-cpus ??) so one doesn't have to have fixed slapd's for given systems.  That same parameter could be used for giving guidelines to slapadd/slapdindex as well, and the tool-threads parameter could be replaced by the new one.
>>The multi-conn code definitely needs more attention, it breaks the Win32 build in its current state.
>>Along those lines,  in the normal (non-Win32) case I don't see an actual need for the connections_mutex. Since we go directly from descriptor number to connection slot, there's really no shared resource to protect that isn't already protected by the conn->c_mutex.
>Given our positive results from eliminating the connections_mutex I'm going to be stripping out all of the multi-conn stuff from HEAD.

I note that connections_mutex was added to address a race
conditions on connection close.  Be careful that eliminating
the connections_mutex doesn't reintroduce these (or other)
race conditions.  -- Kurt

>I think the Win32 code will still need the connections_mutex. For Win32 performance I may consider keeping its descriptor table sorted so we can do binary search on it, but that'll come later. Too bad there's not a simple way to hash those things; apparently a Winsock descriptor is an offset into a system-wide table, not per-process. If a simple solution presents itself, we can eliminate the search here too.
> -- Howard Chu
> Chief Architect, Symas Corp.  http://www.symas.com
> Director, Highland Sun        http://highlandsun.com/hyc
> OpenLDAP Core Team            http://www.openldap.org/project/