为ldap放弃请求延迟ACK包

我们已经从Linux上的openldap服务器迁移到Windows 2008上的DirX。ldap服务器和正常的serch请求按预期运行。 但是，有些应用程序（weblogic部署的webapps）会导致性能问题。

我们追踪了networking活动，发现当客户端发送“放弃”操作时，ldap服务器发送并确认具有0.1-0.2s的RTT。

我们不是100％肯定的，但我们认为这是performance冲击的来源。 我们看到的交互有270个放弃，179个ACKS的RTT> 0.2s。

不是很熟悉TCP，我有以下问题：

• 错误19（0x13）使用Syncrepl复制OpenLDAP
• Nagios 3.2.3核心Web界面通过LDAP使用全名用户名login
• 根据传递的Require指令设置环境variables
• 使用RADIUS服务器的LDAPauthentication
• Bugzilla LDAP身份validation在admin pw更改后破坏 – CentOS

1. 响应于接收到分组而发送的ACK独立于接收者将花费多长时间来处理发送的数据。 这发生在收件人甚至收到传入的有效负载之前的tcp级别（在我们的情况下放弃）。 对？

2. 所有其他交互说searchrequest / searchresponse在有效载荷数据包有ack。 这是“延迟了”？ 他们只需要约0.01秒，这包括有效载荷和可能的计算。 那么为什么单个的ACKS被放弃呢？ 或者像这样提出问题：什么时候发送个人ack而不是合并ack +数据？

   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) 

谢谢，

迈克尔