Context
- Each runner offers configuration that allows users to define sleeps
- For map and queue runners alike, there are two kinds of sleeps: sleep between runs, and sleep between action batches
Problem
Sleeps are static, resulting in...
- ... cyclic drops in CPU usage on the Hazelcast cluster under test,
- ... the necessity to configure odd numbers in order to mitigate the above point at least somewhat, and
- ... unrealistic load -- real business applications accessing Hazelcast are often themselves subject to requests from someone or something, resulting in load on them and thus on the Hazelcast cluster they use that might exhibit rough patterns (e.g. more load during days, less during nights), but the requests generating that load still happen randomly (as in: users don't time their requests)
Solution
- Offer possibility for sleeps to include randomness
- Could be achieved by providing a
enableRandomness: true/false kind of property on the sleepConfig struct for both map runners and queue runners, which would simply cause the sleep logic to pick a number between 0 and the number of milliseconds provided by means of the durationMs property already available today
- This would not make the sleeps completely random, but random enough to address the problems outlined above
- In the way described above, the user would still be able to decide whether to have static or random sleeps
Context
Problem
Sleeps are static, resulting in...
Solution
enableRandomness: true/falsekind of property on thesleepConfigstruct for both map runners and queue runners, which would simply cause the sleep logic to pick a number between 0 and the number of milliseconds provided by means of thedurationMsproperty already available today