<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Thank you Bernd for looking into this!</p>
<br>
<div class="moz-cite-prefix">On 11/7/17 11:42 PM, Bernd Eckenfels
wrote:<br>
</div>
<blockquote
cite="mid:AM4PR08MB1219BF1297421C9FB201758EFF560@AM4PR08MB1219.eurprd08.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
<div>
<div id="x_compose-container" itemscope=""
itemtype="https://schema.org/EmailMessage"
style="direction:ltr">
<span itemprop="creator" itemscope=""
itemtype="https://schema.org/Organization"><span
itemprop="name"></span></span>
<div>
<div style="direction:ltr">
<div style="direction:ltr">Hello,</div>
<div><br>
</div>
<div style="direction:ltr">There is already a property to
set the cache size, would it be enough to re-purpose a
cache size of 0 to turn it off?</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
Currently, setting the cache size to 0 means that it is unbounded,
so that the entries are removed from the cache only when they get
expired.<br>
<br>
<blockquote
cite="mid:AM4PR08MB1219BF1297421C9FB201758EFF560@AM4PR08MB1219.eurprd08.prod.outlook.com"
type="cite">
<div>
<div id="x_compose-container" itemscope=""
itemtype="https://schema.org/EmailMessage"
style="direction:ltr">
<div>
<div style="direction:ltr">
<div>
</div>
<div style="direction:ltr">Are there numbers to show when
this is actually a problem? Is this only for 100% Cache
misses?</div>
</div>
</div>
</div>
</div>
</blockquote>
We've seen dumps with lots of threads blocked waiting on the
Cache.get()/put()/remove().<br>
This is primarily due to the time spent in the cache cleaning
routines (see
sun.security.util.MemoryCache.emptyQueue()/expungeExpiredEntries()),
which are executed inside the synchronization block.<br>
This time is linear on the size of cache, but limiting the cache
size doesn't always help either, as the amount of cleanup work also
increases with a bounded cache.<br>
<br>
Allowing to avoid to use the cache removed this bottleneck and under
certain conditions the throughput increased from 35 to 120 sessions
per second.<br>
<br>
Please note that the proposed option javax.net.ssl.needCacheSessions
will be true by default, so the default behavior will not change.<br>
Only in specific situation, if it is proved that turning off the
cache will improve performance, this option will be recommended to
be set to false. <br>
<br>
<blockquote
cite="mid:AM4PR08MB1219BF1297421C9FB201758EFF560@AM4PR08MB1219.eurprd08.prod.outlook.com"
type="cite">
<div>
<div id="x_compose-container" itemscope=""
itemtype="https://schema.org/EmailMessage"
style="direction:ltr">
<div>
<div style="direction:ltr">
<div style="direction:ltr"> Maybe the cache itself needs
some optimizations?</div>
</div>
</div>
</div>
</div>
</blockquote>
Certainly, it would be very good to optimize the cache
implementation!<br>
I've made a few attempts, but failed to achieve a significant
improvement in different scenarios.<br>
The complication is due to the two requirements: maintaining fixed
cache capacity and maintaining FIFO order when removing the
entries. This makes it hard to use the concurrent data structures
as is.<br>
<br>
Still, I'm totally for the cache optimization in JDK 10, if it is
possible.<br>
However, if it is done, it would not be probably backported to the
earlier releases.<br>
<br>
And I'm going to propose to backport the proposed fix with the
option to turn off the cache, as it will be useful for some
currently running applications. <br>
<br>
With kind regards,<br>
Ivan<br>
<br>
<blockquote
cite="mid:AM4PR08MB1219BF1297421C9FB201758EFF560@AM4PR08MB1219.eurprd08.prod.outlook.com"
type="cite">
<div>
<div id="x_compose-container" itemscope=""
itemtype="https://schema.org/EmailMessage"
style="direction:ltr">
<div>
<div style="direction:ltr">
<div style="direction:ltr"> (It is hard to imagine that a
saved handshake does not compensate for hundreds of gets
- especially if the current version still would generate
a cache key)</div>
<div><br>
</div>
<div style="direction:ltr">Gruss</div>
<div style="direction:ltr">Bernd</div>
</div>
<div><br>
</div>
<div class="x_acompli_signature">
<div>Gruss</div>
<div>Bernd</div>
<div>-- </div>
<div><a moz-do-not-send="true" dir="ltr"
href="http://bernd.eckenfels.net">http://bernd.eckenfels.net</a></div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
color="#000000" face="Calibri, sans-serif"><b>From:</b>
security-dev <a class="moz-txt-link-rfc2396E" href="mailto:security-dev-bounces@openjdk.java.net"><security-dev-bounces@openjdk.java.net></a>
on behalf of Ivan Gerasimov
<a class="moz-txt-link-rfc2396E" href="mailto:ivan.gerasimov@oracle.com"><ivan.gerasimov@oracle.com></a><br>
<b>Sent:</b> Wednesday, November 8, 2017 3:24:54 AM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a><br>
<b>Subject:</b> [10] RFR : 8186628 : SSL session cache can
cause a scalability bottleneck</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hello everybody!<br>
<br>
The class sun.security.ssl.SSLSessionContextImpl maintains
caches for <br>
the sessions reuse.<br>
Access to the cache from threads is serialized.<br>
It was reported that under heavy load the time of waiting
for the turn <br>
to access the synchronized methods outweighs the time of
creating a new <br>
session.<br>
<br>
It is proposed to introduce a flag that will allow to avoid
using the <br>
cache altogether.<br>
Would you please help review the proposed fix?<br>
<br>
BUGURL: <a moz-do-not-send="true"
href="https://bugs.openjdk.java.net/browse/JDK-8186628">https://bugs.openjdk.java.net/browse/JDK-8186628</a><br>
WEBREV: <a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Eigerasim/8186628/00/webrev/">http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/</a><br>
<br>
-- <br>
With kind regards,<br>
Ivan Gerasimov<br>
<br>
</div>
</span></font>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
With kind regards,
Ivan Gerasimov</pre>
</body>
</html>