Hi Chris,

I'm not a network specialist but when we pointed directly to OpenLDAP server we could see a much less ACKs on the dump than when pointed to load balance VIP. Maybe you could do this test on your environment and check the results.

We created a Java Class to perform some tests on our tree and tcpdump was used to see the differences between the queries directly on the server and through the F5. The tcpdump file was 1MB larger when pointed to F5 using the same search algorithm of our Java Class.

This is interesting because we also have a lot of GNU/Linux servers which peform user, password and group validation against OpenLDAP through the F5 and for that end the Nagle's Algorithm still active but there is no performance loss. I think this is related and only applies to some kind of applications which really need real time response from LDAP [1].

[1] - http://en.wikipedia.org/wiki/Nagle%27s_algorithm#Interactions_with_real-time...

Thanks,

Matheus Morais

On Tue, Aug 24, 2010 at 3:39 PM, Chris Jacobs Chris.Jacobs@apollogrp.eduwrote:

Matheus,

What was generating the ‘too many ACKs’?

We’re also using F5’s in all locations (in front of mirrored masters, and 3 sets of load balanced slaves) – and have only had an issue in one location which was related to an overloaded VM cluster.

Thanks,

• chris

*From:* openldap-technical-bounces@OpenLDAP.org [mailto: openldap-technical-bounces@OpenLDAP.org] *On Behalf Of *Matheus Morais *Sent:* Tuesday, August 24, 2010 11:31 AM *To:* openldap-technical@openldap.org *Subject:* OpenLDAP and Load Balance F5 issue

Hi there,

We were having some performance troubles using OpenLDAP and F5 load balance solution from BigIP at a high concurrent enviroment. We faced the problem for one month after I discovered that those problems didn't happen when applications was pointed directly to OpenLDAP server instead of load balance VIP. After a tcpdump analysis of the packages we realize that are too many ACK comming from each request.

Last week we solved the problem unsetting Nagle's algorithm on the load balance virtual server which was causing this issue.

So, if you look yourself on a similiar situation, please check the Nagle's algorithm on the F5 configuration!

Thanks,

Matheus Morais

---

This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

Hi Daniel,

Glad to see those graphics, its a very substantial performance gain!

Thanks to share this with us!

On Thu, Aug 26, 2010 at 5:57 AM, openldap-ml@stresst.net wrote:

Hi Matheus,

we've also been wondering about the very slow ldap response times of our slapds behind our F5s (in comparison to direct slapd connections) but we had no time to analyze the behavior in detail, yet...

...and thanks to your investigations and your report to the list we don't need to investigate into this direction any more - thank you very much!

For demonstration purposes I've uploaded a screenshot of one of our response time graphs under the following url:

http://img831.imageshack.us/img831/9277/f5nagledisabled.png

As can be seen here disabling the Nagle-Algorithm (yesterday ~ 15:45 o'clock) leads to a 5 to 6 times faster response.

Cheers Daniel P.S. BTW: also many thanks into direction to the ltb-project for providing the cacti ldap response graph templates!

On 08/24/2010 08:30 PM, Matheus Morais wrote:

...

Hi there,

We were having some performance troubles using OpenLDAP and F5 load balance solution from BigIP at a high concurrent enviroment. We faced the problem for one month after I discovered that those problems didn't happen when applications was pointed directly to OpenLDAP server instead of load balance VIP. After a tcpdump analysis of the packages we realize that are too many ACK comming from each request.

Last week we solved the problem unsetting Nagle's algorithm on the load balance virtual server which was causing this issue.

So, if you look yourself on a similiar situation, please check the Nagle's algorithm on the F5 configuration!

Thanks,

Matheus Morais

Thanks,

Matheus Morais