我们正在尝试调查LDAP服务器的性能问题。 我们正在从Linux上的openldap转向Windows 2008上的proprietory（DirX）。
LDAP是用于weblogic应用程序的用户存储，并在那里配置为 身份验证提供程序。
部分应用现在遇到了性能问题。
硬件资源很好，可以使用其他ldap客户端查询（新）LDAP服务器 并且通过脚本无法重现性能问题。
然后我们看了一下网络。我们发现，对于受影响的应用程序，大量的ldap“放弃请求”操作从客户端发出。我们看了一下这个行为 原来的openldap服务器发现了一些，但更少的'放弃请求'操作。 我们（还）不知道客户在什么情况下决定发送放弃请求。
下面的场景是典型的。客户端在那里发送放弃请求后 首先出现一对ACK然后是客户端然后是服务器。而ldap发送的那个需要0.1到0.4秒。 它在ACK中的这种延迟似乎正在耗费......
我不太熟悉TCP协议，我希望有人帮助澄清/确认我的解释：
分组664是从服务器到分组662的ACK（放弃请求长度10）。 分组663是从客户端到分组661（searchResDone）的ACK
如果我的解释是正确的，我现在会调查： - 为什么放弃要求的时间长得多，即0.20而不是说0.04 （或者为什么服务器花了这么长时间才放弃？） - 为什么客户首先发送弃权？
还有其他想法吗？
提前感谢，
迈克尔
...
657 9.2943 ldapserver ldapclient LDAP 170 searchResDone(57)
658 9.2948 ldapclient ldapserver TCP 66 18367 > 389 [ACK] Seq=10007 Ack=19799 Len=0
659 9.2954 ldapclient ldapserver LDAP 1009 searchRequest(134)
660 9.2972 ldapserver ldapclient LDAP 630 searchResEntry(134)
661 9.2973 ldapserver ldapclient LDAP 172 searchResDone(134)
Sequence number:45106, len=106
662 9.2978 ldapclient ldapserver LDAP 76 abandonRequest(134)
Sequence number: 46818, len=10
663 9.3378 ldapclient ldapserver TCP 66 18368 > 389 [ACK] Seq=46828 Ack=45212 Len=0
(The RTT to ACK the segment was: 0.040492000 seconds)
664 9.5062 ldapserver ldapclient TCP 66 389 > 18368 [ACK] Seq=45212 Ack=46828 Len=0
(The RTT to ACK the segment was: 0.208397000 seconds)
665 9.5068 ldapclient ldapserver LDAP 183 searchRequest(136)
666 9.5229 ldapserver ldapclient LDAP 163 searchResEntry(136)
667 9.5229 ldapserver ldapclient LDAP 170 searchResDone(136)
....