[ https://issues.apache.org/jira/browse/SOLR-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15178389#comment-15178389 ]
Ben Manes commented on SOLR-8241: --------------------------------- Using the metrics library should be really easy. There are two simple implementation approaches, 1. Use the same approach as [Guava metrics|http://antrix.net/posts/2014/codahale-metrics-guava-cache] that polls the cache's stats. Caffeine is the next gen, so it has a nearly identical API. 2. Use a custom [StatsCounter|http://static.javadoc.io/com.github.ben-manes.caffeine/caffeine/2.2.2/com/github/benmanes/caffeine/cache/stats/StatsCounter.html] and {{Caffeine.recordStats(statsCounter)}} that records directly into the metrics. This rejected feature [request|https://github.com/google/guava/issues/2209#issuecomment-153290342] shows an example of that, though I'd return a {{disabledStatsCounter()}} instead of throwing an exception if polled. The only annoyance is neither Guava or Caffeine bothered to include a {{put}} statistic. That was partially an oversight and partially because we really wanted everyone to load through the cache (put is often an anti-pattern due to races). I forgot to add it in with v2 and due to being an API change semvar would require that it be in v3 or maybe we can use a [default method|https://blog.idrsolutions.com/2015/01/java-8-default-methods-explained-5-minutes/] hack for sneaking it into v2. > Evaluate W-TinyLfu cache > ------------------------ > > Key: SOLR-8241 > URL: https://issues.apache.org/jira/browse/SOLR-8241 > Project: Solr > Issue Type: Wish > Components: search > Reporter: Ben Manes > Priority: Minor > Attachments: SOLR-8241.patch > > > SOLR-2906 introduced an LFU cache and in-progress SOLR-3393 makes it O(1). > The discussions seem to indicate that the higher hit rate (vs LRU) is offset > by the slower performance of the implementation. An original goal appeared to > be to introduce ARC, a patented algorithm that uses ghost entries to retain > history information. > My analysis of Window TinyLfu indicates that it may be a better option. It > uses a frequency sketch to compactly estimate an entry's popularity. It uses > LRU to capture recency and operate in O(1) time. When using available > academic traces the policy provides a near optimal hit rate regardless of the > workload. > I'm getting ready to release the policy in Caffeine, which Solr already has a > dependency on. But, the code is fairly straightforward and a port into Solr's > caches instead is a pragmatic alternative. More interesting is what the > impact would be in Solr's workloads and feedback on the policy's design. > https://github.com/ben-manes/caffeine/wiki/Efficiency -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org