Am 25.08.22 um 08:25 schrieb Ulrich Windl:
>>> Norbert <openldap(a)freakix.de> schrieb am 24.08.2022
um 11:27 in Nachricht
> with OpenLDAP 2.4.47 (running on Debian 10) but also with 2.5.13 from
(running on same Debian
> 10) I can observe the following:
> given following rough idea of a tree
> |- bn=subtree1
> | - handful of entries
> |- bn=subtree2
> | - millions of entries
> |- bn=subtree3
> | |- bn=sub-subtree1
> | |- bn=sub-subtree2
> | |- some entries
> |- bn=subtree4
> ou is an indexed attribute with pres,eq,sub. When now searching with the
And is bn indexed, too?
Yes, sorry typing error I meant bn.
> filter bn=<value> then there is a
> significant difference when searching for either subtree1 and subtree2 as
> values in the range of seconds. This
> means on command line ldapsearch with subtree1 it is around 0.007 seconds
> and with subtree2 4.5 seconds before
> the fully finishes.
> When I change the search filter to
> this has no real impact to the
> time needed searching for subtree1 but improves searching subtree2, still it
> more than 2 times slower than
> searching for subtree1. Only entries with objectClass=bnClass have the bn
> attribute but no other entries.
> Changing the scope to one, yields similar times when searching for subtree1
> and subtree2 but the search itself
> also to cover searching for sub-subtree1 or sub-subtree2 with the same
> search task as it is not known where
> such sub-subtree could be found.
> The only pattern I've found so far is that if there are millions of entries
> in a subtree then finishing the
> search takes much longer.
> The LDAP is using MDB, and has been completely rebuilt (means
> slapcat/slapadd) several times with always
> showing the same results. There was no difference between 2.4 and 2.5.13.
> Is there something which can be improved by changing the configuration?