性能测试工具 一把性能基线测试瑞士军刀,wrk 性能测试工具

大话性能 · 2018年08月23日 · 最后由 测试初妹 回复于 2019年03月16日 · 3101 次阅读

记得很清楚,刚开始工作的时候要对一个网页进行压测用的是 ab 命令,Apache 自带的,该命令基本上只能支持超级简单的页面压测。今天讲讲另一款更加瑞士军刀版的工具 wrk。wrk 是一款现代 HTTP 基准测试工具,能够在单个多核 CPU 上运行时产生显着负载。它将多线程设计与可扩展事件通知系统(如 epoll 和 kqueue)结合在一起,这意味着我们可以用少量的线程来跟被测服务创建大量连接,进行压测,来一起实践一下。
更多工作实战好文,尽在公众号大话性能,敬请关注。
http://dwz.cn/ZXoyv528

1、安装部署

wrk 支持大多数类 UNIX 系统,不支持 windows,安装 wrk 非常简单。
首先只要从 github 上下载 wrk 源码;
git clone https://github.com/wg/wrk
然后执行 make 命令安装;
make 之后,会在项目路径下生成可执行文件 wrk,随后就可以用其进行 HTTP 压测了。

Ps: 可以把这个可执行文件拷贝到某个已在 path 中的路径,比如/usr/local/bin,这样就可以在任何路径直接使用 wrk 了。
我是在本机 mac 上安装的,wrk -v 即可验证是否安装成功。

2、参数说明

Wrk 使用中最常用的选项命令含义解释如下。
使用方法: wrk <选项> <被测 HTTP 服务的 URL>

常用选项:
-c, --connections 跟服务器建立并保持的 TCP 连接数量
-d, --duration 压测时间
-t, --threads 使用多少个线程进行压测
-s, --script 指定 Lua 脚本路径
-H, --header 为每一个 HTTP 请求添加 HTTP 头
--latency 在压测结束后,打印延迟统计信息
--timeout 超时时间,默认 1s

一般线程数不宜过多,核数的 2 到 4 倍足够了,多了反而因为线程切换过多造成效率降低,因为 wrk 不是使用每个连接一个线程的模型, 而是通过异步网络 io 提升并发量,所以网络通信不会阻塞线程执行,这也是 wrk 可以用很少的线程模拟大量网路连接的原因,而现在很多性能工具并没有采用这种方式, 而是采用提高线程数来实现高并发,所以并发量一旦设的很高, 测试机自身压力就很大,测试效果反而下降。

3、简单使用

Wrk 最简单的使用如下,对 www.baidu.com 页面进行了简单压测,不带任何请求头,请求参数。


结果说明:
一般我们最关心的几个结果指标
1、Latency: 可以理解为响应时间分布。
2、Requests/Sec: 每秒的处理请求数,可以理解为 tps。
3、连接超时数目 timeout。

4、高级用法

而很多实际工作中,不可能像上面那么简单的压测,我们可能需要使用 POST METHOD 跟服务器交互;可能需要为每一次请求使用不同的参数,以更好的模拟服务的实际使用场景等。wrk 支持用户使用--script 指定 Lua 脚本,来定制压测过程,满足个性化需求。但是也不能完全替代其他压测工具进行特别复杂的场景设计,毕竟也只是瑞士军刀而已。

在 lua 脚本里你可以修改 method, header, body, 可以对 response 做一下自定义的分析。接下来就讲讲 get 请求和 post 请求里面如何动态化参数。

1、get 请求,请求参数 uid 随机生成。结果如下,每次请求 uid 都是不一样的。


2、post 请求,发送 json 的 body,其中 age 字段动态变化。


现在 wrk 支持 lua 脚本,虽然这给了你的请求带来了无限的可能,但是这样一个强大的功能如果不谨慎使用, 会降低测试端的性能, 测试结果也受到影响。
一般修改 method, header, body 不会影响测试端性能, 但是操作 request, response 就要格外谨慎了。

大家可持续关注大话性能公众号,不断学习测试实战技能和高薪岗位内推。

共收到 7 条回复 时间 点赞

楼主有二次开发过 wrk 吗?缺点是验证不了返回,有实际应用的分享吗?

能对比下 ab 和 http_load 啊

回复

用 lua 脚本可以做简单的校验,一般很复杂的也不建议用 wrk 工具了,毕竟我觉得它擅长于简单的基线测试,类似于
response = function(status, headers, body)
if status == 200 then
token = headers["X-Token"]
path = "/resource"
wrk.headers["X-Token"] = token
end
end

arrow 回复

ab 和 http_load 现在基本很少用了,建议你可以考虑用 jimeter、locust,一款是基于 java 开源,一款是基于 python 开源,可扩展性强。
可以关注微信公众号大话性能哦。😀

arrow 回复

http_load 06 年的过时东西了就别提了吧……

ab 不推荐,content-length 长度变了也当成错误,而且单线程是个瓶颈,用 nginx-status 页面做测试,客户端找台 8 核以上的服务器,跑一下就知道和 wrk 差距有多大了。

小工具推荐 wrk2,https://github.com/giltene/wrk2,是 wrk 的分支。推荐看看作者 Gil Tene 在 readme 里写的关于如何正确测量响应时间,推荐搜一下作者讲 coordinated omission(CO)的 2 个 youtube 视频。

wrk 也可用,性能也更好些。建议跟 wrk2 对照,毕竟 CO 是个大坑,全世界绝大部分压测工具都掉坑里。

locust 不推荐,一是作者看上去不知道自己在做什么,二是框架性能和报告功能都极差,有这功夫填坑不如找个更正经的框架二次开发。

ngrinder 不推荐,往往是只做过 demo 的人才吹它的开箱即用。github 上 2 年多没更新了,跟死了差不多。

taurus + jmeter 组合现在很流行,算是可用,但小心 CO 问题。它的命令行报告生成的网页里,首页的响应时间百分位数统计不一定可靠,注意点开看菜单里的各种 overtime 图表。坑踩得少的人很容易用它骗自己接口的响应时间没问题。现在项目里已经基本抛弃它了。

愿意封装和写代码的话推荐 Gatling。动手封装前最好搜一下一篇貌似叫 close workload model vs open workload model 之类的论文,06 年的。Gatling 要用 open workload model,也就是指定 RPS 然后它每秒新建这么多连接,才能避免 CO 问题。

Keith Mo 回复

我们现在都是用的 JMeter 做性能测试。
一下介绍了这么多工具,我去研究看看。
非常感谢你耐心的回复。

Keith Mo 回复

简直不要太好了。。谢谢

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