Am 25.08.22 um 08:25 schrieb Ulrich Windl:
Norbert openldap@freakix.de schrieb am 24.08.2022 um 11:27 in Nachricht
7c7bb2e6-d037-7069-9e32-0851e685c6c0@freakix.de:
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?
Yes, sorry typing error I meant bn.
Regards, Norbert
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