-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Refactor ramping VUs executor #2124
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2124 +/- ##
=========================================
Coverage ? 72.69%
=========================================
Files ? 182
Lines ? 14581
Branches ? 0
=========================================
Hits ? 10599
Misses ? 3338
Partials ? 644
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
Thanks, I just skimmed this and it seems like a solid improvement! That said, all of the new methods end up having a ton of parameters and results, which is not ideal for comprehension. What we ended up doing in another executor (the k6/lib/executor/externally_controlled.go Lines 373 to 387 in 3994f1a
|
Thanks! Also, thanks for pointing out the I have added a struct called |
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.
Nice job breaking down Run()
👏 handleVUs()
is clean and the *HandlerStrategy
functions are a nice touch and encapsulate the behavior nicely.
Just a minor meta nitpick: I would use a more descriptive commit message and PR description explaining what was done and why instead of just "refactor" :) E.g. "Split up RampingVUs.Run method ..." and maybe a small summary of the changes.
@inancgumus can you also provide some benchmark results from before and after the refactor |
|
@inancgumus seems okay, but in general run with Also please rebase on master as you now have conflicts after the metrics registry merge ... sorry about that :( |
Here are the benchmarks with
|
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.
LGTM in general. I have some naming ... considerations and some code golfing (that isn't really necessary and might be worse for readability).
The biggest "request change" is actually adding a test for gracefulShutdown and rampingVUs given the comment that removing the support for it doesn't break tests :)
RampingVUs.Run method was complex and this refactors it by adding rampingVUsRunState to share run state between functions used by the Run method. + Makes the Run method easier to read and understand + Makes it explicit which Goroutines are being fired in the Run + Separates responsibilities to other parts like: + rampingVUsRunState and its methods. + Moves trackProgress Goroutine from the makeProgressFn to the Run method + Makes initializeVUs to only handle initializing GRs + Uses two strategy functions to make them reusable and clearer. handleVUs and handleRemainingVUs use them. + Makes the handleVUs algorithm easier to understand and manage. `go get` was failing on Go tip.
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.
LGTM, just a minor suggestion.
I don't have a strong opinion on handleVUs()
. The previous version looked OK, though the current one is more succinct, so 👍.
Co-authored-by: Ivan Mirić <[email protected]>
Refactored Ramping VUs executor—a little bit. This is the first step as I'm learning about the system. I hope this refactoring makes sense.