"Sticky" user types on workers about locust

[mgor]

Yeah, bad choice of word, "sacred", but I remembered about reading in some thread (or if it was in code?) that changes to it wasn't advised :)

Well, I have a couple of days now when the rest of the team has vacation that I could spend looking into it.

You are referring to "the old one", has there been a different dispatcher implementation?
I could look through the git history if that is the case.

I'll start working on a DeterministicUsersDispatcher then, instead of patching the current algorithm. Basically, not using weights, only fixed numbers and also being able to "tag" user types to a set of workers.

[cyberw]

The old one was completely different (locust 1.x), done on the workers not on the master (which had other limitations, because each worker had exactly the same distribution), so it is not much to look at :)

Cool! The current implementation is still pretty deterministic (so you should probably name the new one something else), it is just that it has time ticks as opposed to the old one, which had no time ticks (if I remember correctly). Probably dont want to change that in your PR, as that would be a major change :)

Perhaps it could be named CountBasedUserDispatcher? (as opposed to the current one which is "weight based")

To be able to use it fully there would need to be some ui/command line changes too (because you would specify counts for each user type instead of just a total user count), but if you build the dispatcher implementation I can help out with the other stuff.

[mgor]

I have something working, but I want to run some extensive testing in our project before creating a PR here for it.

[cyberw]

The dispatcher code is not "sacred", but it was contributed by @mboutet and I dont know if he's still around? (so I'm hesitant to change it)

While the dispatcher implementation does seem to hold up for most use cases it is "less deterministic" than the old one and doesnt scale as well with high user, worker and user type counts.

What would be kind of cool is offering a completely separate algorithm: Not based on specifying weights and a total user count but on per-User type-numbers (like most other load test tools do it). This might involve a little more work than what you had imagined, but that would make me like the proposed change more :)