[
https://issues.apache.org/jira/browse/LUCENE-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985291#comment-16985291
]
Adrien Grand commented on LUCENE-9066:
--------------------------------------
The high level idea makes sense to me: increasing the number of slices usually
improves latency, but also hurts throughput. So when the queue fills up and you
have to wait for other queries to complete before starting anyway, it probably
makes sense to decrease the number of slices as an attempt to get the number of
tasks in the queue low again to get latency benefits back?
I wonder that getting system statistics might not be necessary: if the system
gets slow then the queue will fill up naturally anyway?
> Modal Strategy In Concurrent Query Execution
> --------------------------------------------
>
> Key: LUCENE-9066
> URL: https://issues.apache.org/jira/browse/LUCENE-9066
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Atri Sharma
> Priority: Major
>
> When executing a query concurrently today, we do not take any sort of system
> statistics into account. For e.g. if the node is under high pressure, it is
> not advisable to spawn a large number of threads for a query since they are
> most likely to be blocked waiting for CPU to be available. However, the
> converse is that for a lightly loaded cluster, the query can consume as many
> threads as required.
>
> This Jira tracks high level efforts in this direction. The first idea is to
> account the Executor's wait queue's size as a factor when allocating slices
> to a query's segments.
--
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
