>>> Norbert <[email protected]> schrieb am 24.08.2022 um 11:27 in Nachricht <[email protected]>: > Hi, > > with OpenLDAP 2.4.47 (running on Debian 10) but also with 2.5.13 from > ltb-project.org (running on same Debian > 10) I can observe the following: > > given following rough idea of a tree > > o=base > |- 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? > 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 "(&(objectClass=bnClass)(bn=<value>))" > then > 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? > > Thanks, > Norbert
