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

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

[2.1.0|https://github.com/ben-manes/caffeine/releases/tag/v2.1.0] was released 
which includes the above mentioned optimizations. So the cache should seem 
artificially better for an artificial workload =)

I haven't had a chance to try to add more workload profiles to the Cassandra 
tool. It would be nice if we knew what real-world distributions were like, as 
Zipf-like is what researchers published. From the traces I've experimented 
with, I am fairly confident in a net positive result.

P.S. An 
[article|http://highscalability.com/blog/2016/1/25/design-of-a-modern-cache.html]
 on HighScalability describes the overall design.

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

Reply via email to