Hi Team,
We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code.
We are using OpenLDAP 2.6.7.
As part of this migration, we are facing one issue related to performance degradation under load on Windows platform.
In our application, we are using a single/shared connection handle to perform LDAP operation on LDAP user store servers. As part of Authentication, we are using ldap_search_ext_s call to get users and to get any user attributes from LDAP servers. We are using synchronous calls. With Mozilla NSLDAP, the same application is working well without any issues. As we are migrating to OpenLDAP, we did required changes and also we used ldap_dup() API to avoid "-4:Decoding error" issues under the load.
Now, we are facing performance degradation issues under the load with OpenLDAP library Whenever we are trying to get a user attribute from the LDAP user store server where that user attribute is not available or value for user attribute is empty, we observed performance degradation with OpenLDAP library clearly around 25-30%. In case, search for user attributes with value, no degradation observed. This degradation is happening only when the user attribute is not available or the value is empty.
Here are the snippet of runs output where performance degrade is showing:
*With search of user attribute having value at LDAP server side:*
Total Elapsed: 0:10:01
Minimum Response Time: 0:00:00.000.056 Maximum Response Time: 0:00:00.783.140 Average Response Time: 0:00:00.016.124
Total Requests: 659316 Throughput (Req/Sec): 1094.447
*With search of user attribute, not having value/does not exist at LDAP server side:*
Total Elapsed: 0:10:01
Minimum Response Time: 0:00:00.000.059 Maximum Response Time: 0:00:00.218.502 Average Response Time: 0:00:00.032.788
Total Requests: 355065 Throughput (Req/Sec): 590.258
Example search calls we are using: 1. ldap_search_ext_x() for user lookup 2. ldap_search_ext_s() for user attributes for that specific user. (filter: uid=* and base: "cn=user,dc=comain,dc=com) - Where uid attribute has some value for this user at LDAP server side 3. ldap_search_ext_s() for user attributes for that specific user. (filter: Name=* and base: "cn=user,dc=comain,dc=com) - Where Name attribute is not present for that user at LDAP server side (This is causing performance degrade)
With the same above steps, we did not see any performance issues with NSLDAP. If we remove step 3 from the above, no degradation is observed with the OpenLDAP library.
Could you please look into this issue and provide a solution to overcome this performance degradation issue? We are completely blocked here as part of OpenLDAP migration.
Note: To investigate this performance degradation with OpenLDAP, I wrote one LDAP sample code with the above 3 operations with multiple threads. I executed the sample with NSLDAP and OpenLDAP using multiple threads. In the sample runs, OpenLDAP is giving very poor performance when compared with NSLDAP. Please have a look at the sample also and provide your thoughts.
Thank you in advance for your time and help
Please provide the sample LDIF corresponding to this test code. Also, a sample of the server configuration.
venugopal chinnakotla wrote:
Hi Team,
We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code.
We are using OpenLDAP 2.6.7.
As part of this migration, we are facing one issue related to performance degradation under load on Windows platform.
In our application, we are using a single/shared connection handle to perform LDAP operation on LDAP user store servers. As part of Authentication, we are using ldap_search_ext_s call to get users and to get any user attributes from LDAP servers. We are using synchronous calls. With Mozilla NSLDAP, the same application is working well without any issues. As we are migrating to OpenLDAP, we did required changes and also we used ldap_dup() API to avoid "-4:Decoding error" issues under the load.
Now, we are facing performance degradation issues under the load with OpenLDAP library Whenever we are trying to get a user attribute from the LDAP user store server where that user attribute is not available or value for user attribute is empty, we observed performance degradation with OpenLDAP library clearly around 25-30%. In case, search for user attributes with value, no degradation observed. This degradation is happening only when the user attribute is not available or the value is empty.
Here are the snippet of runs output where performance degrade is showing:
*With search of user attribute having value at LDAP server side:*
Total Elapsed: 0:10:01
Minimum Response Time: 0:00:00.000.056 Maximum Response Time: 0:00:00.783.140 Average Response Time: 0:00:00.016.124
Total Requests: 659316 Throughput (Req/Sec): 1094.447
*With search of user attribute, not having value/does not exist at LDAP server side:*
Total Elapsed: 0:10:01
Minimum Response Time: 0:00:00.000.059 Maximum Response Time: 0:00:00.218.502 Average Response Time: 0:00:00.032.788
Total Requests: 355065 Throughput (Req/Sec): 590.258
Example search calls we are using:
- ldap_search_ext_x() for user lookup
- ldap_search_ext_s() for user attributes for that specific user. (filter: uid=* and base: "cn=user,dc=comain,dc=com) - Where uid attribute has some value for
this user at LDAP server side 3. ldap_search_ext_s() for user attributes for that specific user. (filter: Name=* and base: "cn=user,dc=comain,dc=com) - Where Name attribute is not present for that user at LDAP server side (This is causing performance degrade)
With the same above steps, we did not see any performance issues with NSLDAP. If we remove step 3 from the above, no degradation is observed with the OpenLDAP library.
Could you please look into this issue and provide a solution to overcome this performance degradation issue? We are completely blocked here as part of OpenLDAP migration.
Note: To investigate this performance degradation with OpenLDAP, I wrote one LDAP sample code with the above 3 operations with multiple threads. I executed the sample with NSLDAP and OpenLDAP using multiple threads. In the sample runs, OpenLDAP is giving very poor performance when compared with NSLDAP. Please have a look at the sample also and provide your thoughts.
Thank you in advance for your time and help
Hi,
Please find the attached sample LDIF file that we used for our testing (Sent an email with attachment). We are using the Symantec Directory. New DSA created for user store with default values. No custom changes.
Thank you.
Hi Team,
For the performance degrade we observed in our case on Windows platform only, did some research and have few findings. Check below details and share your thoughts and opinion.
Use Case: ----------- Environment: Platform: Windows Server (2025/2022) OpenLDAP Version: 2.6.7 C SDK LDAP Provider: Switching from Mozilla NSLDAP 6.0.7 to OpenLDAP 2.6.7 Connection Pattern: Single LDAP connection handle shared across multiple threads API Usage: Synchronous calls (ldap_search_ext_s, ldap_bind_s, ldap_get_values_len)
Problem Statement: Significant performance degradation observed only on Windows when using OpenLDAP 2.6.7, compared to Mozilla NSLDAP 6.0.7 in identical scenarios.
Research analysis and probable root cause: ------------------------------------------------ Key Observation:
Performance issue is Windows-specific and OpenLDAP-specific.
Both OpenLDAP and NSLDAP make identical network calls to LDAP server No client-side caching differences Server response times are identical Conclusion: Issue is client-side, not network or server-related
Application Code Analysis: Analyzed ldap_dup() usage (thread-local handles) Removed ldap_dup() - degradation persisted Conclusion: Issue is not in application logic
OpenLDAP Source Code Analysis: After analyzing the OpenLDAP source code, identified one place where we observed code difference between Windows and Linux platform. In File: thr_nt.c, where wrappers implemented around NT threads (ldap_pvt_thread_mutex_***). Used HANDLE-based Windows Mutex (CreateMutex, WaitForSingleObject, ReleaseMutex)
Changes Implemented: -------------------------- Replaced Windows Mutex with CRITICAL_SECTION
Change 1: Type Definition
File: include/ldap_int_thread.h
// BEFORE: typedef HANDLE ldap_int_thread_mutex_t; #define LDAP_INT_MUTEX_NULL ((HANDLE)0)
// AFTER: typedef CRITICAL_SECTION ldap_int_thread_mutex_t; #define LDAP_INT_MUTEX_NULL {0}
Change 2: Mutex Functions (updated Mutex functions to use Critical Section)
File: libraries/libldap/thr_nt.c
Functions: ldap_int_mutex_firstcreate ldap_pvt_thread_cond_wait ldap_pvt_thread_cond_broadcast ldap_pvt_thread_mutex_init ldap_pvt_thread_mutex_recursive_init ldap_pvt_thread_mutex_destroy ldap_pvt_thread_mutex_lock ldap_pvt_thread_mutex_unlock ldap_pvt_thread_mutex_trylock
Ex: int ldap_pvt_thread_mutex_init( ldap_pvt_thread_mutex_t *mutex ) { InitializeCriticalSection( mutex ); return 0; }
int ldap_pvt_thread_mutex_lock( ldap_pvt_thread_mutex_t *mutex ) { EnterCriticalSection( mutex ); return 0; }
After making these changes, build OpenLDAP library and verified with our Application. Now, we are not getting any performance degrade on Windows platform. Performance results are almost inline with existing Mozilla nsldap.
Your thoughts/Opinion request: -----------------------------------
Are there existing recommendations or workarounds for high-concurrency Windows deployments with shared LDAP handles? Would a CRITICAL_SECTION implementation be acceptable, or are there concerns we haven't considered?
We would greatly appreciate your thoughts on: - Whether this is the right direction for Windows performance - Any concerns or edge cases we should address - Any other regression areas we should consider with this change
Thank you for maintaining OpenLDAP and for considering this request!
On Tue, Mar 17, 2026 at 04:43:42AM -0000, c.venugopal521@gmail.com wrote:
Hi Team,
For the performance degrade we observed in our case on Windows platform only, did some research and have few findings. Check below details and share your thoughts and opinion.
[...]
OpenLDAP Source Code Analysis: After analyzing the OpenLDAP source code, identified one place where we observed code difference between Windows and Linux platform. In File: thr_nt.c, where wrappers implemented around NT threads (ldap_pvt_thread_mutex_***). Used HANDLE-based Windows Mutex (CreateMutex, WaitForSingleObject, ReleaseMutex)
[...]
After making these changes, build OpenLDAP library and verified with our Application. Now, we are not getting any performance degrade on Windows platform. Performance results are almost inline with existing Mozilla nsldap.
Your thoughts/Opinion request:
Are there existing recommendations or workarounds for high-concurrency Windows deployments with shared LDAP handles? Would a CRITICAL_SECTION implementation be acceptable, or are there concerns we haven't considered?
We would greatly appreciate your thoughts on:
- Whether this is the right direction for Windows performance
- Any concerns or edge cases we should address
- Any other regression areas we should consider with this change
Thank you for maintaining OpenLDAP and for considering this request!
You are welcome to open an ITS[0] proposing a change and provide a patch (see guidelines for contributing[1] as well).
[0]. https://bugs.openldap.org [1]. https://openldap.org/devel/contributing.html
Thank you,
openldap-technical@openldap.org
-
c.venugopal521＠gmail.com -
Howard Chu -
Ondřej Kuzník -
venugopal chinnakotla