新手区 locust boomer 测试 cpu 65 之后不升了

· 2021年07月13日 · 最后由 回复于 2021年07月15日 · 1064 次阅读

资源 1c 2g uvicorn,docker 部署


1.这个报告中的 rps 可以直接给领导说是每秒并发嘛

  1. 应该从哪些地方进行排查呢
共收到 11 条回复 时间 点赞

性能测试跟功能一样,先得有需求吧,再有设计,执行,比对预期结果和实际结果。
光从图上看,几千用户的时候 rps 就到峰值,后面的响应时间都是几十秒,什么业务系统能容忍这么高的响应时间呢?
如果是想把服务器 CPU 压满,那对于瓶颈本来就不在 CPU 的怎么压,再说 RPS 都上不去了追求 CPU 利用率有什么意义。

没怎么用过 locust ,先好奇问下,最后一个 number of users ,y 轴指的是并发线程数,还是累计用户数?

如果是累计,从斜率说明发送请求的速度是恒定的,那这个 rps 是否已经极限不好说,要换下并发线程数看下是否还是保持一致。不过从响应时间 95% 已经增大到这么大的数据看,大概率已经达到极限了。

如果是并发线程数,rps 应该早就极限了,但响应时间却在 1 分钟左右达到了一个相对稳定的值,只能理解为系统有自动降级措施,直接放弃处理请求直接返回了,所以响应时间没有继续涨。

陈恒捷 回复

累计用户数

两万多用户只有一百多 rps?响应时间太长了,rps 上不去,cpu 基本上就上不去了,先把响应时间降下来,把 RPS 搞上去,cpu 自然就上去了

那就是并发线程数恒定了,压力相对恒定了。

这个报告中的 rps 可以直接给领导说是每秒并发嘛

从现在的响应时间增大情况看,其实早就达到系统瓶颈点了(响应时间涨,说明系统现有的处理线程不够用,有不少请求其实已经在排队而非立即处理了)。建议并发线程数从 10 开始,先试试,然后逐步增加,看到多少的时候 rps 就不再上去,而是响应时间增加。

应该从哪些地方进行排查呢

不知道你说的排查是排查啥,这里的信息看不出啥呀。比如你说 cpu 不再上升,按照你现在性能表现分析,有可能是请求在队列里等待,实际处理线程已经是配置范围内全负荷运行了,那 cpu 不再上升也不奇怪(在队列里等待不会消耗 cpu 的)。如果确认这个接口的处理逻辑属于计算密集型,要通过提升 CPU 利用率提高性能,可以考虑增大线程数配置,让它同时多干点活。

#6 · 2021年07月15日 Author
陈恒捷 回复

那是在 rps 不上去,响应时间增加时的 用户数可直接说是并发数嘛?

#7 · 2021年07月15日 Author
MarvinWu 回复


抱歉,个人想先试试避免后面用,像之前的场景基本老大也是说直接压,然后完了 问 多少并发,同时当时的响应时间等指标情况,属于纯小白...

回复

并发数这个概念每个人理解都有不同,没有统一的定义。按照高楼老师在极客时间性能课程的定义,并发数就是 rps,指代系统实际最高性能。

压测工具里的用户数(并发线程数)不能代表真实用户的,毕竟真实用户不一定会这么高频访问接口。

建议你买本性能测试相关的书,或者看看极客时间里高楼老师性能测试的课程,先把性能测试相对完整的了解一下。

这响应时间看 QPS 没啥意义的

#10 · 2021年07月15日 Author
陈恒捷 回复

谢谢建议

#11 · 2021年07月15日 Author
Bingoo 回复

好的,谢谢

关闭了讨论 07月15日 16:27
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册