我正在尝试使用Tomcat升级在Java EE中创建的Web应用程序。直到现在我一直在使用Netscape ldap implementation，现在我正在尝试升级到Unboundid Ldap。问题是与Netscape实现相比，Unboundid实现具有非常高的延迟。
关于我打算做什么的一些信息：我想从LDAP获取最后5个条目，将它们放在一个数组中并在网页中显示该数组。
EDIT1： 我使用Java SE创建了2个用于测试库的示例应用程序。 对于每个测试，我都附加了源代码和服务器端LDAP日志。
结果是相同的，无论我使用的迭代如何，使用UnboundID SDK实现检索结果平均需要更长的时间。
对于Netscape LDAP SDK：code和log。 对于UnboundID LDAP SDK：code和log
EDIT2： 我也在尝试使用UnboundID提供的ldap-debugger工具，但我无法弄清楚如何使它工作，我看到它需要绑定的ip和端口作为参数，客户端应该连接ldap-debugger和他将充当代理，但是我在哪里指定服务器ip和端口，因为在客户端我已经为ldap-debugger设置了ip和端口？
答案 0 :(得分：0)
没有任何东西可以立即跳出你正在使用的代码。在我的测试中，UnboundID LDAP SDK比Netscape SDK快得多。虽然你肯定有可能找到某种角落的情况，但我还想排除其他一些可能性。
首先，您如何确定每个版本执行的时间？您是使用客户端计时（例如，System.currentTimeMillis（），再次运行代码，System.currentTimeMillis（））还是服务器端计时（例如，服务器访问日志中报告的处理时间）？如果差异仅存在于客户端，那么这肯定可能指向SDK问题，但如果差异也出现在服务器端，那么可能会有一些不同的正在发送的请求导致服务器执行更多操作在一个案例中工作比另一个案件。您可以使用随UnboundID LDAP SDK提供的ldap-debugger工具来准确调查正在进行的通信。
作为性能测量的一部分，您是否尝试过多次紧密循环（例如100,000次）？这可以帮助确保已经执行了所有必要的JIT编译，垃圾收集打嗝没有妨碍，并且潜在的服务器繁忙不是问题。如果你的结论只是基于每段代码的一次运行，那么很难从中得出任何真正的结论。
如果它确实看起来确实是客户端问题，那么如果您能提供更具体的详细信息以便我可以更彻底地调查问题，我将不胜感激。特别是，确切地查看正在发送哪些请求以及确切地返回哪些条目将是有帮助的（信息可以是匿名的，以便它不会泄露任何敏感数据，只要它仍然具有相同的性能特征） 。如果您愿意私下提供，请将信息发送至ldapsdk-support@unboundid.com。