cassandra-commits mailing list archives

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

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

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

When Cassandra moves to TPC, it should take less than a day to write a TinyLFU cache if you
borrow my [4-bit CountMin sketch|https://github.com/ben-manes/caffeine/blob/master/caffeine/src/main/java/com/github/benmanes/caffeine/cache/FrequencySketch.java].
I might evolve that to include the doorkeeper and other tricks, but it hasn't been a priority
yet. The simulator includes a variant using incremental reset (which would be my preference
for a TPC) and shows a negligible difference in hit rates. A Go developer read the paper and
wrote an implementation for fun in a few days, and I'm happy to review anyone's version.

Caffeine tackled the research and concurrency side, but no reason to adopt it once TPC. Best
to take ideas, leverage its simulator to fine tune, and share insights.

> 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)

Mime
View raw message