"Failed to reach target rps, even after rampup has finished" with limited load about locust-plugins

[DavideRossi]

Yup, that's it!
The main reason being that this way I can tinker with the web interface parameters to change the load

[cyberw]

Try using more clients. If ramp up finishes really fast then you probably wont reach the target throughput, so rps_sleep will warn you about it.

It is just a warning though... rps_sleep will just sleep for zero ms if you are not reaching the target rps.

[DavideRossi]

This may indeed be the case, with 10 clients I don't get the warning anymore.
My problem is, though, that with 10 clients, an average response time of 14ms, I only get a request rate of 1.3. What am I missing? Is the rps in rps_sleep a per-client RPS or an overall one?

[cyberw]

It is overall. Do you have any other sleeps (or maybe a wait_time) configuted somewhere?

[DavideRossi]

Oh, overall... this is kind of tricky. I mostly run my tests from the web interface so the only thing I can change is the number of clients. To really change the load I have to change the locustfile (or the parameters it uses) which is not straightforward when they are run in a set of distributed containers. In this context it would be more useful to have a per-client rate.

[cyberw]

There’s a per client rate wait_time built into locust nowadays. It is called constant_pacing

[DavideRossi]

Yes, I saw that. My understanding is that this operates on a per-client basis whereas TaskSetRPS operates on a global basis.
If I understand this right, it means that if I set a constant_pacing of 1 second but the response time is 1.5 seconds (because of a spike) the overall rate decreases where as TaskSetRPS compensates for that with other clients in order to keep the overall rate constant (as long as the average response time is less than 1 second, obviously). Is this right?

[cyberw]

Yes, that is correct.

[DavideRossi]

Well, then a per-client rate would be more than appreciated. Let's label this a feature request?

[cyberw]

Huh? constant_pacing is already per-client - do you need something more?

Or do you mean per-client rate insted of per-client pacing? That is just the inverse, e.g. to get 2 req/s, use constant_pacing(1/2)

Although I do actually have a PR that adds that (along with rps_sleep) to locust core (locustio/locust#1241). Feel free to upvote it :)

[DavideRossi]

Actually I meant a per-client rate for TaskSetRPS!

[cyberw]

Ok, is there some reason you prefer to have it in TaskSetRPS instead of the built in? :)

[DavideRossi]

Well, for the reason above: TaskSetRPS can compensate between clients to keep a steady overall request rate.

[cyberw]

Aha, you want to set a per-client target but allow for compensation between clients?

[cyberw]

I personally dont use the web interface, but I do understand why you want it. If you want to build it then I'd be happy to merge it (to locust-plugins at least, my PR for locust itself might not get merged unless I manage to convince @heyman...)