Testing JDK 7u4 java-based SSL clients to drive webserver traffic has regressed by two orders of magnitude. Our JSSE clients can drive >7400 requests/second with JDK 6 but only 124 requests/second with JDK 7u4 (and some earlier JDK 7 releases).

Although we are testing on JDK 7u4, I have tracked the regression to JDK 7u1 b06 when the code to split the first record data was added. If I run with -Djsse.enableCBCProtection=false then performance returns to normal.

The comment in that code indicates that we don't need to split if the TLS version is 1.1 or greater. In this case, the client is talking to a Java appserver also running with the JDK 7u4 JSSE libraries, so I'm not sure why it didn't negotiate an appropriate protocol to skip this.

The other odd thing I notice is that we don't seem to be writing the appropriate amount of data. If I turn on SSL debugging with the default behavior, I see this:

Thread-0, WRITE: TLSv1 Application Data, length = 80 // FIRST REQUEST
Thread-0, READ: TLSv1 Application Data, length = 160
Thread-0, READ: TLSv1 Application Data, length = 32
Thread-0, READ: TLSv1 Application Data, length = 240
Thread-0, WRITE: TLSv1 Application Data, length = 32 // SECOND REQUEST
Thread-0, WRITE: TLSv1 Application Data, length = 80
Thread-0, READ: TLSv1 Application Data, length = 32
Thread-0, READ: TLSv1 Application Data, length = 160
Thread-0, READ: TLSv1 Application Data, length = 32
Thread-0, READ: TLSv1 Application Data, length = 240

The code is writing the same request repeatedly, so the data length of the first two requests should be the same; I'm not sure why in the second request we send a total of 112 bytes. But maybe that is just the way it works; I see that the server response in the first case (where it also didn't split the request) is a total 432 bytes but in the second case (it's second write, hence now splitting) also has an extra 32 bytes. When I add the -Djsse argument only to the client, the server still sends the extra 32 byte record but the client performance is back to normal.