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.

[paulcFanDuel]

Again many thanks for the input @cyberw. I'll get an example drafted up in code and added.

Your right in your assessment this is more of a patch that will enhance rather than wholesale change/addition to the functionality.

I have found in the past that its really useful to be able to tune specific User like entities separately while in flight, it gives you complete control (and can be useful when using load profiles) and allows for more sophisticated load patterns.

As you mentioned its would require a lot more in depth work than this simple change :) but would be amazingly useful.

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 20 days.

[github-actions]

This PR was closed because it has been marked stale for 20 days with no activity.