Am 25.08.22 um 08:25 schrieb Ulrich Windl:
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?
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
