On Wed, 27 Mar 2024 08:15:08 GMT, Hai-May Chao <hc...@openjdk.org> wrote:
> I ran the benchmark to measure the time needed to build a TLS context using > PKIX KeyManager (with protocols "TLSv1.2" and "TLS”) before and after the > changes to X509KeyManagerImpl.java. Here are the results: > > Without changes: Benchmark (tlsVersion) Mode Cnt Score Error Units > SSLHandshake.doHandshake TLSv1.2 thrpt 15 1073890.853 ? 18249.629 ops/s > SSLHandshake.doHandshake TLS thrpt 15 1139049.624 ? 5507.867 ops/s > > With changes: Benchmark (tlsVersion) Mode Cnt Score Error Units > SSLHandshake.doHandshake TLSv1.2 thrpt 15 130.039 ? 4.372 ops/s > SSLHandshake.doHandshake TLS thrpt 15 134.157 ? 1.903 ops/s > > For the case without changes, it has higher Error values and looks like there > is more variability in the measurements. I ran it again, and got similar > results with no background processes running. I can’t explain if there may be > environmental variables affecting the Error values. The changes that arise > time to set up cached map at initialization time will be paid off for > multiple handshaking. The Error values looks fine to me. The differences between them are caused by the differences between op/s numbers. If I read the numbers correctly, the TLS context buildup performance impact is about 100 times. The performance downgrading is not small. If I remembered correctly, a few years ago we tried hard to speed up the TLS booting up as it is very slow to initialize a TLS context and customers run into problems in their environment. Thinking about the industry effort to deploy the service in cloud environment, where need to speed up the booting time as soon as possible. In cloud or micro-service loading environment, it is more important to boot-up the context as soon as possible, comparing to speed up each connections. I don't think we have to complete the cache during the context building period. It is also possible to build the cache when the entry is required. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2023101804
