[
https://issues.apache.org/jira/browse/CASSANDRA-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15234287#comment-15234287
]
Benedict commented on CASSANDRA-10855:
--------------------------------------
Since I may be partially to blame for that, having made a comment suggesting
LIRS quite some time ago, I'd like to chip in my two cents:
The employment of probabilistic data structures for a cache is the obvious next
step in their evolution (something I had a hope to explore before Tiny-LFU
showed up), and Tiny-LFU being the first such scheme should absolutely be
considered *strongly*. It is simply natural that a probabilistic approach
should be capable of yielding better returns for a probabilistic application
(hit rate), and if anything I'm surprised the world has been so slow to exploit
this idea. Were I making the comment again today, I would have suggested that
Tiny-LFU be considered as the most sensible choice.
That goes doubly for the fact that any given _implementation_ is a stop-gap
until the transition to Thread-Per-Core completes and we can make all of our
algorithms more memory (and execution) efficient. Since Tiny-LFU already
exists, it does seem an obvious choice on that front.
> 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)
