性能常识 WRK 个人使用经验总结

tlhymm42 · 2020年03月19日 · 最后由 哈哈哈 回复于 2021年06月10日 · 7530 次阅读

WRK 的结果怎么看?


如图:

  • Latency:表示的是响应时间(需要在命令中添加 --latency),顺序分别是: 平均值,标准偏差,最大值,正负标准差;

其中,平均值,最大值,有一定参考意义,如果标准偏差越小,一定层面能反应待测的接口是比较稳定的

  • Req/Sec:表示的是每个线程每秒的完成的请求数,顺序分别是: 平均值,标准差,最大值,正负标准差;

参考价值与响应时间类似

链接数和线程数应该设多少?

先上结论:
-t(线程数):
一般是 CPU 核数,最大不要超过 CPUx2 核数,否则会带来额外的上下文切换,将线程数设置为 CPU 核数主要是为了 WRK 能最大化利用 CPU,使结果更准确
-c(连接数):
连接数(connection)可以理解为并发数,一般在测试过程中,这个值需要使用者不断向上调试,直至 QPS 达到一个临界点,便可认为此时的并发数为系统所能承受的最大并发量。
实际上,wrk 会为每个线程分配(c/t)个 socket 连接,每个连接会先执行请求动作,然后等待直到收到响应后才会再发送请求,这个日后会有关于 wrk 的源码解析方便理解,所以每个时间点的并发数大致等于连接数(connection)

连接数(c)与 QPS(q),请求响应时间毫秒(t)的关系大概可理解为:q = 1000/t * c
RTT 为 1ms,如果 c(连接数)为 1,则理论上 QPS 接近 1000,如果 c(连接数)为 100,则 QPS 接近 10w
RTT 为 10ms,如果 c(连接数)为 1,则理论上 QPS 接近 100,如果 c(连接数)为 100,则 QPS 接近 1w

但是服务有自己的负载极限,并发数不能无限放大,这就能解释有的时候连接数越大,反而 QPS 越低,是因为并发数已经设的过高,导致待测系统已经超出自身能承受的负载

WRK 对比 JMETER 和 AB,各个的极限究竟怎么样?

结论:
WRK 与 AB 性能最好,300 并发下,QPS 最高都可达到 19w,但 WRK 资源消耗适中(cpu 涨幅最高 9%),而 AB 资源消耗较高(cpu 涨幅最高 42%)
JMETER 相同并发下,QPS 最高可达到 8.6w,资源消耗较高(cpu 涨幅最高 42%)

施压机:CPU(24 核,E5-2620 2.40HZ)
压测对象:nginx 自定义的接口

WRK:线程数 = 24,并发数 = 300,QPS = 193000,响应 99Line 为 2.74ms,CPU 波动峰值 9%

AB:并发数 = 300,QPS = 197000,响应平均 2ms,CPU 波动峰值 42%

JMETER:并发数 = 300,QPS = 86000,响应平均 3ms,CPU 波动峰值 42%

WRK,JMETER,GATLING 该怎么选择?

场景不复杂,需要快速进行压测验证,HTTP/HTTPS 协议:
推荐使用 WRK,性能佳,且通过 lua 脚本能制定简单的测试脚本(比如参数化,自定义上报结果等),但是只能针对 HTTP、HTTPS 协议接口,具有功能的局限性
场景复杂,需要测其他协议:
使用 Jmeter,性能不足,机器来凑
而 GATING 虽然性能也不错,但劣势主要在于 scala 具有一定学习成本,且其非商业版不支持分布式的执行

总结

WRK 个人认为非常适合作为一款压测工具,其代码量并不太多,且不复杂,可适当对其进行魔改以适应各自的特殊需求
源码阅读可跳转:wrk 源码阅读

共收到 6 条回复 时间 点赞

ab 的性能不太可能会比 jmeter 差,你的 benchmark 测试中的是否开启了 keep alive?

jacexh 回复

感谢提醒,的确忘记了 AB 这个选项

请教一下楼主,wrk 是测试的 http 长连接还是短连接,这个有没有选项可以控制呢?

爱吃米饭 回复
  1. 可以通过手动设置 header,将 connection 置为 close 达到短链接的效果
tlhymm42 回复

谢谢楼主,已经解决了~

楼主是怎么知道 -t 最好跟 CPU 核数相关联呢?

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