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

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

记得很清楚,刚开始工作的时候要对一个网页进行压测用的是 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 条回复 时间 点赞
Keith Mo 回复

简直不要太好了。。谢谢

Keith Mo 回复

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

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 问题。

arrow 回复

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

回复

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

能对比下 ab 和 http_load 啊

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

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