locust rps调试存档

1、constant_throughput user

class WebUser(FastHttpUser):
    # 声明执行的任务集是哪个类
    tasks = [BeTest]
    # 被压服务的域名
    # host = 'http://192.168.22.167:9080'
    host = 'http://192.168.0.22:8080'
    # 最小等待时间和最大等待时间   请求间的间隔时间 单位ms
    # min_wait = 1000
    # max_wait = 5000
    wait_time = constant_throughput(10)
如图，我们使用constant_throughput（）是可以在一定程度上控制RPS速率的，小伙伴可以回去测试一下，其中使用方法就是，如何我们设置的user为100，那我们的constant_throughput设置为1，则实际的rps会被控制在100，如果我们设置为10，则rps会被控制在1000，所以这个很好用；

2、FastHttpUser

官方给出的区别是FastHttpUser的测试将能够在每个核心每秒执行接近 5000 个请求，而HttpUser则是大约 850 个（在 2018 MacBook Pro i7 上测试） 2.6GHz），在负载生成器CPU没有过载的情况下，FastHttpUser和HttpUser基本相同，更推荐使用HttpUser。

3、分布式

分布式执行
运行 Locust 的单个进程可以模拟相当高的吞吐量。对于一个简单的测试计划，它应该能够每秒发出数百个请求，如果使用FastHttpUser则数千个。但是如果你的测试计划很复杂或者你想运行更多的负载，你就需要扩展到多个进程，甚至可能是多台机器。

我们可以使用–master标志Master启动一个Locust实例，并使用–worker标志Worker启动多个工作实例。

如果worker进程与master进程在同一台机器上，建议worker的数量不要超过机器的CPU核数。一旦超过，发压效果可能不增反减。
如果worker进程与master进程不在同一台机器上，可以使用–master-host将它们指向运行master进程的机器的IP/主机名。
在Locust在执行分布式时，master和worker机器实例上一定要有locusfile的副本。
master实例运行Locust的Web界面，并告诉workers何时产生/停止用户。worker运行用户并将统计数据发送回master实例。master实例本身不运行任何用户。

注意点
因为Python不能完全利用每个进程一个以上的内核(参见GIL)，所以通常应该在Worker机器上为每个处理器内核运行一个Worker实例，以便利用它们的所有计算能力。
对于每个Worker实例可以运行的用户数量几乎没有限制。只要用户的总请求率/RPS不太高，Locust/gevent就可以在每个进程中运行数千甚至数万个用户。
如果Locust即将耗尽CPU资源，它将记录一个警告。

4、
Increase the number of users. In order to fully utilize your target system you may need a lot of simultaneous users.
If response times are unexpectedly high and/or increasing as the number of users go up, then you have probably saturated the system you are testing and need to dig into why. This is not really a Locust problem, but here are some things you may want to check:
resource utilization (e.g. CPU, memory)
configuration (e.g. max threads for your web server)
back end response times (e.g. DB)
If Locust is complaining about high CPU usage on its side
Run Locust distributed to utilize multiple cores & multiple machines
Try switching to FastHttpUser to reduce CPU usage

5、wait_time

You can using the min_wait & max_wait values. Set it to 0 and see if throughput increases.
min_wait = 0
max_wait = 0
wait_time = between(min_wait, max_wait)

6、
There was is an old article from k6 that showed locust being very slow but they configured it with min_wait = 5000 max_wait = 15000, I assume because this was used in an example in the locust docs. They have an updated article now which is very comprehensive: https://k6.io/blog/comparing-best-open-source-load-testing-tools

For comparison, we have run tests up to 30000 RPS (not using FastHttpLocust):

locust master = 2 cores, 1GB or memory
locust slaves = 50 slaves at 1 core and 2GB each
Python/locust will likely never match the raw speed of other tools like k6 or the basic tools like wrk/ab etc but ease of the Python language and MUCH easier horizontal scaling on k8s with the master/slave model more than makes up for it IMO.