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

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

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

共收到 14 条回复 时间 点赞

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

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

江涛依旧 回复

是的,谢谢

差班生 回复

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

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

仅楼主可见
chend 回复

真实用户有 100 万

lyyyyyyy 回复

真实用户 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 回复

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

chend 回复

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

chend 回复

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

lyyyyyyy 回复

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

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

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

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