[
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: [email protected]
For additional commands, e-mail: [email protected]
