Extract a base class BaseBenchmark as IndexBenchmark and QueryBenchmark have certain overlapping common properties.
And this paves way for better sharing of the ControlledExecutor.
Currently only QueryBenchmark uses ControlledExecutor which controls both rpm (run per minute) and duration (run duration), while IndexBenchmark although has very similar parameters (rpm and durationSecs), it's not suing ControlledExecutor and is using its own implementation to control rpm of index operation and durationSecs does not work.
Some of the values are extracted from Setup and moved up to IndexBenchmark for this refactoring practice. I do not want to completely rip out Setup for now as there could be some valid use case that I did not consider.
However, I would propose instead of allowing different Setups within the IndexBenchmark, perhaps just flatten all the values from Setup to IndexBenchmark (ie only 1 setup per IndexBenchmark, so far in suites I have only seen single setup). If the user wants different setups, then just set it up as a new task-type instead? Anyway, don't want to make major refactoring for now.
Descriptions
Extract a base class BaseBenchmark as IndexBenchmark and QueryBenchmark have certain overlapping common properties.
And this paves way for better sharing of the
ControlledExecutor.Currently only
QueryBenchmarkusesControlledExecutorwhich controls bothrpm(run per minute) andduration(run duration), whileIndexBenchmarkalthough has very similar parameters (rpmanddurationSecs), it's not suingControlledExecutorand is using its own implementation to controlrpmof index operation anddurationSecsdoes not work.Also the list of
SetupunderIndexBenchmarkdoes not appear to work in all places (probably a WIP?), while there are places that seems to iterate over the setup to index accordingly, but the caller would only use the first in the list for collection name to indexSome of the values are extracted from
Setupand moved up toIndexBenchmarkfor this refactoring practice. I do not want to completely rip outSetupfor now as there could be some valid use case that I did not consider.However, I would propose instead of allowing different
Setups within theIndexBenchmark, perhaps just flatten all the values fromSetuptoIndexBenchmark(ie only 1 setup perIndexBenchmark, so far in suites I have only seen single setup). If the user wants different setups, then just set it up as a new task-type instead? Anyway, don't want to make major refactoring for now.