pluggable dispatcher logic #2606
Conversation
…eating Environment
|
Idk, this still changes/adds a lot of code.... Could you just subclass UsersDispatcher and override its methods insteas of introducing an abstract base class? (and not rename the methods. tbh I'm not sure about the reasoning for making them all private (_ prefix) but I'd rather not change it) I understand it is not the cleanest OO-principles to do that, but low complexity in locust core is more important. |
|
sure, update with the only change in changed the PR to a draft, since I'd like to test them out in our project first, which uses the branch in my fork that this PR also is based on. |
|
nice! |
|
@mgor Is there any documentation available on how to use this code to allow sticky user types per worker? Thanks! |
This PR only allows custom dispatcher logic to be used, the actual logic that would allow for sticky user types is outside of locust. The implementation I'm using can be found here, |
|
Great, thanks for the response, cheers! |
superseeding #2568, coming from discussion in #2522.
this PR makes it possible to implement custom dispatcher logic and specifying the dispatcher class when creating an
Environment.a little unsure and not really satisfied with the name of the "interface"
UserDispatcherType.played around with
UserDispatcherBase(but it's discouragedto useBase).IUserDispatcherdoesn't feel pythonic. so any suggestion on a better name is welcomed :) my top choice would be to renameUserDispatchertoWeightedUserDispatcher(or similar) and have the interface changed toUserDispatcher, but at the same time I wanted to make as few changes as possible.some methods and properties in the interface was added to make it easier to [compability] test implementations.
so minor changes in the current dispatcher logic so it uses the interface specified methods and properties.