Add "step-down" capabilities

[iramisvalentincapco]

Description of issue / feature request

Provide an optional configuration option to "step-down" the # of concurrent users based on some supplied rate, and after a defined amount of time after all locust users are hatched. Locust would continue to log the request data and statistics until there are 0 locust users by default.

Gherkin-style User Story (Perspective: Locust test-writer)

Feature: Step-down Capabilities
As a user, I want to specify an expiration rate and duration, so that I can verify that hatched locust users are properly expired.

Scenario: Expiration Rate defined
Given I start a standard locust execution
And I supply a valid expiration rate
And I supply a valid duration
When I start the Locust swarm
And the number of concurrent locust users reaches the defined maximum
And the swarm has maintained the maximum number of locust users for duration seconds
Then locust users expire as defined by the expiration rate
And Locust continues to log data until reaching 0

Scenario: Expiration Rate not defined
Given I start a standard locust execution
And I supply a valid duration
When I start the Locust swarm
And the number of concurrent locust users reaches the defined maximum
And the swarm has maintained the maximum number of locust users for duration seconds
Then locust users expire as defined by the hatch rate
And Locust continues to log data until reaching 0

Scenario: Duration not defined
Given I start a standard locust execution
And I supply a valid expiration rate
When I start the Locust swarm
And the number of concurrent locust users reaches the defined maximum
And I click the Stop button
Then locust users expire as defined by the expiration rate
And Locust continues to log data until reaching 0

[micsjo]

Why not then apply n number of ramp ups/downs? Allows different increasing/decreasing load across time. Not just up/down.

[iramisvalentincapco]

@micsjo That would be a separate feature which would build upon the functionality that this feature would offer.

[iramisvalentincapco]

I am unsure of what the expected behavior should be if both the expiration rate and duration at max users are not defined. Should the ramp-down still occur, upon triggering on_stop (thereby changing the current default behavior) or should no ramp-down occur at all?

Edit: For now, I will proceed without modifying the current default behavior.

[stevecj]

I am also interested in a feature like this. Currently, when to run is complete, all clients are shut down at the same time, and this produces an unrealistic load on the logout request, so the stats for my logout request duration are not useful.

I was thinking of adding a random sleep before logout, but that does not take into account how many clients are running, and I'm not sure how to get that number so I can use it to control the range of values for that. Maybe there is a way to get that number or better yet (client of ) that I don't know about?

[heyman]

I don't really see a big use-case for this. If a system can handle a sustained load of X number of users, it should be able to handle less than X number of users as well.

and this produces an unrealistic load on the logout request, so the stats for my logout request duration are not useful.

It's not realistic to have all users log in at once, and then all of them logging out at the same time while no other clients log in/continues to use the system. Instead I'd make so that there is a small chance for the users to log out every now and then so that you'd get login/logout load all the time during the test.

[max-rocket-internet]

If a system can handle a sustained load of X number of users, it should be able to handle less than X number of users as well

In a simplistic system, for sure. But consider a system that is connected asynchronously to another. A queue is a classic example. We are often load testing systems like this. It could be conceivable that the rate of decline at the end of a load test is important as items in queues need to be processed after the peak. For example using AWS SQS>AWS Lambda or a simple queue listener. That said, I don't need this feature 😃

[heyman]

It could be conceivable that the rate of decline at the end of a load test is important as items in queues need to be processed after the peak.

That's true. If and when we implement support for steps in the ramping up of locust users (or more general scenarios), we should also make sure that it also supports stepping down. There is an open issues for this at #1001.