tamarin p wrote:
I've been running some tests with OpenLDAP 2.4.11 lately, with
existing application that will use the LDAP as its backend for storing
users and roles.
Using bdb, performance is excellent. With hdb on the other hand, the
application is rendered unusable unless the searched entry is already
cached, as one particular search takes minutes to execute otherwise,
whereas in bdb the same search quite fast regardless. The specific
search is subtree (scope=2 deref=0) filtered on "o" and
like so: (&(objectClass=organization)(o=123456)).. Both attributes have
equality indexes. The whole directory has just over 4 million entries,
and about 500.000 of those are in the context being searched thanks to
the scope. The strange thing is how bdb is fast from search one, while
hdb with hdb it takes minutes to complete unless the entry is already
cached. I've tried configuring caches according to the faq-o-matic. The
docs mention that hdb requires a bigger idl cache in particular, to have
good search performance, so I've tried various cache sizes, up to 1
million for idl- and 330.000 for the entry caches, but this seems to
make slapd dig so deeply into virtual memory that I'm not sure if it
actually does more harm than good.
Also check your dncachesize, the DN cache tends to be the critical element in
back-hdb's performance. Still, if the filter attributes are indexed it should
not be so slow...
Now, there's no requirement to use hdb as the application
subtree renames and bdb works great. I just want check that my config
isn't horribly wrong, or that I'm overlooking something vital for hdb
not required for bdb..
Hard to say at the moment.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/