在采用locust进行性能测试过程中，我们只设置了两个参数
1、Number of users to simulate：代表并发用户数
2、Hatch rate (users spawned/second)：启动虚拟用户的速率，就是上面的并发用户数每秒启动多少个，只是刚开始启动的时候会生效
但是怎么保证QPS呢？
例如用户数我们设置了80，我们怎么保证每秒的并发也是80呢？80个用户可能有的用户1秒请求很多次，有的用户1秒请求比较少，但是我们需要保证每秒请求数也是80
我们在每次请求前记录一个start_time，在请求结束后记录一个时间，计算两者时间差
如果时间差小于1s，需要等待不足1s的剩余时间，如果时间差大于1s，继续下一次请求
start_time = time.time()
try:
with self.client.get(url, name="so_group_search_press",
catch_response=True) as response:
# 断言
if response.status_code == 200 and json.loads(response.text)["code"] == 0 and \
json.loads(response.text)['message'] == 'ok':
response.success()
else:
response.failure("请求失败，status_code不为200或返回code不为0或返回message不为ok: %s" % str(json.loads(response.text))[0:500])
except Exception as e:
response.failure("请求失败，status_code不为200或返回code不为0或返回message不为ok: %s" % str(e)[0:500])
time_delay = time.time() - start_time
if time_delay > 1:
pass
else:
wait_time = 1 - time_delay
time.sleep(wait_time)
遇到的问题总结：
1、脚本中涉及到对文件的处理，之前处理方式是采用本地txt文件，在脚本中采用with open打开该文件，之后想着将文件内容存储到redis中，后续通过调用redis进行参数提取
之前的脚本：
image.png
更改成通过redis调用后的脚本：
image.png
初看两个脚本是一致的，没有什么问题，但是在实际压测过程中，采用第一种方式，当用户数设置成80，RPS能够比较稳定在80并发，但是采用第二种方式发现将用户数设置成80，RPS可能只有20～30，不能够达到80并发，各种查原因，最后找到了答案
解释：首先明白min_wait和max_wait两个值的含义，代表的是模拟用户在执行每次任务之间等待的最小和最大时间
第一种打开文件场景下，实际上相当于80个用户每个用户上来都去执行test_task这个方法，每个用户只调用1次该方法，然后每个用户调用时都去with open打开这个文件，然后循环去访问文件内容，提取参数访问对应的服务接口，实际上没有用到min_wait和max_wait这两个值；
第二种场景下，80个用户每个人会一直调用test_task这个方法，每个用户调用完该方法之后会调用min_wait和max_wait时间，等待2000ms，然后再去调用test_task方法，其中用户之间是并发的，用户A在时间time1调用完test_task，等待2000ms，继续调用test_task方法，用户B在时间time2调用完test_task，等待2000ms，继续调用test_task方法，其中time1和time2是没有关联；
这样就解释了为什么场景二RPS无法达到80并发的原因
