[
https://issues.apache.org/jira/browse/CASSANDRA-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056294#comment-15056294
]
Ariel Weisberg commented on CASSANDRA-10855:
--------------------------------------------
I don't object to swapping CLHM with a new implementation. As a matter of
principle we should measure what impact this has so we can understand the yield
of the optimizations in tiny LFU. We shouldn't be making changes for
performance without measuring, but also so we can inform the evolution of OHC
which solves the GC pressure issue.
I see on heap caches, memtables, and any other source of high volume survivor
copying and promotion as a dead end.
We changed the format of the key cache for 3.0 so that it would be suitable for
memory mapping, but didn't get the change in to actually use a memory mapped
access method. Robert Stupp did write a lot of the code, but it was still using
OHC as the cache. I suspect that will get us the 80%, but someone has to pick
that up. [~JoshuaMcKenzie] we should think about if we want to schedule if we
want to boost read performance and tail latencies due to reduced heap pressure.
> 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
>
> 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)
