Hide Forgot
Description of problem: 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.
Upstream ticket: https://github.com/389ds/389-ds-base/issues/5267
*** Bug 2069744 has been marked as a duplicate of this bug. ***
Design Doc: https://www.port389.org/docs/389ds/design/store-case-sensitive-dn-design.html