RFR: 8274308: Improve efficiency for HandshakeContext initialization.

Daniel Jeliński github.com+30433125+djelinski at openjdk.java.net
Mon Oct 4 06:34:20 UTC 2021


On Sat, 2 Oct 2021 05:45:47 GMT, Clive Verghese <cverghese at openjdk.org> wrote:

> Hi,
> 
> We have identified that the `HandshakeContext` initialization takes up a close to 50% of the flame graph for startHandshake. I have moved the computation of the `activeProtocols` and `activeCipherSuites` from the HandshakeContext constructor to SSLConfiguration class because the values used to compute the two list are available in the SSLConfiguration. 
> 
> In order to reuse this, I have initialized SSLConfiguration in the SSLSocketFactory and reused this when possible for Client Socket Constructors in the SSLSocketImpl. 
> 
> Sockets created from the SSLSocketFactory see this improvements. 
> 
> Old Benchmarks
> 
> Benchmark                                   Mode  Cnt  Score   Error   Units
> SSLStartHandshake.handshakeBenchmark       thrpt   25  0.247 ± 0.011  ops/ms
> SSLStartHandshake.handshakeBenchmark        avgt   25  4.210 ± 0.445   ms/op
> 
> New Benchmarks
> 
> SSLStartHandshake.handshakeBenchmark       thrpt   25  0.257 ± 0.017  ops/ms
> SSLStartHandshake.handshakeBenchmark        avgt   25  3.967 ± 0.208   ms/op
> 
> 
> 
> I have also attached the JFR profiles from before and after the change.
> Before
> <img width="2325" alt="SSLOverhead-old" src="https://user-images.githubusercontent.com/934461/135705010-a8502966-c6be-4cb5-b743-4a5b382c8e1f.png">
> 
> After 
> <img width="2310" alt="SSLOverhead-new" src="https://user-images.githubusercontent.com/934461/135705007-ea852b36-e10f-4741-a166-249270b34465.png">
>  
> We have been able to optimize the `TransportContext.kickstart` function by removing the `HandshakeContext.<init>`  initialization and reduce the time to start the handshake by reusing `activeProtocols` and `activeCipherSuites`
> 
> In addition to the SSL and http tests, I have run tier-1 and tier-2 tests and ensure that they pass. 
> 
> Looking for your feedback

The results look very impressive. Could you also benchmark SSLEngine? With SSLEngine we could benchmark the improvements on client and server side separately, and OS's socket handling wouldn't influence the results.

I quickly hacked together a SSLEngine benchmark for server-side handshakes [here](https://github.com/djelinski/jdk/blob/2bee5c471b41d60d4248d5d16e868060f0efda19/test/micro/org/openjdk/bench/java/security/SSLEngineStartHandshake.java); note that on the server side I run the following code on every connection;

            SSLEngine serverEngine = context.createSSLEngine();
            serverEngine.setUseClientMode(false);
            serverEngine.setEnabledProtocols(new String[]{"TLSv1.3"});
            serverEngine.setEnabledCipherSuites(new String[]{"TLS_AES_256_GCM_SHA384"});
            serverEngine.beginHandshake();

not sure if that's the best way to initialize SSLEngine. Anyway, in this setup I observed a 16% performance degradation; results without your patch:

Benchmark                                         Mode  Cnt  Score   Error   Units
SSLEngineStartHandshake.handshakeBenchmark       thrpt   25  0.837 ± 0.006  ops/ms
SSLEngineStartHandshake.handshakeBenchmark        avgt   25  1.187 ± 0.006   ms/op

with your patch:

Benchmark                                         Mode  Cnt  Score   Error   Units
SSLEngineStartHandshake.handshakeBenchmark       thrpt   25  0.702 ± 0.009  ops/ms
SSLEngineStartHandshake.handshakeBenchmark        avgt   25  1.416 ± 0.013   ms/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/5793



More information about the security-dev mailing list