性能常识 性能测试- locust 单机最高的并发是多少?

lyyyyyyy · 2023年08月01日 · 最后由 chend 回复于 2023年08月07日 · 10994 次阅读

公司在本月下旬有个接口需要百万级并发的压测。现在正在调研工具,初步选的是 locust。 但是查阅资料单机最高的并发数,有的说是 300,有的说 1000,有的说 60000+,有实际使用过的同学吗?

共收到 14 条回复 时间 点赞

看机器性能吧,自己试,httpuser 跟 fasthttpuser 差距很大的;本地多核启动跟单核启动也有差距;最后,百万级并发,一定是需要多机的,多少台机器需要看你测试结果

机器配置不一样,能够支持的并发数也不同。对单机能支持 60000+ 表示非常可疑。一般用 jmeter 比较多吧。 百万级肯定是分布式压测了。单机是不可能的。

是的,谢谢

差班生 #13 回复

看官网上给的数据,一核支持 5000,12 核可以支持到 60000。不过还没有尝试,后面有结果了来更新

你指的百分级并发, 指的是虚拟用户数还是 TPS/QPS? 类似于 Jmeter, 100 并发=100 线程. 但是 100 并发能产生几万的 QPS 也是可以的..
假如 1 个并发 (线程),1 秒内, 完成了 100 次请求 (响应时间平均 10ms), 那么这是 100 并发还是 1 并发.
我怀疑你说的并发是指的 QPS

仅楼主可见
chend #5 回复

真实用户有 100 万

lyyyyyyy #7 回复

真实用户 100 万不可能同时在线吧,还是按设计的同时在线的最大用户数测试

刚好最近使用 locust 进行生产持续 15 天压测,可以和你分享下一部分:

  • PS:我们压测的 QPS 平均在 4.2w 左右,远没有达到 100WQPS。

先说结论:locust 单机最高的并发是多少?这要看压力机配置。理论上如果 QPS 上不去,可以分布式机器,每台机器启 CPU 个数的 worker 来提升。

  1. 在写业务类时,优先继承 FastHttpUser,在同一机器上比 HttpUser 的 QPS 提升 5 倍左右。
  2. 如果对于 go 比较熟悉,使用 go 语言压测引擎 boomer 启动 worker,预计性能可以再提升 2 倍【在 FastHttpUser 的情况下】。
  3. 建议压测服务和服务器在同一台,通过内网请求最好。
  4. 在自己实验中 mbp、M1 芯片、8c16g、内网请求情况下,1000 并发,Go 的 QPS 可达到 5wQPS【本机关闭其它程序】,FastHttpUser 在 2.6w 左右,HttpUser 在 5000 左右.【请求接口很简单只返还 OK,仅为测试】。
  5. 如果是 ws 的压测,会占用非常高 90% 以上的 CPU,若要达到百万级 QPS,可能需要很好 CPU 配置,反而内存使用率不高。
  6. 过高并发数量,可能并不会压测出很高 QPS,因为涉及到两台机器的端口数量、Master 进程对 worker 进程中线程数调度等问题。
lyyyyyyy #7 回复

我其实是想纠正你的一个概念就是你所说的并发是指的 100WQPS, 而不是 100W 的虚拟用户数同时在线....
Locust 是基于 gevent 来模拟的虚拟用户数 (并发数), 然后模拟的 Http 请求, 根据响应的数量计算的 QPS, 也就是你描述的 100W.
Locust 的官方所说的单核 5000 8000 的也是这个指标 (QPS).
而你使用 Locust 测试的时候无法直接提供 100WQPS 去指令去测试,只能通过-c 之类的参数来提供虚拟用户数 (并发数) 来模拟请求,而这个-c 之类的参数的值, 可能是 100-200-300 等单位. 毕竟 gevent 启动的协程数量过大的话也会影响它 QPS 的施压能力..
-----------------------总而言之:
大部分开发嘴里的并发数, 其实都是 QPS/TPS 的值, 特别表明的除外.. 而测试工具不同, 提供的参数也不同, 造成的能力也会不同. 真实测的时候需要注意这点, 否则达不到官方所说的能力.

chend #11 回复

谢谢纠正,其实我理解他们的需求是,100w 用户,但是这 100w 用户不应该是同时请求,而是在某一个时间段。

chend #11 回复

谢谢宝贵的经验。另外有个问题想请教以下,每台 worker 都有自己发送请求的上线,我怎么去判断这个数量是当前 woker 的最大并发数呢?

lyyyyyyy #2 回复

不同的测试工具有不同的概念, 理解清楚之后才好对应入手设置参数. 对于 locust 来说, 你是需要通过命令行收入-c -n 之类的一系列的参数来启动对吧.(很久没用 Locust, 忘记具体参数名字了, 此处代指.)

那么, 此刻的 c, n 应该是指的 Locust 的并发数量 (gevent 的协程数量), 当你不设置休眠时间 (wait_time?) 的时候, 其实在每个协程内部类似于 while true {sendReq()}...对于协程来说, I/O 阻塞的时间才是它能利用的时间, 才是它能去发送其他请求的时间. 所以, APi 的响应时间快慢是会影响你单核设置的最大有效的协程数量的.

回到你的问题中, 每个 worker 的最大能力对不同 API 来说是动态, 你可以使用类似于每分钟递增 x 个的方式去边测边健康, 当服务器资源正常响应并且 Locust 的单核趋于 90-100% 波动的时候, 就说明对于这个 API, 单核的最大能力要到了.

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册