Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 7 Jan 2016 11:48:39 +0000 (UTC)
From: "Ben Manes (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12921575.1450076484000.43099.1452167319918@Atlassian.JIRA>
In-Reply-To: <JIRA.12921575.1450076484000@Atlassian.JIRA>
References: <JIRA.12921575.1450076484000@Atlassian.JIRA>
 <JIRA.12921575.1450076484797@arcas>
Subject: [jira] [Commented] (CASSANDRA-10855) Use Caffeine (W-TinyLFU) for
 on-heap caches
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

The latest [snapshot jar|https://oss.sonatype.org/content/repositories/snapshots/com/github/ben-manes/caffeine/caffeine] includes a two optimizations.

Insertions now avoid an unnecessary lambda. I suspect that will have a negligible benefit, but its always good to be more GC hygienic.

A cache below 50% capacity will skip read policy work. That means it won't record the access in ring buffers which reduces contention. That also reduces the how often policy the maintenance work is scheduled, as the buffers don't need to be drained. A write will still trigger a maintenance cycle, but that should be shorter by doing less. This result in throughput close to a raw ConcurrentHashMap and then incurring the penalty when the threshold is crossed. That should improve _trades-fwd-lcs-nolz4_ and anyone else's usage where the cache is merely a safety threshold but isn't likely to grow close to the maximum.

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