[
https://issues.apache.org/jira/browse/SOLR-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517021#comment-15517021
]
Shawn Heisey commented on SOLR-8241:
------------------------------------
After some experience using Caffeine in my own code, I think it's absolutely
something we should have in Solr. My time is still limited, but I'd like to
begin pushing this through as a replacement for the existing LFUCache.
I had a thought. The decay capability currently present in LFUCache can be
replaced by the expiration feature in Caffeine. I did have some questions
about that:
I'm not sure what the default expiration time for cache entries should be, but
it should definitely be configurable. The idea that comes to mind first is 4
hours.
I'm also not sure what time unit to use for expiration. Milliseconds would
probably result in very large numbers. I can see arguments for seconds,
minutes, hours, and for some users, days. Caffeine supports multiple time
units, so the unit could be configurable, which puts millis back on the table.
I don't see support for a feature that I think would be really quite cool: A
"minimum size" for the cache, so when the number of entries in the cache drops
to that level, entries will no longer be removed because of expiration. For
Solr's purposes, this would mean that if the cache has seen some activity,
there will always be *something* available for autowarming, even if it's been a
week since Solr got a query. Perhaps this could be configured with
"expireAfter" methods when the cache is constructed?
> 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
