-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fix ramping arrival rate unplanned vus #1500
Conversation
Codecov Report
@@ Coverage Diff @@
## new-schedulers #1500 +/- ##
==================================================
+ Coverage 77.27% 77.29% +0.02%
==================================================
Files 162 162
Lines 13058 13095 +37
==================================================
+ Hits 10090 10122 +32
- Misses 2452 2455 +3
- Partials 516 518 +2
Continue to review full report at Codecov.
|
lib/executor/common_test.go
Outdated
@@ -79,6 +79,6 @@ func initializeVUs( | |||
for i := uint64(0); i < number; i++ { | |||
vu, err := es.InitializeNewVU(ctx, logEntry) | |||
require.NoError(t, err) | |||
es.AddInitializedVU(vu) | |||
es.ReturnVU(vu, false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because AddInitializedVU adds 1 to the number of initializedVus .. this also seemed like the only place it is used, so maybe we can remove it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It turns out that this broke the externally-controlled
tests, so I reverted it. Also, it's used here: https://github.com/loadimpact/k6/blob/447f892cc2c4073290e25b220307851d14aaae95/core/local/local.go#L203
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense, though it took me a while to follow the test 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The general initialization approach seems good, but I think the logic of how it's used is still wrong, as I've described in my inline comment
This make it so that if an unplannedVU needs to be started we wait for ANY free VU instead of only for that unplannedVU to start the next iteration. Also puts in place some guards against initing multiple unplannedVUs
0719cfd
to
223ed80
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 but I can't approve it as I am the author 🙄
a8076d6
to
9780e43
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, sorry, I think there's at least one blocker here (the initVU
comment). But let me know if I'm wrong 😄
No description provided.