[jira] [Commented] (ACCUMULO-4466) Investigate TinyLFU as default block cache implementation

["Josh Elser (JIRA)" <ji...@apache.org>]

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

Josh Elser commented on ACCUMULO-4466:
--------------------------------------

Comment from [~ben.manes] on testing/perf for future reference:

{quote}
I agree the numbers are too close to judge and falls within the margin of error. The Lru cache is quite good by not suffering lock contention, delegating the penalties to a background thread, and being segmented to capture basic frequencies. The YCSB Zipf benchmarks are ideal for it, as the policy can offer a perfect hit rate and concurrency. Caffeine can do similar with a small additional overhead due to spreading out the maintenance work for more flexibility and to avoid O\(n\) operations.

So we can't argue improved concurrency or an improved hit rate (which reduces latencies) for the Zipf workloads. Instead we can claim to be on par and that there is little to no degredation. The gain should come in an improved hit rate for real-world workloads, which can be quite different than synthetic distributions. This might require evaluating on a live cluster, unfortunately. It might be interesting to capture real cluster traces feed that through YCSB if we wanted a more robust, repeatable comparison.
{quote}

> Investigate TinyLFU as default block cache implementation
> ---------------------------------------------------------
>
>                 Key: ACCUMULO-4466
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4466
>             Project: Accumulo
>          Issue Type: Task
>          Components: tserver
>            Reporter: Josh Elser
>             Fix For: 2.0.0
>
>
> ACCUMULO-4177 brought in TinyLfuBlockCache which shows some potential over our LruMap from HBase.
> We should run some benchmarks that we can stand behind and determine if we should be switching the default cache implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)