[
https://issues.apache.org/jira/browse/SOLR-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15178727#comment-15178727
]
Shawn Heisey commented on SOLR-8241:
------------------------------------
bq. neither Guava or Caffeine bothered to include a {{put}} statistic
For all the Solr cache implementations currently shipping, the put operation is
pretty much identical, so stats are not likely to be very interesting when
comparing implementations. The situation is similar for lookups. I am not at
all worried about seeing time stats on either of those, unless it's easy and
really fast to obtain.
I think that hit ratio is the most important statistic for cache performance,
and it's already available. Eviction performance is important, though. The
count of evictions, also present currently, is useful. The speed of evictions,
in conjunction with the count, can help decide whether the cache is too slow.
If the implementation itself happens to track stats, that's awesome, but I'm
after more than a calculation of the average time. Percentile stats give a
clearer picture of what's happening than plain averages. I'd love to have the
same detail on speed data that we got for QTime with SOLR-1972.
> 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
