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