cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10855) Use Caffeine (W-TinyLFU) for on-heap caches
Date Sun, 10 Apr 2016 21:23:25 GMT


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:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Ben Manes
>              Labels: performance
> Cassandra currently uses [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|],
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|] 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|]
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

View raw message