[
https://issues.apache.org/jira/browse/LUCENE-10043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17393252#comment-17393252
]
Adrien Grand commented on LUCENE-10043:
---------------------------------------
+1 I think we were conservative when we introduced this limit because we didn't
want to change too much the behavior of the query cache, which would previously
cache clauses that get reused even if that might hurt tail latencies.
Most of the use-cases I'm familiar with care more about tail latencies than
they care about global throughput, so I think it would make sense to have a
much lower default. The value of 10 that you are proposing sounds good to me.
> Decrease default for LRUQueryCache#skipCacheFactor?
> ---------------------------------------------------
>
> Key: LUCENE-10043
> URL: https://issues.apache.org/jira/browse/LUCENE-10043
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Julie Tibshirani
> Priority: Minor
>
> In LUCENE-9002 we introduced logic to skip caching a clause if it would be
> too expensive compared to the usual query cost. Specifically, we avoid
> caching a clause if its cost is estimated to be a factor higher than the lead
> iterator's:
> {code}
> // skip cache operation which would slow query down too much
> if (cost / skipCacheFactor > leadCost) {
> return supplier.get(leadCost);
> }
> {code}
> Choosing good defaults is hard! We've seen some examples in Elasticsearch
> where caching a query clause causes a major slowdown, contributing to poor
> tail latencies. It made me think that the default 'skipCacheFactor' of 250
> may be too high -- interpreted simply, this means we'll cache a clause even
> if it is ~250 times more expensive than running the top-level query on its
> own. Would it make sense to decrease this to 10 or so? It seems okay to air
> on the side of less caching for individual clauses, especially since any
> parent 'BooleanQuery' is already eligible for caching?
> As a note, the interpretation "~250 times more expensive than running the
> top-level query on its own" isn't perfectly accurate. The true cost doesn't
> dependent on the number of matched documents, but also the cost of matching
> itself. Making it even more complex, some queries like
> 'IndexOrDocValuesQuery' have different matching strategies based on whether
> they're used as a lead iterator or verifier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
