RFR: 8259886 : Improve SSL session cache performance and scalability

djelinski github.com+30433125+djelinski at openjdk.java.net
Mon Feb 1 18:27:41 UTC 2021


On Mon, 1 Feb 2021 18:18:51 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Under certain load, MemoryCache operations take a substantial fraction of the time needed to complete SSL handshakes. This series of patches improves performance characteristics of MemoryCache, at the cost of a functional change: expired entries are no longer guaranteed to be removed before live ones. Unused entries are still removed before used ones, and cache performance no longer depends on its capacity.
>> 
>> First patch in the series contains a benchmark that can be run with `make test TEST="micro:CacheBench"`.
>> Baseline results before any MemoryCache changes:
>> Benchmark       (size)  (timeout)  Mode  Cnt     Score    Error  Units
>> CacheBench.put   20480      86400  avgt   25    83.653 ?  6.269  us/op
>> CacheBench.put   20480          0  avgt   25     0.107 ?  0.001  us/op
>> CacheBench.put  204800      86400  avgt   25  2057.781 ? 35.942  us/op
>> CacheBench.put  204800          0  avgt   25     0.108 ?  0.001  us/op
>> there's a nonlinear performance drop between 20480 and 204800 entries, probably attributable to CPU cache thrashing. Beyond 204800 entries the cache scales more linearly.
>> 
>> Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll only copy one:
>> Benchmark       (size)  (timeout)  Mode  Cnt  Score   Error  Units
>> CacheBench.put   20480      86400  avgt   25  0.146 ? 0.002  us/op
>> CacheBench.put   20480          0  avgt   25  0.108 ? 0.002  us/op
>> CacheBench.put  204800      86400  avgt   25  0.150 ? 0.001  us/op
>> CacheBench.put  204800          0  avgt   25  0.106 ? 0.001  us/op
>> The third patch improves worst-case times on a mostly idle cache by scattering removal of expired entries over multiple `put` calls. It does not affect performance of an overloaded cache.
>> 
>> The 4th patch removes all code that clears cached values before handing them over to the GC. [This comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) stated that clearing values was supposed to be a GC performance optimization. It wasn't. Benchmark results after that commit:
>> Benchmark       (size)  (timeout)  Mode  Cnt  Score   Error  Units
>> CacheBench.put   20480      86400  avgt   25  0.113 ? 0.001  us/op
>> CacheBench.put   20480          0  avgt   25  0.075 ? 0.002  us/op
>> CacheBench.put  204800      86400  avgt   25  0.116 ? 0.001  us/op
>> CacheBench.put  204800          0  avgt   25  0.072 ? 0.001  us/op
>> I wasn't expecting that much of an improvement, and don't know how to explain it.
>> 
>> The 40ns difference between cache with and without a timeout can be attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on my VM.
>
> make/test/BuildMicrobenchmark.gmk line 97:
> 
>> 95:     SRC := $(MICROBENCHMARK_SRC), \
>> 96:     BIN := $(MICROBENCHMARK_CLASSES), \
>> 97:     JAVAC_FLAGS := $(JAVAC_FLAGS) --add-exports java.base/sun.security.util=ALL-UNNAMED, \
> 
> Why do you need to add $(JAVAC_FLAGS) here?

I'm trying to benchmark a class that is in a non-exported package `sun.security.util`. Without this line the benchmark doesn't compile. I couldn't find any other benchmarks that access non-exported classes, so I came up with my own implementation. 

Is there a better way to get the benchmark to compile?

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

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



More information about the security-dev mailing list