[
https://issues.apache.org/jira/browse/LUCENE-7235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15251899#comment-15251899
]
ASF subversion and git services commented on LUCENE-7235:
---------------------------------------------------------
Commit 81446cf34531d46f224beaf6c2bc70bdf53ee585 in lucene-solr's branch
refs/heads/master from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=81446cf ]
LUCENE-7235: Avoid taking the lock in LRUQueryCache when not necessary.
> Avoid taking the lock in LRUQueryCache when not necessary
> ---------------------------------------------------------
>
> Key: LUCENE-7235
> URL: https://issues.apache.org/jira/browse/LUCENE-7235
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-7235.patch
>
>
> LRUQueryCache's CachingWeightWrapper works this way:
> - first it looks up the cache to see if there is an entry for the query in
> the current leaf
> - if yes, it returns it
> - otherwise it checks whether the query should be cached on this leaf
> - if yes, it builds a cache entry and returns it
> - otherwise it returns a scorer built from the wrapped weight
> The potential issue is that this first step always takes the lock, and I have
> seen a couple cases where indices were small and/or queries were very cheap
> and this showed up as a bottleneck. On the other hand, we have checks in step
> 3 that tell the cache to not cache on a particular segment regardless of the
> query. So I would like to move that part before 1 so that we do not even take
> the lock in that case.
> For instance right now we require that segments have at least 10k documents
> and 3% of all docs in the index to be cached. I just looked at a random index
> that contains 1.7m documents, and only 4 segments out of 29 met this
> criterion (yet they contain 1.1m documents: 65% of the total index size). So
> in the case of that index, we would take the lock 7x less often.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
