On Mon, 22 Feb 2021 21:31:21 GMT, Xue-Lei Andrew Fan wrote:
>> Actually there's a much easier solution to reduce the number of slow
>> `put()`s without making any behavioral changes.
>> The cache object could store the earliest expire time, and then exit
>> `expungeExpiredEntries()` early when
On Mon, 22 Feb 2021 21:31:21 GMT, Xue-Lei Andrew Fan wrote:
>> Actually there's a much easier solution to reduce the number of slow
>> `put()`s without making any behavioral changes.
>> The cache object could store the earliest expire time, and then exit
>> `expungeExpiredEntries()` early when
On Mon, 22 Feb 2021 20:36:53 GMT, djelinski
wrote:
> Actually there's a much easier solution to reduce the number of slow `put()`s
> without making any behavioral changes.
> The cache object could store the earliest expire time, and then exit
> `expungeExpiredEntries()` early when current time
On Tue, 16 Feb 2021 19:38:50 GMT, djelinski
wrote:
>>> I may think it differently. It may be hard to know the future frequency of
>>> an cached item based on the past behaviors. For the above case, I'm not
>>> sure that K=3 is used less frequently than K=1. Maybe, next few seconds,
>>> K=1 co
On Wed, 10 Feb 2021 19:19:33 GMT, djelinski
wrote:
>>> Thanks for your review! Some comments below.
>>>
>>> > A full handshake or OCSP status grabbing could counteract all the
>>> > performance gain with the cache update.
>>>
>>> Yes, but that's unlikely. Note that K=3 is before K=1 in the qu
On Wed, 10 Feb 2021 00:44:57 GMT, Xue-Lei Andrew Fan wrote:
> I may think it differently. It may be hard to know the future frequency of an
> cached item based on the past behaviors. For the above case, I'm not sure
> that K=3 is used less frequently than K=1. Maybe, next few seconds, K=1 could
On Tue, 9 Feb 2021 08:44:28 GMT, djelinski
wrote:
> So, how do we want to proceed here? Is the proposed solution acceptable? If
> not, what needs to change? if yes, what do I need to do next?
For me, it is a pretty good solution, but I have some concerns. I appreciate
if you would like to re
On Thu, 4 Feb 2021 20:45:55 GMT, djelinski
wrote:
> Thanks for your review! Some comments below.
>
> > A full handshake or OCSP status grabbing could counteract all the
> > performance gain with the cache update.
>
> Yes, but that's unlikely. Note that K=3 is before K=1 in the queue only
> b
On Thu, 4 Feb 2021 20:45:55 GMT, djelinski
wrote:
>> Thank you for the comment. The big picture is more clear to me now.
>>
>>> Example 2:
>>> Old implementation will get:
>>> |K=3, exp=10|K=5, exp=12|K=7, exp=14|K=9, exp=16|
>>>
>>> New implementation will get:
>>> |K=5, exp=12|K=7, exp=14|K=1
On Thu, 4 Feb 2021 19:36:24 GMT, Xue-Lei Andrew Fan wrote:
>> Added benchmarks for get & remove. Added tests for 5M cache size. Switched
>> time units to nanoseconds. Results:
>> Benchmark (size) (timeout) Mode CntScore Error Units
>> CacheBench.get 20480 86400 av
On Thu, 4 Feb 2021 19:17:21 GMT, djelinski
wrote:
>>> the benchmark performance improvement is a trade-off between CPU and
>>> memory, by keeping expired entries while putting a new entry in the cache
>>
>> Not exactly. The memory use is capped by cache size. The patch is a trade
>> off betwe
On Tue, 2 Feb 2021 12:19:22 GMT, djelinski
wrote:
>> If I get the patch right, the benchmark performance improvement is a
>> trade-off between CPU and memory, by keeping expired entries while putting a
>> new entry in the cache. I'm not very sure of the performance impact on
>> memory and GC
On Tue, 2 Feb 2021 02:37:39 GMT, Xue-Lei Andrew Fan wrote:
> the benchmark performance improvement is a trade-off between CPU and memory,
> by keeping expired entries while putting a new entry in the cache
Not exactly. The memory use is capped by cache size. The patch is a trade off
between th
On Mon, 1 Feb 2021 18:49:04 GMT, djelinski
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: e
On Mon, 1 Feb 2021 22:45:17 GMT, Claes Redestad wrote:
>> Build change looks good, but I would like to hear from @cl4es too.
>
> Adding an `--add-exports` to `JAVAC_FLAGS` is a bit iffy, but should be OK.
> Yes, all benchmarks will now be compiled with that package exported and
> visible, but t
On Mon, 1 Feb 2021 19:22:22 GMT, Erik Joelsson wrote:
>> djelinski has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify makefile
>
> Build change looks good, but I would like to hear from @cl4es too.
Adding an `--add-exports` to `JA
On Mon, 1 Feb 2021 18:49:04 GMT, djelinski
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: e
On Mon, 1 Feb 2021 18:35:56 GMT, djelinski
wrote:
>> Hm, maybe you just misunderstand how this makefile construct works. If you
>> just want to add "--add-exports java.base/sun.security.util=ALL-UNNAMED",
>> then that's all you should put in this assignment.
>
> yeah, I'm new to makefiles. Let
> 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 bef
19 matches
Mail list logo
