Hi Peter!
Thank you very much for looking into this!
On 11/22/17 1:45 AM, Peter Levart wrote:
Hi Ivan,
Here's my attempt to increase multithreaded scalability of Cache:
http://cr.openjdk.java.net/~plevart/jdk10-dev/8186628_ssl_session_cache_scalability/webrev.01/
Haven't tested this yet, but I thought that since you already have
relevant performance tests, you might want to try this, so I decided
to release it as is.
I plugged your implementation into the benchmark I had [*] and got these
numbers for the throughput:
Original MemoryCache: 4,116,537 puts/second
Your variant: 2,942,561 puts/second
So, in the tested scenario performance downgraded by 28%.
Still, I think it's important to try to improve performance of the
MemoryCache and, if possible, remove the points of contention.
Rough sketch of changes:
- replaced LinkedHashMap with ConcurrentHashMap
- CacheEntry(s) are additionaly linked into a double-linked list.
DL-list management is the only synchronization point (similar to
Cleaner API) and the rule is: 1st new entry is linked into DL-list,
then it is put into map - published. The same with removing: 1st an
entry is unlinked from DL-list, then if successfull, removed from map
and invalidated.
- changed the way expiry is handled so that the whole list is never
needed to be scanned.
The code speaks for itself.
Your implementation is somewhat similar to what I had tried before
coming up with proposal of the option to turn the cache off.
I used ConcurrentHashMap + ConcurrentLinkedQueue to maintain the FIFO
order, still the performance was a few percent less then the one of the
original implementation.
That's really why I decided to split the issue:
- first, provide an option to turn the cache off (that should be easily
backported and can provide immediate relief to the customers that
experience the scalability bottleneck;
- second, continue work on the cache implementation improvements.
Let me know if you find it usefull and/or it solves the scalability
bottleneck.
Yes, I think it's very useful!
However, as I wrote above, I think that the issue needs be split into
two parts: an option to turn the caching off (which can be easily
backported) and improving the cache implementation (which can even relax
the requirements, as the FIFO order or absolutely hard upper bound of
the cache size).
With kind regards,
Ivan
Regards, Peter
On 11/21/17 14:16, Ivan Gerasimov wrote:
Thanks Xuelei for the comment!
On 11/20/17 8:50 PM, Xuelei Fan wrote:
Hi Ivan,
I understand the desire of performance improvement. But I don't
think avoiding the use of cache is the price we want to pay for.
Besides, avoiding using of session cache is not something improving
the performance in general, it is typically something impacting the
performance, a lot sometimes.
The proposal is not meant to be a general solution.
Clearly, turning the session cache off will increase the average time
of session creation.
However, if the cache becomes the reason of a bottleneck due to high
contention, then turning it off helps by just shortening the waiting
time for each thread.
The option is set to true by default, i.e. the cache is used.
Only if the application is used in such a way that high contention
for the cache is exposed, then the setting the option to false may
help to improve performance.
With kind regards,
Ivan
Xuelei
On 11/20/2017 5:36 PM, Ivan Gerasimov wrote:
Gentle ping.
If people agree on the approach, I'll go ahead and file a CCC
request for the new recognized system property.
With kind regards,
Ivan
On 11/7/17 6:24 PM, Ivan Gerasimov wrote:
Hello everybody!
The class sun.security.ssl.SSLSessionContextImpl maintains caches
for the sessions reuse.
Access to the cache from threads is serialized.
It was reported that under heavy load the time of waiting for the
turn to access the synchronized methods outweighs the time of
creating a new session.
It is proposed to introduce a flag that will allow to avoid using
the cache altogether.
Would you please help review the proposed fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186628
WEBREV: http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/
--
With kind regards,
Ivan Gerasimov
