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/
