This discussion is archived
5 Replies Latest reply: Apr 24, 2012 2:58 PM by wetmore RSS

LDAP/SSL performance degradation with 1.6.29/1.6.30

910667 Newbie
Currently Being Moderated
Hi,

we are running an application within a Tomcat 6.0.35 server on RHEL 5.7/i386 that queries our company's Active Directory using LDAP over SSL. One of the queries involves expanding a large distribution list. Since the upgrade from JDK 1.6.27 to 1.6.29 (or 1.6.30) the performance of this LDAP query has degraded dramatically, from about 8 seconds to more than 300 seconds. This only happens when encrypting the LDAP connection.

We are not sure how to debug this further. Which information would we need to provide to get to the root of this? I was thinking that perhaps the Tomcat output with the javax.net.debug=ssl,handshake property set for 1.6.27 and 1.6.29/30 would be sufficient?

With Java 1.6.29/30, the basic response/reply between the Tomcat and the AD server looks like:

TP-Processor11, WRITE: TLSv1 Application Data, length = 32
TP-Processor11, WRITE: TLSv1 Application Data, length = 160
Thread-270, READ: TLSv1 Application Data, length = 16368
Thread-270, READ: TLSv1 Application Data, length = 16368
Thread-270, READ: TLSv1 Application Data, length = 11920
TP-Processor11, WRITE: TLSv1 Application Data, length = 32
TP-Processor11, WRITE: TLSv1 Application Data, length = 160
Thread-270, READ: TLSv1 Application Data, length = 16368
Thread-270, READ: TLSv1 Application Data, length = 16368
Thread-270, READ: TLSv1 Application Data, length = 11920

When using Java 1.6.27, we see:

TP-Processor12, WRITE: TLSv1 Application Data, length = 208
Thread-42, READ: TLSv1 Application Data, length = 16368
Thread-42, READ: TLSv1 Application Data, length = 16368
Thread-42, READ: TLSv1 Application Data, length = 5696
TP-Processor12, WRITE: TLSv1 Application Data, length = 208
Thread-42, READ: TLSv1 Application Data, length = 16368
Thread-42, READ: TLSv1 Application Data, length = 16368
Thread-42, READ: TLSv1 Application Data, length = 5696

Looking at the 32 bytes long requests (with javax.net.debug=all set), we see:

Padded plaintext before ENCRYPTION: len = 32
0000: 30 0C C2 32 83 6E 9F D8 8F 5E E8 47 7A 0B 9A F1 0..2.n...^.Gz...
0010: 7D 44 78 0B 9E 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A .Dx.............
TP-Processor1, WRITE: TLSv1 Application Data, length = 32

Which doesn't make a whole lot of sense to us...

Any help debugging this further would be most welcome.

Cheers
Stefan
  • 1. Re: LDAP/SSL performance degradation with 1.6.29/1.6.30
    EJP Guru
    Currently Being Moderated
    1.6.0_29 is writing the request in two chunks rather than one, which might cause a small ciphertext size increase, and receiving (11920-5696) bytes less in reply for some unknown reason, very curious, but there is nothing there that would cause an 8/300 performance degradation, unless there is very significant time between e.g. the 32-byte write and the 160-byte write, and I don't see any reason why there would be. Is there any timing information in the AD logs? And are you sure it's exactly the same LDAP query? with the same results?
  • 2. Re: LDAP/SSL performance degradation with 1.6.29/1.6.30
    910667 Newbie
    Currently Being Moderated
    We are sure that our application generates the same LDAP queries, whether the LDAP connection is secured with TLS or not.

    Unfortunately, I'm not sure how I could generate timing information. Just looking at the log, the queries/responses are generally a lot slower with 1.6.0_29, but that's just what our "eyeball mark I" tells us. Do you have any idea how we could generate timing data?
  • 3. Re: LDAP/SSL performance degradation with 1.6.29/1.6.30
    912911 Newbie
    Currently Being Moderated
    I have experienced this same issue with the performance of a utility library which queries an LDAP connection over SSL. In 1.6.0_27 it took 1-2 seconds to perform a common task with the library and now it takes somewhere around 50 seconds to perform the same task with 1.6.0_29/30. I found that if we replace the jre/lib/jsse.jar in the newer JDK with the one from 1.6.0_27 we can get around this issue so I wonder if there is another regression bug similar to this one: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7103725

    Thanks,
    James

    Edited by: 909908 on Jan 24, 2012 6:34 AM
  • 4. Re: LDAP/SSL performance degradation with 1.6.29/1.6.30
    910667 Newbie
    Currently Being Moderated
    Hi James,

    have you opened a bug report against the JRE/JDK? If so, would you mind telling me the bug number?

    If not, do yo have any ideas on what the best way of further pursuing this issue is?


    Thanks
    Stefan
  • 5. Re: LDAP/SSL performance degradation with 1.6.29/1.6.30
    wetmore Newbie
    Currently Being Moderated
    Using a SSLSocketFactory which generate SSLSocket that have socket.setTcpNoDelay(true) set took care of the problem. Likely the same problem as described in

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7157903

    Edited by: wetmore on Apr 12, 2012 2:39 PM

    The fix for 7157903 is now in the *7u6* developer preview (build 06) at http://jdk7.java.net/. This addressed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133330 , which is is the specific bug filed for LDAP.

    Report back if this doesn't solve the issue.

    Edited by: wetmore on Apr 24, 2012 2:58 PM

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points