[
https://issues.apache.org/jira/browse/SOLR-13898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16972678#comment-16972678
]
Andrzej Bialecki commented on SOLR-13898:
-----------------------------------------
Updated patch:
* a few bugfixes
* use prescreen {{get(key)}} first in legacy cache implementations.
I also added {{TestSolrCachePerf}} test that tries to expose the difference in
hit ratio between get / put and computeIfAbsent in a highly concurrent use.
Basically the test attempts to create many racing put / get (or
computeIfAbsent) accesses to show that the hit ratio is lower when using get /
put than when using computeIfAbsent. The test passes, ie. it shows that
computeIfAbsent results in a higher hit ratio, but I'm not 100% sure it's the
best way to prove this ;)
In particular, the timings are a bit unexpected (I didn't assert anything yet
about the timings in the test, because the results were puzzling). The test
measures total elapsed time for the whole scenario run, for each cache
implementation, and calculates an average across 100 runs. For {{LFUCache}} and
{{LRUCache}} it actually takes longer when {{computeIfAbsent}} is used. I
suspect it has something to do with excessive synchronization in each impl. but
I'm worried that maybe something is wrong with the testing method (or with the
computeIfAbsent implementation in these caches).
> Non-atomic use of SolrCache get / put
> -------------------------------------
>
> Key: SOLR-13898
> URL: https://issues.apache.org/jira/browse/SOLR-13898
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 8.3
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13898.patch, SOLR-13898.patch
>
>
> As pointed out by [~ben.manes] in SOLR-13817 Solr code base in many key
> places uses a similar pattern of non-atomic get / put calls to SolrCache-s.
> In multi-threaded environment this leads to cache misses and additional
> unnecessary computations when competing threads both discover a missing
> value, non-atomically compute it and update the cache.
> Some of these places are known performance bottlenecks where efficient
> caching is especially important, such as {{SolrIndexSearcher}},
> {{SolrDocumentFetcher}}, {{UninvertedField}} and join queries .
> I propose to add {{SolrCache.computeIfAbsent(key, mappingFunction)}} that
> will atomically retrieve existing values or compute and update the cache.
> This will require also changing how the {{SolrCache.get(...)}} is used in
> many components.
--
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
