Re: PTH support in OpenLDAP 1.x

[wesley.craig@umich.edu]

> From:    Vinod Nair <vnair@broadjump.com>

> On Solaris2.6, with pre-emptive threads, I've seen "multiple
> writers" scenario occasionally core dump (1.2.10) or hang (1.2.9).
> This is with the DirMark benchmark. Do you have multiple writers in your
> setup ?

Yes.  And we do see occasional crashes.  We really have no choice, tho,
given our high load.  Also, our crash rate was no different with PTH
than with pthreads.  Numerous bug fixes have been applied since I tried
it, tho, so PTH may improve reliability.

> By "administrative limits on searches" were you referring to 
> the sizelimit or timelimit parameters in slapd.conf. I (and
> I'm sure others on the list too) would like to hear about
> your performance enhancements.

I've implemented candidate limits, different from size or time limits.
During search, particularly on un-indexed attributes, the server loops
through large lists of entries.  Given the high time limit we set,
searches on unindexed attributes start a rather long lived thread which
is unlikely to produce useful results.  We added code to count the
number of entries examined, the number of entries returned, and what
the final result was.  We found that searches which examined more than
1000 entries were unlikely to ever return any result, and the final
return was invariably "time limit exceeded".

A candidate limit allows us to return "time limit exceeded" (in LDAP v3
we would return "administrative limit exceeded") in a much shorter
time, after having expended fewer resources.

> ./configure --with-ldbm-api=db2 \
> --with-ldbm_type=btree \
> --with-threads=pth \
> --enable-rlookups=no 

I believe --with-ldbm_type=btree is the default.

:wes