On Thu, 29 Oct 2020 16:21:47 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>>> Did you have a benchmark with various cache sizes (for example, from 1 to >>> 10K) and various connections (for example from 1 to 10K) for those >>> components (including TLS implementation) that use Cache? >> >> Nope, we've just seen the memory regression in a certain customer use case >> (lot's of meory retained by a finalizer) and confirmed it resolved after >> setting javax.net.ssl.sessionCacheSize to 0. >> >> But I guess this change merits certain further benchmarking to get it right. > >> > Did you have a benchmark with various cache sizes (for example, from 1 to >> > 10K) and various connections (for example from 1 to 10K) for those >> > components (including TLS implementation) that use Cache? >> >> Nope, we've just seen the memory regression in a certain customer use case >> (lot's of meory retained by a finalizer) and confirmed it resolved after >> setting javax.net.ssl.sessionCacheSize to 0. >> > Did you have this patch checked with the customer? I think the performance > may be similar or improved comparing to set the cache size to 0. > >> But I guess this change merits certain further benchmarking to get it right. >> > It looks good to me, but we may be more confident with it if there is a > benchmarking. We're currently rolling out a patch to our SAP JVM shipment (based on Oracle's JDK 8 licensee repository) with exactly this content. We will then check with the customer but I'd suspect his results will about the same as with -Djavax.net.ssl.sessionCacheSize=0. If you require some benchmarking I guess it'll take me some more time. In the end I doubt that we'll find a better default value than 1 for the cache size as it's hard to predict how full a cache will be in the average. Maybe one could spend a property for the initial size - but I also doubt that's worth the effort. I also think that for the use case in StatusResponseManager's responseCache the influence of a different initial value is neglectable. ------------- PR: https://git.openjdk.java.net/jdk/pull/937
