我的问题是：locust 脚本批量参数化了，但是压测没压力了。
下面分别说：一、性能设置，二、压测表现，三、参数化的方法，四、总结（我参数化了个寂寞）。
一、性能设置
我 locust 在本机跑的，同时批量跑 70 个接口，设置的用户总数是 10，每秒增加 10，也就是说直接到达到 10 用户并发。
二、压测表现
跑进来完全达不到，如下图
说一下对 70 多个接口同时压测时 locust 的表现：
首先在开始进行性能测试的时候，它不是一下进行所有接口请求，而是请求完一个接口再请求下一个接口这样的递增新接口请求。
并且在递增的同时，前面的接口也不进行请求了，直到增完了，再回过头来，从头开始请求。
例如，首先：
/getuser ok 次数 1
/gettime ok 次数 1
然后：
/getuser ok 次数 2
/gettime ok 次数 1
/getlikes ok 次数 1
执行的效率很低，甚至达不到压测的效果。
三、参数化的方法
我说下我是如何做的参数化：
首先是数据，有现成的接口测试参数化的数据（一个 excel 表）
然后是脚本：
1.在 on_start（初始化）方法里读取 excel 的数据并存到列表里
2.写一个 task 方法（locust 的执行任务），在里面每读取一行数据（就是一个接口的完整数据）后
执行一次请求
逻辑就是这样。
可我这么整的结果就是压测的压力完全起不来，压了个寂寞，
根本不如我一个脚本里就写俩三个接口那样请求效率高。
所以我的压测参数化没有成功。
四、总结
我个人思考结果是：我这样批量参数化压测行不通。
参数化也行，但肯定不能同时请求这么多接口了，一次请求 4、5 个接口差不多吧。
这样的话真不如多写几个 locust 脚本，执行完一个算一个。
问下大佬们的想法。
不熟悉 locust ， @debugtalk 帮忙看下是不是参数化姿势问题？
没明白你的描述. 但是从你截图代码中看到你代码设计的就是你 N 个接口逐个请求， 而不是 N 个接口并发请求．
而且, 你设置的 10 并发, 那么你的现象应该是 10 个 User, 相当于有 10 个 User 同时都在轮询你 Excel 中定义的接口, 而且是顺序逐步的.
chend
回复
对对对，是这样，那这样就等同于如同上面大佬所说的参数化的姿势有问题。现在我设置了 70 并发，实际执行效果还是一个一个执行，那可能就是如同你前面说的，N 个接口逐步请求，所以无法达成并发的效果。
陈恒捷
回复
@ 张狂天 我记得 on_start 是每个虚拟用户在启动前都会执行一次；你将 excel 的加载放到这里是不合适的，一方面是每个虚拟用户都要去加载打开 excel 文件，占用资源多；另一方面是虚拟用户之间没法实现数据的共享。
你可以参考下 HttpRunner v2/v3 在 locust 部分的代码
狂天
回复
你哪里设置了 70 并发
你设置的是 10 并发/User, 然后每个 User 的任务是挨个执行那 70 个 API.
我估计你对 Locust 理解错了. 和参数化没啥关系.
所以我猜测你的原意是想让你 Excel 的 70 个接口同时运行, 并且每个接口有 10 个并发？ 如果是的话,你估计需要分别对每个接口设置一个 Locust 脚本？ 可能是.....
如果对你每个接口 10 个并发这个数字 10 要求不那么敏感的话,也可以写一个 Locust, 然后用 task 装饰器装饰 70 个接口方法. 然后设置 700 并发. 权重一样的情况下, 每个 User 每进行一次请求都是从 70 个 Task 里面随机找的 (几率相等)
debugtalk
回复
我之前就是看的大佬博客学的 locust，没想到是大佬亲自上场指点，感谢大佬。然后顺便问下我对 excel 的读取方法从 onstart 里面取出来放到了 task 里运行之后：
还是跟之前一样是一个一个接口的请求，问下大佬是如何做的参数化呢？
针对你想少点代码写这个 70 个接口并发想法，我有个小建议：
LocustUser 的 Tasks 是个 TaskSet 的 list，可以尝试写方法将你的 70 个接口构造对应 TaskSet 放进去