[
https://issues.apache.org/jira/browse/CASSANDRA-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275473#comment-15275473
]
Ben Manes commented on CASSANDRA-10855:
---------------------------------------
[~blambov] [integrated |
https://github.com/apache/cassandra/commit/30bb255ec9fb36ace2aab51474bd3bfb9bbd3bed]
Caffeine (v2.2.6) for the chunk cache ([CASSANDRA-5863 |
https://issues.apache.org/jira/browse/CASSANDRA-5863]). He included an analysis
demonstrated good performance and hit rates. Thanks!
Note that it was in version 2.2.7 that, thanks to [~blambov] and [~benedict],
we added strong protection against HashDOS attacks. I am currently exploring an
adaptive version of the policy that improves its hit rate for small,
recency-skewed caches. This would also naturally resolve the attack without
needing our protection scheme.
The chunk cache uses a same-thread executor to delegate the maintenance work
to. While there might be a performance gain of using ForkJoinPool#commonPool
(default), this was also a very wise choice. [Druid | http://druid.io/] was
recently struck by [JDK-8078490 |
https://bugs.openjdk.java.net/browse/JDK-8078490] where a race in 8u40 - 8u60
causes the pool to not execute the task.
With [~blambov]'s work proving the benefits, can we move this forward for the
remaining caches? Afterwards I'd like to work with [~snazy] on adding the
policy to OHC to improve Cassandra's hit rates there too.
> 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)
