Skip to content

Introduce Randomness To Sleeps #15

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
AntsInMyEy3sJohnson opened this issue Nov 5, 2022 · 0 comments · Fixed by #18
Closed

Introduce Randomness To Sleeps #15

AntsInMyEy3sJohnson opened this issue Nov 5, 2022 · 0 comments · Fixed by #18
Assignees
Labels
enhancement New feature or request

Comments

@AntsInMyEy3sJohnson
Copy link
Owner

AntsInMyEy3sJohnson commented Nov 5, 2022

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant