[ 
https://issues.apache.org/jira/browse/CASSANDRA-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602688#comment-15602688
 ] 

Ben Manes commented on CASSANDRA-10855:
---------------------------------------

The test failure might be due to delegating maintenance work (e.g. writes 
triggering an eviction) to an executor. CLHM and Guava amortized this on the 
calling threads, whereas Caffeine tries to hide it on ForkJoinPool to minimize 
user-facing latencies. By setting Caffeine.executor(Runnable::run) it will 
behave similar to its predecessors, ideally set only in tests for 
predictability. Alternatively calling cache.cleanUp() prior to inspecting is 
another easy alternative.

I don't want to delay this again, but would like to ensure Cassandra updates to 
the upcoming 2.3.4 release. There is a difficult to trigger 
[race|https://github.com/ben-manes/caffeine/issues/127] in JCTools that we 
fixed over the weekend.

> Use Caffeine (W-TinyLFU) for on-heap caches
> -------------------------------------------
>
>                 Key: CASSANDRA-10855
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10855
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Ben Manes
>              Labels: performance
>         Attachments: CASSANDRA-10855.patch, CASSANDRA-10855.patch
>
>
> Cassandra currently uses 
> [ConcurrentLinkedHashMap|https://code.google.com/p/concurrentlinkedhashmap] 
> for performance critical caches (key, counter) and Guava's cache for 
> non-critical (auth, metrics, security). All of these usages have been 
> replaced by [Caffeine|https://github.com/ben-manes/caffeine], written by the 
> author of the previously mentioned libraries.
> The primary incentive is to switch from LRU policy to W-TinyLFU, which 
> provides [near optimal|https://github.com/ben-manes/caffeine/wiki/Efficiency] 
> hit rates. It performs particularly well in database and search traces, is 
> scan resistant, and as adds a very small time/space overhead to LRU.
> Secondarily, Guava's caches never obtained similar 
> [performance|https://github.com/ben-manes/caffeine/wiki/Benchmarks] to CLHM 
> due to some optimizations not being ported over. This change results in 
> faster reads and not creating garbage as a side-effect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to