Reputation: 467
I am trying to upgrade a web application made in Java EE, using Tomcat. Till now I have been using the Netscape ldap implementation, and now I am trying to upgrade to Unboundid Ldap. The problem is that the Unboundid implementation has a very high delay comparing to the netscape implementation.
Some info on what I am planning to do: I want to get from LDAP the last 5 entries, put them in an array and display this array in a webpage.
EDIT1: I have created 2 sample apps for testing the libraries, using Java SE. For each test I have attached the source code and the server side LDAP log.
The results are the same, no matter how may iterations I use, it takes on average much longer to retrieve the results using the UnboundID SDK implementation.
For Netscape LDAP SDK: code and log. For UnboundID LDAP SDK: code and log
EDIT2: I am also trying to use the ldap-debugger tool, provided by UnboundID, but I can't figure how to make it work, I see that it takes as arguments the ip and port on which to bind, and the clients should connect the the ldap-debugger and he will act as a proxy, but where do I specify the server ip and port, because in the client I've already put the ip and port for ldap-debugger ?
Upvotes: 0
Views: 228
Reputation: 1736
There isn't anything that immediately jumps out about the code that you're using. In my testing, the UnboundID LDAP SDK is much faster than the Netscape SDK. While it's certainly possible that you've found some kind of corner case, I'd like to rule out a few other possibilities.
First of all, how are you determining how long each version takes to execute? Are you using client-side timing (e.g., System.currentTimeMillis(), run the code, System.currentTimeMillis() again) or server-side timing (e.g., processing time reported in the server access log)? If the difference only exists on the client side, then that definitely could point to an SDK issue, but if the difference also appears on the server side, then maybe there's something different about the requests that are being sent that causes the server to do more work in one case than the other. You could potentially use the ldap-debugger tool provided with the UnboundID LDAP SDK to investigate exactly what communication is taking place.
Have you tried running each in a tight loop large number of times (say, 100,000) as part of the performance measurement? This can help ensure that all the necessary JIT compilation has been performed, that garbage collection hiccups aren't getting in the way, and that potential server busyness isn't a problem. If your conclusion is based on just one run of each piece of code, then it's hard to draw any real conclusions from that.
If it really does appear to be a client-side issue, then I would appreciate if you could provide more specific details so that I can investigate the problem more thoroughly. In particular, it would be helpful to see exactly what requests are being sent and exactly what entries are being returned (the information can be anonymized so that it doesn't reveal any sensitive data, as long as it still exhibits the same performance characteristics). You can send the information to [email protected] if you'd rather provide it privately.
Upvotes: 0