[
https://issues.apache.org/jira/browse/SOLR-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16936270#comment-16936270
]
Ben Manes commented on SOLR-8241:
---------------------------------
I copied {{ConcurrentLRUCache}} and {{ConcurrentLFUCache}} classes for use by
JMH w/o the dependencies, which caused issues with the zip archive. This
multithreaded workload is a 100% hit of gets and puts, using a Zipf
distribution, on a 4-core (8 HT) laptop. The caches were set to use the async
eviction thread.
The performance of the caches is hurt significantly due to using {{AtomicLong}}
for the statistics. This throttles the throughput because it creates a lot of
contention on this field. Ideally if you use {{LongAdder}} then this impact
will decrease, e.g. to 10% overhead. However, this cannot be done because both
caches depend on the result of the increment which is not available in the
striped counter.
{code:java}
// Lru
if (islive) {
e.lastAccessed = stats.accessCounter.incrementAndGet();
}
// Lfu
if (islive) {
e.lastAccessed = stats.accessCounter.incrementAndGet();
e.hits.incrementAndGet();
}
{code}
This benchmark stresses critical sections, so a single contention point may
reduce throughput more than if spread across multiple points. This is probably
why the LFU cache is faster than the LRU one, because it has more counters to
content on.
||Benchmark||Cache Type||Score||
|GetPutBenchmark.read_only|Solr_Lfu||42,338,073 ops/s||
|GetPutBenchmark.read_only|Solr_Lru||23,938,078 ops/s||
|GetPutBenchmark.readwrite|Solr_Lfu||19,422,639 ops/s||
|GetPutBenchmark.readwrite|Solr_Lru||24,814,577 ops/s||
|GetPutBenchmark.write_only|Solr_Lfu||7,068,798 ops/s||
|GetPutBenchmark.write_only|Solr_Lru||8,387,552 ops/s||
I did not run with Caffeine, but my published [desktop
benchmarks|https://github.com/ben-manes/caffeine/wiki/Benchmarks#desktop-class]
were run on this laptop. That showed significantly higher throughput (e.g. 150M
reads/s).
I am *still* waiting for the S3 trace to complete...
> 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: SOLR-8241.patch, SOLR-8241.patch, SOLR-8241.patch,
> SOLR-8241.patch, SOLR-8241.patch, caffeine-benchmark.txt, proposal.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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
