Skip to content
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

Closed
mreynolds389 opened this issue Apr 13, 2022 · 3 comments
Closed

RFE - store full DN in database record #5267

mreynolds389 opened this issue Apr 13, 2022 · 3 comments
Assignees
Labels
performance Issue impacts performance RFE Request for Enhancement
Milestone

Comments

@mreynolds389
Copy link
Contributor

mreynolds389 commented Apr 13, 2022

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%

subtree-rename=OFF 
----------------------------------------------------
Workers         Clients         SRCH/s          GAIN
15              40              142302.868      + 0%
15              45              157062.354      + 4%    
15              50              165993.278      +12%
15              55              168967.106      +15%

20              40              133749.551      + 2%
20              45              148529.026      + 0%
20              50              150216.182      + 1%
20              55              114247.201      +13%

25              40              123818.029      + 1%
25              45              141934.678      + 1%
25              50              153096.810      + 0%
25              55              109355.695      +10%


subtree-rename=ON
----------------------------------------------------
Workers         Clients         SRCH/s
15              40              142297.329
15              45              150931.420
15              50              147570.526
15              55              146769.262

20              40              130967.392
20              45              148365.746
20              50              148903.385
20              55              121286.399

25              40              122408.771
25              45              140797.527
25              50              151812.222
25              55               98683.023

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.

@mreynolds389 mreynolds389 added RFE Request for Enhancement performance Issue impacts performance labels Apr 13, 2022
@mreynolds389 mreynolds389 added this to the 2.x backlog milestone Apr 13, 2022
@mreynolds389
Copy link
Contributor Author

@mreynolds389 mreynolds389 self-assigned this Apr 14, 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
Copy link
Contributor Author

b1ed566..4b4bb97 389-ds-base-2.2 -> 389-ds-base-2.2

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!)
@mreynolds389
Copy link
Contributor Author

CI fix:
26eaa1b..86fb2b9 389-ds-base-2.2 -> 389-ds-base-2.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Issue impacts performance RFE Request for Enhancement
Projects
None yet
Development

No branches or pull requests

1 participant