Expose max_concurrent_shard_requests in _msearch
#33016
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Today `_msearch` doesn't allow modifying the `max_concurrent_shard_requests` per sub search request. This change adds support for setting this parameter on all sub-search requests in an `_msearch`. Relates to elastic#31877
s1monw
added
>enhancement
:Search/Search
|
Pinging @elastic/es-search-aggs |
jpountz
approved these changes
Aug 21, 2018
| data nodes in the cluster but at most `256`. In certain scenarios parallelism isn't achieved | ||
| through concurrent request such that this protection will result in poor performance. For | ||
| instance in an environment where a cluster is formed by a single node holding a large amount of | ||
| shards queried at the same time. In such a scenario it makes sense to increase the number to a high value. |
There was a problem hiding this comment.
maybe be explicit and mention that there are never two requests running at the same time too
There was a problem hiding this comment.
Not sure I follow, you mean being explicit that this makes sense only in a single request environment? I think the kibana usecase in general makes sense where concurrently executing request are low but potentially higher than one?
There was a problem hiding this comment.
Yes this is what I meant. I'm fine with relaxing it to say low numbers of concurrent requests if that works better for you?
s1monw
added a commit
that referenced
this pull request
Aug 22, 2018
javanna
reviewed
Aug 22, 2018
| @@ -86,6 +86,16 @@ The msearch's `max_concurrent_searches` request parameter can be used to control | |||
| the maximum number of concurrent searches the multi search api will execute. | |||
| This default is based on the number of data nodes and the default search thread pool size. | |||
|
|
|||
| The request parameter `max_concurrent_shard_requests` can be used to control the | |||
| maximum number of concurrent shard requests the each sub search request will execute. | |||
There was a problem hiding this comment.
s/the/that ? sorry for being late to the party :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Today
_msearchdoesn't allow modifying themax_concurrent_shard_requestsper sub search request. This change adds support for setting this parameter on
all sub-search requests in an
_msearch.Relates to #31877