Having now done much tweaking with openldap, we are now up to a dismal
average of 14 queries/second with 20 hosts over a 74.5 minute period.
I am fairly positive we are indexing everything necessary. All we are
doing right now is filtering on suseassunetid to find the sumaildrop
attribute. Both of those attributes are indexed, as are objectClass,
entry, uid, dc, and cn. Example query: ldapsearch -h <host>
-b"cn=accounts,dc=stanford,dc=edu" suseassunetid=quanah sumaildrop
I note that a query like this is actually quite complex... and includes
all the TCP establishment, maybe DNS reverse lookups, SASL authentication
and security layer establishment, identity mapping (possible with search
indirection), .... That is, a lot more than a single LDAP search
operation.
A few things we have noticed:
One: slapd spends a lot of time determining the ACL's for attributes,
every single time a query is made, instead of caching the ACL's. I am
interested in its #1523, but do not have access to the patches. Would
it be possible to send them to me, so I can see if that improves our
performance any?
Seems the patch was uploaded under a different name. I've added a symlink
to the repository so that URL in the ITS now works.
Two: slapd will be very responsive and quick in its answers for a
period of time, then will just hang for several seconds, or greatly slow
down the rate at which it is returning queries. It will then pick up
again, being quite responsive.
I would look at three areas were such can easily occur. One, something
in the connection accept code (which is single threaded) hanging up on
something... like reverse DNS lookups. Two, something in the
lower-level authentication framework (SASL,GSSAPI,Kerberos) hanging
things up. Three, contention for DB pages (if using back-bdb) or the
LDBM giant r/w lock (if using back-ldbm).