Nice.
On 22/04/2022 6:47 am, Daniel Jeliński wrote:
On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
portion of time is spent in HandshakeContext initialization, specifically in
DisabledAlgorithmConstraints class.
There are only a few instances of that class, and they are immutable. Caching
the results should be a low-risk operation.
The cache is implemented as a softly reachable ConcurrentHashMap; this way it
can be removed from memory after a period of inactivity. Under normal
circumstances the cache holds no more than 100 algorithms.
before:
Benchmark (resume) (tlsVersion) Mode Cnt Score
Error Units
SSLHandshake.doHandshake true TLSv1.2 thrpt 5 2165.081 ±
440.204 ops/s
SSLHandshake.doHandshake true TLS thrpt 5 534.681 ±
146.931 ops/s
SSLHandshake.doHandshake false TLSv1.2 thrpt 5 369.104 ±
11.143 ops/s
SSLHandshake.doHandshake false TLS thrpt 5 253.903 ±
58.056 ops/s
after:
Benchmark (resume) (tlsVersion) Mode Cnt Score
Error Units
SSLHandshake.doHandshake true TLSv1.2 thrpt 5 10440.501 ±
478.177 ops/s
SSLHandshake.doHandshake true TLS thrpt 5 762.995 ±
33.842 ops/s
SSLHandshake.doHandshake false TLSv1.2 thrpt 5 440.471 ±
52.867 ops/s
SSLHandshake.doHandshake false TLS thrpt 5 305.928 ±
57.847 ops/s
After this patch the HandshakeContext initialization practically disappears
from the CPU profile; it only takes ~5% in TLS1.2 resumption, and much less in
the remaining scenarios.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8349
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
