Add track parameters to control target throughput and clients for search operations #1
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.
Background
This change adds target_throughput and search_clients as track parameters for all search operations where a default target throughput is specified. If no user-specified value for these new parameters exists, then the existing defaults will be used. Otherwise, the user-specified value will be honored. There is a special case for target-throughput where 'none' as a string can be specified to remove the target-throughput setting.
This change will allow our runs to be more configurable and is a step in the direction of automated saturation testing.
Additionally, it will allow us to remove target throughput on our daily benchmarks to get more significant query performance numbers.
Testing
I spun up the beta AMI and switched the tracks remote to my repo and pulled all branches. The I tested the following:
The only failures were in eventdata (which this PR doesn't touch) when running the transform challenge, and the expected failures of 'challenge does not exist' or 'track does not exist' for lower distribution versions.
search_clients:2,target_throughput:'none'
as track-paramsI did not run eventdata for step 2 as it's unchanged by this PR. There were no new failures except for SO, which threw an error saying the params were unsupported, which is the expected behavior.