You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Andrzej Bialecki (Jira)" <ji...@apache.org> on 2019/10/02 17:55:00 UTC
[jira] [Commented] (SOLR-8241) Evaluate W-TinyLfu cache
[ https://issues.apache.org/jira/browse/SOLR-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16943041#comment-16943041 ]
Andrzej Bialecki commented on SOLR-8241:
----------------------------------------
Updated patch:
* reduced contention in stats counting by using LongAdder-s instead of AtomicLong-s.
* added option to set maxRamMB limit (it's an either or with the maxSize limit). I'm not sure I did the right thing when changing the value of this option - basically, if the existing cache was not weighted the {{setMaxRamMB}} rebuilds the cache, instead of just changing the policy limits.
* added unit test for testing the limit changes on a live cache.
If this patch looks more or less ok I'll add the RefGuide changes and commit it shortly (hopefully in time for 8.3 :) )
> Evaluate W-TinyLfu cache
> ------------------------
>
> Key: SOLR-8241
> URL: https://issues.apache.org/jira/browse/SOLR-8241
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: Ben Manes
> Assignee: Andrzej Bialecki
> Priority: Major
> Fix For: master (9.0)
>
> Attachments: EvictionBenchmark.png, GetPutBenchmark.png, SOLR-8241.patch, SOLR-8241.patch, SOLR-8241.patch, SOLR-8241.patch, SOLR-8241.patch, SOLR-8241.patch, caffeine-benchmark.txt, proposal.patch, solr_caffeine.patch.gz, solr_jmh_results.json
>
>
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org