New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE - store full DN in database record #5267
Labels
Milestone
Comments
mreynolds389
added
RFE
Request for Enhancement
performance
Issue impacts performance
labels
Apr 13, 2022
mreynolds389
added a commit
to mreynolds389/389-ds-base
that referenced
this issue
Oct 27, 2022
Description: For the Full unnormalized DN in the entry via "dsEntryDN" operational attribute. This allows for maintaining the case of a DN from when it was first added. There is also a significant performance improvement when loading an entry from disk to the entry cache (using entryrdn index was very exspensive). Added config setting to turn this behavior on and off (default on) relates: 389ds#5267 Reviewed by: firstyear, progier, tbordaz, and spichugi(Thanks!!!!)
mreynolds389
added a commit
that referenced
this issue
Oct 27, 2022
Description: For the Full unnormalized DN in the entry via "dsEntryDN" operational attribute. This allows for maintaining the case of a DN from when it was first added. There is also a significant performance improvement when loading an entry from disk to the entry cache (using entryrdn index was very exspensive). Added config setting to turn this behavior on and off (default on) relates: #5267 Reviewed by: firstyear, progier, tbordaz, and spichugi(Thanks!!!!)
mreynolds389
added a commit
that referenced
this issue
Oct 27, 2022
Description: For the Full unnormalized DN in the entry via "dsEntryDN" operational attribute. This allows for maintaining the case of a DN from when it was first added. There is also a significant performance improvement when loading an entry from disk to the entry cache (using entryrdn index was very exspensive). Added config setting to turn this behavior on and off (default on) relates: #5267 Reviewed by: firstyear, progier, tbordaz, and spichugi(Thanks!!!!)
mreynolds389
added a commit
to mreynolds389/389-ds-base
that referenced
this issue
Feb 20, 2023
Description: Fix CI test to properly set the nsslapd-return-original-entrydn and to restart the server after changing the config setting. relates: 389ds#5267 Reviewed by: vashirov(Thanks!)
mreynolds389
added a commit
that referenced
this issue
Feb 20, 2023
Description: Fix CI test to properly set the nsslapd-return-original-entrydn and to restart the server after changing the config setting. relates: #5267 Reviewed by: vashirov(Thanks!)
mreynolds389
added a commit
that referenced
this issue
Feb 20, 2023
Description: Fix CI test to properly set the nsslapd-return-original-entrydn and to restart the server after changing the config setting. relates: #5267 Reviewed by: vashirov(Thanks!)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While testing "nsslapd-subtree-rename-switch=off" there was noticeable performance improvement. The current implementation generates the DN dynamically by using the entryrdn attribute in the database record, and then obtaining the parent portion of the DN from other database indexes.
Disabling subtree-rename (nsslapd-subtree-rename-switch=off) improves throughput/response_time performance especially when the number of clients increases.
The range of improvement on highest load (high number of clients) ranges up to ~10%
We could also maintain the existing operational attribute "entrydn" and only use it for DN "generation" on searches. It would need to be updated on adds, and modrdns. There could also be an impact on tombstones queries as well.
The text was updated successfully, but these errors were encountered: