On Sun, 3 Oct 2021 18:20:29 GMT, Daniel Jeliński <github.com+30433125+djelin...@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 > > 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 Hi @djelinski Thank you for putting this together. I will investigate the results of your benchmarks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5793
![https://user-images.githubusercontent.com/934461/135705010-a8502966-c6be-4cb5-b743-4a5b382c8e1f.png"](https://user-images.githubusercontent.com/934461/135705010-a8502966-c6be-4cb5-b743-4a5b382c8e1f.png"){kind=link}
![https://user-images.githubusercontent.com/934461/135705007-ea852b36-e10f-4741-a166-249270b34465.png"](https://user-images.githubusercontent.com/934461/135705007-ea852b36-e10f-4741-a166-249270b34465.png"){kind=link}