Title: Locust.io: Controlling the request per second parameter
Tags: amazon-web-services;load-testing;stress-testing;locust
Question: I have been trying to load test my API server using Locust.io on EC2 compute optimized instances. It provides an easy-to-configure option for setting the consecutive request wait time and number of concurrent users. In theory, rps = wait time X #_users. However while testing, this rule breaks down for very low thresholds of #_users (in my experiment, around 1200 users). The variables hatch_rate, #_of_slaves, including in a distributed test setting had little to no effect on the rps.
```
Experiment info
The test has been done on a C3.4x AWS EC2 compute node (AMI image) with 16 vCPUs, with General SSD and 30GB RAM. During the test, CPU utilization peaked at 60% max (depends on the hatch rate - which controls the concurrent processes spawned), on an average staying under 30%.
Locust.io
setup: uses pyzmq, and setup with each vCPU core as a slave. Single POST request setup with request body ~ 20 bytes, and response body ~ 25 bytes. Request failure rate: < 1%, with mean response time being 6ms.
variables: Time between consecutive requests set to 450ms (min:100ms and max: 1000ms), hatch rate at a comfy 30 per sec, and RPS measured by varying #_users.
```

The RPS follows the equation as predicted for upto 1000 users. Increasing #_users after that has diminishing returns with a cap reached at roughly 1200 users. #_users here isn't the independent variable, changing the wait time affects the RPS as well. However, changing the experiment setup to 32 cores instance (c3.8x instance) or 56 cores (in a distributed setup) doesn't affect the mahoneygeorge@example.net.
So really, what is the way to control the RPS? Is there something obvious I am missing here?



Here is another answer: (one of the Locust authors here)

First, why do you want to control the RPS? One of the core ideas behind Locust is to describe user behavior and let that generate load (requests in your case). The question Locust is designed to answer is: How many concurrent users can my application support?

I know it is tempting to go after a certain RPS number and sometimes I "cheat" as well by striving for an arbitrary RPS number.

But to answer your question, are you sure your Locusts doesn't end up in a dead lock? As in, they complete a certain number of requests and then become idle because they have no other task to perform? Hard to tell what's happening without seeing the test code.

Distributed mode is recommended for larger production setups and most real-world load tests I've run have been on multiple but smaller instances. But it shouldn't matter if you are not maxing out the CPU. Are you sure you are not saturating a single CPU core? Not sure what OS you are running but if Linux, what is your load value?

Comment for this answer: One of the reason i strive for RPS is due of the fact that I know the users (for eg. 2) but for locust, 2 users are generating a request of 110+ RPS, but in real world, those 2 users can only make 1-2 requests per seconds? How is that helpful in determining user based loads?

Here is another answer: While there is no direct way of controlling rps, you can try ```constant_pacing``` and ```constant_throughput``` option in ```wait_time```
From docs
https://docs.locust.io/en/stable/api.html#locust.wait_time.constant_throughput
```
In the following example the task will always be executed once every 1 seconds, no matter the task execution time:
```
```class MyUser(User):
    wait_time = constant_throughput(1)
```
```constant_pacing``` is inverse of this.
So if you run with 100 concurrent users, test will run at 100rps (assuming each request takes less than 1 second in first place


{'source': 'StackExchangeDataset', 'subset': 'stackoverflow.com', 'metadata': {'AnswerCount': 2, 'CommentCount': 0, 'ContentLicense': 'CC BY-SA 3.0', 'CreationDate': '2014:00:12/30/14', 'FavoriteCount': 6.0, 'PostTypeId': 1, 'Tags': '<amazon-web-services><load-testing><stress-testing><locust>', 'Title': 'Locust.io: Controlling the request per second parameter', 'ViewCount': 12509, 'id': 27713104, 'user_AboutMe': '<p>Founder and CEO, appbase.io. My stack includes Golang, Elasticsearch, search engines.</p>\n', 'user_AccountId': 1263962.0, 'user_DisplayName': 'siddharthlatest', 'user_Reputation': 2211.0, 'user_Views': 199.0, 'user_id': 1221677.0}}