cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Manes (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10855) Use Caffeine (W-TinyLFU) for on-heap caches
Date Sun, 08 May 2016 05:37:13 GMT


Ben Manes commented on CASSANDRA-10855:

[~blambov] [integrated |]
Caffeine (v2.2.6) for the chunk cache ([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 |] was recently struck by [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:
>             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