tamarin p wrote:
I've been running some tests with OpenLDAP 2.4.11 lately, with an 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 "objectclass" 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 doesn't need 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.