Refactoring of the dispatch logic to improve performance #1809
Conversation
This file contains hidden or 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
I'm committing this just to have trace of it even though I will completely delete the current dispatch code in an upcoming commit.
cyberw
reviewed
Jul 7, 2021
cyberw
reviewed
Jul 7, 2021
cyberw
reviewed
Jul 7, 2021
cyberw
reviewed
Jul 7, 2021
Ditching deepcopy has improved the perf a lot.
- Reduce size of users generator - Do not copy users_on_workers if not needed - Optimize _fast_users_on_workers_copy
cyberw
reviewed
Jul 12, 2021
cyberw
reviewed
Jul 12, 2021
cyberw
reviewed
Jul 12, 2021
cyberw
reviewed
Jul 12, 2021
cyberw
reviewed
Jul 12, 2021
cyberw
reviewed
Jul 12, 2021
| def remove_worker(self, worker_node_id: str) -> None: | ||
| self._worker_nodes = [w for w in self._worker_nodes if w.id != worker_node_id] | ||
| if len(self._worker_nodes) == 0: | ||
| # TODO: Test this |
Collaborator
There was a problem hiding this comment.
There is a test for this now, right? Remove the todo :)
Contributor
Author
There was a problem hiding this comment.
I don't think there's a test for the zero worker case yet. I'll add one.
cyberw
reviewed
Jul 12, 2021
cyberw
reviewed
Jul 12, 2021
cyberw
reviewed
Jul 12, 2021
cyberw
reviewed
Jul 12, 2021
| client.user_classes_count = {} | ||
| if self._users_dispatcher is not None: | ||
| self._users_dispatcher.remove_worker(client.id) | ||
| # TODO: If status is `STATE_RUNNING`, call self.start() |
Collaborator
There was a problem hiding this comment.
lets talk about this after merge
cyberw
reviewed
Jul 12, 2021
Collaborator
|
(deleted) Edit: never mind, both the issues I saw are in 1.6 as well :) |
Collaborator
|
Lets discuss my proposed changes after merging. |
mboutet
added a commit
to mboutet/locust
that referenced
this pull request
Jul 28, 2021
cyberw
added a commit
that referenced
this pull request
Jul 28, 2021
Improve logging messages and clean up code after dispatch refactoring (#1809)
This was referenced Sep 14, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
NOTE: Still a work in progress, tests are not yet all updated so they fail.
This PR addresses the performance issues introduced by this other PR when one or more of the following is true:
I completely refactored the
UsersDispatcher. In fact, it is almost completely different from before and a lot simpler. I also ditched thedistribution.pylogic as I'm now using this great little library which allows for a nginx-like weighted round-robin dispatch of the users. Ramp-down is also now supported (i.e. stopping users at a given rate).I've implemented most of the tests to validate this new implementation in
test_dispatch.py, but I've not yet updated therunnersmodule.I'm still missing the logic to ensure that all workers run the expected users prior to beginning a ramp-up/down. I'll implement it in the next few days.
I implemented a small benchmark with the following config:
Each dispatch iteration takes around 130ms to compute which is very good. It's orders of magnitude faster than before. The performance is similar for the inverse scenario from 100 000 to 0 users.