fix: rampTo behaviour when arrivalRate is less than amount of workers #1621
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
juanig1
force-pushed
the
hotfix/rampup_distribution
branch
from
ff53108
to
4c452bc
Compare
juanig1
force-pushed
the
hotfix/rampup_distribution
branch
3 times, most recently
from
b70aacc
to
c4d6af3
Compare
Setting an arrival rate lower than the workers being user to run the test, resulted in rampTo property being distributed across all workers instead of the ones that had an actual arrivalRate. As the default value for arrivalRate if not present was 1, it generated a weird rampTo curve. Changed the default to zero, in order to use all threads and keep the expected ramp curve.
juanig1
force-pushed
the
hotfix/rampup_distribution
branch
from
c4d6af3
to
6d22324
Compare
juanig1
changed the title
juanig1
commented
Oct 19, 2022
hassy
reviewed
Oct 20, 2022
hassy
approved these changes
Oct 20, 2022
Co-authored-by: Hassy Veldstra <h@veldstra.org>
Co-authored-by: Hassy Veldstra <h@veldstra.org>
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.
See #1589.
Setting an arrival rate lower than the workers being user to run the test, resulted in
rampToproperty being distributed across all workers alongside an incorrect value forarrivalRateThis generated an unexpected distribution of requests:
The root cause for this is that having a
rampToand noarrivalRate, defaulted toarrivalRatebeing 1.Example:
using
arrivalRate:1; rampTo:25and running with 7 workers resulted in:arrival rate distribution for each worker:
rampTo distribution for each worker:
When this got to the execution logic, arrival rate was being updated to 1 here causing the initial load to be higher than expected, so effective arrival rates were actually:
After the update we remove 1 as default
arrivalRate, avoiding the initial spike and still getting the most out of available threads.Still worth mentioning that for smaller numbers setting
WORKERS=1may be desired to have a more controlled behavior.