问题应该是出现在施压侧，建议多检查下网络 IO、磁盘 IO 等，还有是否系统的文件句柄设置的过小

场景 2 和 3 是在同一个 VPS 吗，我之前也遇到过加压后，服务端 RT 不变的情况下，TPS 上不去，后来发现是施压侧带宽被占满导致实际压力根本没发出去，增加带宽后问题解决

那就没必要压了。
或者像楼下说的这样，这种情况主要是针对单用户的。比如我们也是限制单用户三秒内不能重复下单。
这种情况只能用海量用户去压，而不能单用户重复去压

mark 下。。。
最近在用 boomer 的时候，也遇到这个问题，比如开 5 个 slave，100 个用户的数据获取写在了 slave 侧，本意是想每个 slave 取其中的 20 个用户来发请求，但按照我目前这种写法，大概率是部分用户被多个 slave 重复使用了，部分用户没被用到。还没去想怎么处理，没看源码，还不知道多 slave 的时候，参数分配是怎么样的，目前想的是，能否放在 master 侧，由它来分配？如果这样的话，master 也不知道会有多少个 slave 过来，没法分配。。。

不知道你们后端是怎么响应的，不过我司是正常响应 http 状态码 200，responseBody 里面还有个 errorCode，比如这种情况为 2020，那么你做性能的时候，肯定需要判断当前请求是否成功，可以在判断 http 状态码为 200 的前提下再判断 errorCode。我这边有好几种这样的场景，我是定义一个比如 code_list，把这种业务限制的 code 丢进去，校验时判断如果当前的 errorCode 存在 code_list 中时，不向统计中心上报此条数据（可以根据这个业务场景的代码覆盖链条深不深来决定是否上报这条数据，比如如果在最外面的 api 网关层没做过多的业务判断就直接返回，这种请求可以直接丢弃，如果是走到了业务链最后端之后才返回，那么此条数据可以视为有效压力，就可以保留上报）

反复读了几遍这句话，还是没明白想要表达什么意思

关注下 RT，如果 RT 和最初相比没降，那应该找你施压侧的问题，可能是压力下降了，如果 RT 大幅增长，服务却没有报错，抓下链路数据，看看时间是消耗在哪里了。从描述来看，20 分钟就大幅下降，可以考虑关注下 DB 那块是不是出问题了

最初用的是 websocket 做的，每次调试的时候后端主动 push 过程消息至前端，后来觉得整个执行过程就几秒的时间，没必要做这么重，就直接将整个过程信息在结束的时候直接在 responseBody 中返回给前端了

这里也能遇见！第一次发帖，可惜项目太烂了，没人看得上

哎 最近也是打算用 locust 做压测的 实验了两天后发现达不到使用标准 作为施压侧 能力太弱了 经过实验最终得出的结论是 单核只能承载 500 左右的 RPS

我 12 核的 CPU 开了 12 个 slave 实际施压 RPS 不到六千 准备去试下 golang 下的 boomer 看看是否能达到作者说的十倍的提升