On Tue, Oct 08, 2019 at 12:56:04PM +0000, jrajalakshmi@juniper.net wrote:

Hi,

Thanks for the reply. There is an implementation already in our product.

Hi, as mentioned previously, please provide a sample C program that shows what's happening and preferably one that also behaves better with 2.4.23 from your perspective so we can help you investigate. I don't believe packet captures would help us here at this point.

To summarize on the behavior observed

Scenario#1:

Single LDAP session with LDAP Bind does authentication in Sequential Order. Due to sequential execution of OpenLDAP Search API after version 2.4.24 we observe packet drops in LDAP Authentication Request. This is resulting in Low performance of our product.

Previously you mentioned only searches, which should work over the same connection depending how you do things. Not sure how binds fit in the picture here? Just a note that you can only have certain types of operations pending at the same time and binds are not one of them.

Also don't know what you mean by packet drops here. Is that packet drops in your product or packet drops on the LDAP session?

Scenario #2: (this is a sample test case tried to compare the behavior with Scenario#1)

There are say 10 LDAP instances configured, all pointing to the same LDAP server. The request-response is handled properly, performance is improved when compared to scenario#1. But the drawback is the multiple threads for every LDAP client session, utilizing more memory. This design may not be recommended for our product.

You can have a single thread taking care of the session (or however many sessions you want) if you use a non-blocking socket for the underlying connection(s) (and use ldap_result and friends) which is what the asynchronous API has been designed for.

Pl. reply back for any further queries / clarifications. The packet captures file size is big (>6MB), can try to share the relevant request-response details......

Regards,