[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/