Feature: A filter component may contain 'nsrole' attribute that can not be indexed. WIth this feature the component is rewritten into another component that can be indexed. This RFE only applies to managed and filtered roles but not to nested roles.
Reason: the virtual attribute 'nsrole' is supported in filter component. As a virtual attribute it can not be indexed and the component is unindexed. If the others components of the filter are not indexed then the search will be unindexed and result in very long operation.
Result: 'nsroles' attribute used in filter component are rewritten and then can be indexed. Resulting with better response time. Only for managed and filtered roles.
Description of problem:
This customer has an LDAP DB of 1.2 million of entries.
There are applications which are running queries using the nsRole virtual attribute.
For instance:
SRCH base="dc=example,dc=com" scope=2 filter="(&(nsRole=cn=NSROLE,dc=example,dc=com)(objectClass=USER))" attrs="distinguishedName "
The initial query is taking too long to complete and applications are hitting their timeouts.
Subsequent queries are faster.
1st run:
SRCH base="dc=example,dc=com" scope=2 filter="(&(nsRole=cn=NSROLE,dc=example,dc=com)(objectClass=USER))" attrs="distinguishedName "
RESULT err=0 tag=101 nentries=11 wtime=0.000070735 optime=179.484774853 etime=179.484840590 notes=A details="Fully Unindexed Filter"
Following queries
SRCH base="dc=example,dc=com" scope=2 filter="(&(nsRole=cn=NSROLE,dc=example,dc=com)(objectClass=USER))" attrs="distinguishedName"
RESULT err=0 tag=101 nentries=11 wtime=0.000060507 optime=0.558663030 etime=0.558718327 notes=A details="Fully Unindexed Filter
Version-Release number of selected component (if applicable):
$ cat <SOS_REPORT>/etc/redhat-release
Red Hat Enterprise Linux release 8.6 (Ootpa)
$
$ grep ^389-ds <SOS_REPORT>/installed-rpms
389-ds-base-1.4.3.29-3.module+el8dsrv+14615+a86efbbf.x86_64 Mon Sep 5 10:44:21 2022
389-ds-base-libs-1.4.3.29-3.module+el8dsrv+14615+a86efbbf.x86_64 Mon Sep 5 10:44:19 2022
$
How reproducible:
Always.
Steps to Reproduce:
1. Create a DB with a million of entries
2. Add the nsRoleDN attribute to 20K entries
3. Run searches using the nsRole attribute
Actual results:
Slow searches
Expected results:
Faster results so applications won't timeout.
After increasing the Normalized DN cache, subsequent queries are faster.
Now the concern is about how to improve the first search.
Additional info:
* Upstream ticket:
https://github.com/389ds/389-ds-base/issues/5695
* Indexing and virtual attributes:
https://bugzilla.redhat.com/show_bug.cgi?id=1773643
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (redhat-ds:12 bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHEA-2023:7429
Description of problem: This customer has an LDAP DB of 1.2 million of entries. There are applications which are running queries using the nsRole virtual attribute. For instance: SRCH base="dc=example,dc=com" scope=2 filter="(&(nsRole=cn=NSROLE,dc=example,dc=com)(objectClass=USER))" attrs="distinguishedName " The initial query is taking too long to complete and applications are hitting their timeouts. Subsequent queries are faster. 1st run: SRCH base="dc=example,dc=com" scope=2 filter="(&(nsRole=cn=NSROLE,dc=example,dc=com)(objectClass=USER))" attrs="distinguishedName " RESULT err=0 tag=101 nentries=11 wtime=0.000070735 optime=179.484774853 etime=179.484840590 notes=A details="Fully Unindexed Filter" Following queries SRCH base="dc=example,dc=com" scope=2 filter="(&(nsRole=cn=NSROLE,dc=example,dc=com)(objectClass=USER))" attrs="distinguishedName" RESULT err=0 tag=101 nentries=11 wtime=0.000060507 optime=0.558663030 etime=0.558718327 notes=A details="Fully Unindexed Filter Version-Release number of selected component (if applicable): $ cat <SOS_REPORT>/etc/redhat-release Red Hat Enterprise Linux release 8.6 (Ootpa) $ $ grep ^389-ds <SOS_REPORT>/installed-rpms 389-ds-base-1.4.3.29-3.module+el8dsrv+14615+a86efbbf.x86_64 Mon Sep 5 10:44:21 2022 389-ds-base-libs-1.4.3.29-3.module+el8dsrv+14615+a86efbbf.x86_64 Mon Sep 5 10:44:19 2022 $ How reproducible: Always. Steps to Reproduce: 1. Create a DB with a million of entries 2. Add the nsRoleDN attribute to 20K entries 3. Run searches using the nsRole attribute Actual results: Slow searches Expected results: Faster results so applications won't timeout. After increasing the Normalized DN cache, subsequent queries are faster. Now the concern is about how to improve the first search. Additional info: * Upstream ticket: https://github.com/389ds/389-ds-base/issues/5695 * Indexing and virtual attributes: https://bugzilla.redhat.com/show_bug.cgi?id=1773643