[
https://issues.apache.org/jira/browse/CASSANDRA-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15071741#comment-15071741
]
Robert Stupp commented on CASSANDRA-10855:
------------------------------------------
[Ran CI|http://cassci.datastax.com/search/?q=10855] against (rebased) branch
and the results look good to me (i.e. no regression).
Unfortunately the cstar perf runs
([trades-fwd-lcs-nolz4|http://cstar.datastax.com/tests/id/6fcb6cbc-aafa-11e5-947f-0256e416528f]
and [cassci regression test
r/w|http://cstar.datastax.com/tests/id/6b113b02-aafa-11e5-947f-0256e416528f])
show that using Caffeine for the key cache slightly _degrades_ performance in
terms of throughput and latencies. Some percentiles (mostly max latencies) are
slightly better, but the overall result is that performance degrades. The
key-cache hit rate is slightly better with Caffeine (trades-fwd-lcs-nolz4
showing slightly more than 10% hit rate w/ Caffeine vs. slightly less than 10%
w/o Caffeine).
_trades-fwd-lcs-nolz4_ uses somewhat bigger partitions and fills the key cache
completely.
_regression r/w_ uses small partitions and just uses roughly 10% of the key
cache.
perf runs used a 3-node C* cluster (“blade_11_b”) - each node having 2 6-code
Xeon CPUs having a total of 64GB RAM.
>From a _really quick & brief_ view at the Caffeine source, I *suspect* that
>the worse numbers are caused by the spinning loops. Also padding fields, which
>can behave completely different on NUMA than on singe-CPU systems, may have
>some bad influence in this test.
> 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)
