Remove specific users

[paulcFanDuel]

What
The modification in this PR is to enhance the existing (very useful) functionality of being able to increase the amount locust users for a specific User Class.

Changes in this pr allows us to decrease the running locust users for individual user classes (rather than all user classes) deterministically.

The functionality remains the same for normal spawn/despawn events where user classes are not specified.

Currently in locust we can

1. Given start conditions of a locust run where we have 3 users of class types [UserA, UserB, UserC] and are running weight 1,1,1,
2. We can individually increase UserA for example if we send a dispatch through with:

new_dispatch(
        self, target_user_count=4, spawn_rate=1, user_classes[UserA]
    )

4. This will give us the following running users: {"UserA": 2, "UserB": 1, "UserC": 1},
5. We do not have the ability to remove 1 running user of a specified class currently.

With the changes in this pr we can now do the following:

1. With starting test conditions giving us the following running users: {"UserA": 1, "UserB": 1, "UserC": 1},
2. Remove an individual running user: new_dispatch( self, target_user_count=2, spawn_rate=1, user_classes[UserA] )
3. Result {"UserA": 0, "UserB": 1, "UserC": 1}

[cyberw]

Hi! Sorry for the long response time, last couple of weeks have been insanely busy.

I think this looks very cool! Can you show a more complete example of how it would be used? Calling new_dispatch "manually" is a bit of a way to use Locust...

[paulcFanDuel]

Ah no problems @cyberw thanks for looking at this.

I will get an example added (is this best placed here? Aware there is a lot here already and don't want to pollute the timeline too much, but then again some code would be nice to illustrate how this works).

Also just to expand/clarify on my original explanation, the intention for this and usage would be calling through the master runner start( method here, rather than directly calling dispatcher. Apologies if this was a bit unclear from the initial description :)

Usage would be:

1. Add 2 MyUserClass1 users: start(user_count=2, spawn_rate=1, user_classes=[MyUserClass1])
2. Remove 1 of the same user: start(user_count=1, spawn_rate=1, user_classes=[MyUserClass1])
3. Add 8 x MyUserClass2 (current functionality): start(user_count=10, spawn_rate=1, user_classes=[MyUserClass2])

Couple of things to note:

• The add users functionality is exactly the same / no change.
• When we use the user_classes param as above this resets the dispatcher self._user_classes to whatever is passed in (if it differs from the original state)

The latter is not new either but worthy of note as any future calls that percolate through to a new_dispatch without setting user_classes=[something] will act upon the the dispatchers self._user_classes.

The inverse of this is, if user_classes=[] has never been set in the start call when adding / removing users the dispatchers original state for self._user_classes never alters.

[cyberw]

Hey, sorry again for not replying promptly.

I do like this feature, but I wonder if it wouldn't make more sense to support an entirely different mode, where you always set specific User counts for the various classes instead of using weights? Probably a bit bigger change to implement, but if you're interested I'll be sure to dedicate some attention to this.

I will get an example added (is this best placed here? Aware there is a lot here already and don't want to pollute the timeline too much, but then again some code would be nice to illustrate how this works).

Yes, that's the right place for it.