wrk 压力测试

wrk负载测试时可以运行在一个或者多核CPU,wrk结合了可伸缩的事件通知系统epoll和kqueue等多线程设计思想。目前wrk可以安装在Linux系统和Mac系统,下面看下wrk在Linux下的安装和用法。

1、压力测试工具wrk安装

[root@localhost /]# yum install git #安装git
[root@localhost wrk]# git clone https://github.com/wg/wrk.git #复制一份wrk源码文件
[root@localhost wrk]# cd /wrk/ #进入wrk源码文件夹
[root@localhost wrk]# mkdir /wrk #编译wrk
[root@localhost wrk]# cp ./wrk /usr/local/bin/ #复制到用户bin目录下

2、压力测试工具wrk用法

[root@localhost wrk]# wrk -t8 -c400 -d30s http://127.0.0.1
Running 30s test @ http://127.0.0.1
8 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 96.88ms 75.53ms 1.93s 97.18%
Req/Sec 554.79 60.39 680.00 78.48%
131271 requests in 30.05s, 97.40MB read
Requests/sec: 4368.91
Transfer/sec: 3.24MB

3、压力测试工具wrk常用参数
-t 线程数
-c HTTP连接数
-d 测试执行时间

我们先来做一个简单的性能测试:

wrk -t12 -c100 -d30s http://www.baidu.com

30秒钟结束以后可以看到如下输出:

Running 30s test @ http://www.baidu.com
12 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 538.64ms 368.66ms 1.99s 77.33%
Req/Sec 15.62 10.28 80.00 75.35%
5073 requests in 30.09s, 75.28MB read
Socket errors: connect 0, read 5, write 0, timeout 64
Requests/sec: 168.59
Transfer/sec: 2.50MB

先解释一下输出: 
12 threads and 100 connections 
这个能看懂英文的都知道啥意思: 用12个线程模拟100个连接. 
对应的参数 -t 和 -c 可以控制这两个参数. 

一般线程数不宜过多. 

核数的2到4倍足够了. 

多了反而因为线程切换过多造成效率降低. 

因为 wrk 不是使用每个连接一个线程的模型, 而是通过异步网络 io 提升并发量. 

所以网络通信不会阻塞线程执行. 

这也是 wrk 可以用很少的线程模拟大量网路连接的原因.

 而现在很多性能工具并没有采用这种方式, 而是采用提高线程数来实现高并发. 

所以并发量一旦设的很高, 测试机自身压力就很大. 

测试效果反而下降. 

下面是线程统计:

Thread Stats Avg Stdev Max +/- Stdev
Latency 538.64ms 368.66ms 1.99s 77.33%
Req/Sec 15.62 10.28 80.00 75.35%

Latency: 可以理解为响应时间, 有平均值, 标准偏差, 最大值, 正负一个标准差占比. 
Req/Sec: 每个线程每秒钟的完成的请求数, 同样有平均值, 标准偏差, 最大值, 正负一个标准差占比. 

一般我们来说我们主要关注平均值和最大值. 标准差如果太大说明样本本身离散程度比较高. 有可能系统性能波动很大. 

接下来:

5073 requests in 30.09s, 75.28MB read
Socket errors: connect 0, read 5, write 0, timeout 64
Requests/sec: 168.59
Transfer/sec: 2.50MB

30秒钟总共完成请求数和读取数据量. 
然后是错误统计, 上面的统计可以看到, 5个读错误, 64个超时. 
然后是所以线程总共平均每秒钟完成168个请求. 每秒钟读取2.5兆数据量. 

可以看到, 相对于专业性能测试工具. wrk 的统计信息是非常简单的. 但是这些信息基本上足够我们判断系统是否有问题了. 

wrk 默认超时时间是1秒. 这个有点短. 我一般设置为30秒. 这个看上去合理一点. 
如果这样执行命令:

1. /wrk -t12 -c100 -d30s -T30s http://www.baidu.com

可以看到超时数就**降低了, Socket errors 那行没有了:

1. Running 30s test @ http://www.baidu.com

2. 12 threads and 100 connections

3. Thread Stats Avg Stdev Max +/- Stdev

4. Latency 1.16s 1.61s 14.42s 86.52%

5. Req/Sec 22.59 19.31 108.00 70.98%

6. 4534 requests in 30.10s, 67.25MB read

7. Requests/sec: 150.61

8. Transfer/sec: 2.23MB

通过 -d 可以设置测试的持续时间. 一般只要不是太短都是可以的. 看你自己的忍耐程度了.

时间越长样本越准确. 如果想测试系统的持续抗压能力, 采用 loadrunner 这样的专业测试工具会更好一点. 

想看看响应时间的分布情况可以加上–latency参数:

1. wrk -t12 -c100 -d30s -T30s –latency http://www.baidu.com

1. Running 30s test @ http://www.baidu.com

2. 12 threads and 100 connections

3. Thread Stats Avg Stdev Max +/- Stdev

4. Latency 1.22s 1.88s 17.59s 89.70%

5. Req/Sec 14.47 9.92 98.00 77.06%

6. Latency Distribution

7. 50% 522.18ms

8. 75% 1.17s

9. 90% 3.22s

10. 99% 8.87s

11. 3887 requests in 30.09s, 57.82MB read

12. Socket errors: connect 0, read 2, write 0, timeout 0

13. Requests/sec: 129.19

14. Transfer/sec: 1.92MB

可以看到50%在0.5秒以内, %75在1.2s 以内. 看上去还不错. 

看到这里可能有人会说了, HTTP 请求不会总是这么简单的, 通常我们会有 POST,GET 等多个 method, 会有 Header, 会有 body 等. 

在我第一次知道有 wrk 这个工具的时候他确实还不太完善, 要想测试一些复杂的请求还有点难度. 现在 wrk 支持 lua 脚本. 在这个脚本里你可以修改 method, header, body, 可以对 response 做一下自定义的分析. 因为是 lua 脚本, 其实这给了你无限的可能. 但是这样一个强大的功能如果不谨慎使用, 会降低测试端的性能, 测试结果也受到影响. 

一般修改method, header, body不会影响测试端性能, 但是操作 request, response 就要格外谨慎了. 

我们通过一些测试场景在看看怎么使用 lua 脚本. 

POST + header + body. 

首先创建一个 post.lua 的文件:

1. wrk.method = "POST"

2. wrk.body = "foo=bar&baz=quux"

3. wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"

就这三行就可以了, 当然 headers 可以加入任意多的内容. 
然后执行:

1. wrk -t12 -c100 -d30s -T30s –script=post.lua –latency http://www.baidu.com

当然百度可能不接受这个 post 请求. 

对 wrk 对象的修改全局只会执行一次. 
通过 wrk 的源代码可以看到 wrk 对象的源代码有如下属性:

1. local wrk = {

2. scheme = "http",

3. host = "localhost",

4. port = nil,

5. method = "GET",

6. path = "/",

7. headers = {},

8. body = nil,

9. thread = nil,

10. }

schema, host, port, path 这些, 我们一般都是通过 wrk 命令行参数来指定. 

wrk 提供的几个 lua 的 hook 函数: 

setup 函数 
这个函数在目标 IP 地址已经解析完, 并且所有 thread 已经生成, 但是还没有开始时被调用. 每个线程执行一次这个函数. 
可以通过thread:get(name), thread:set(name, value)设置线程级别的变量. 

init 函数 
每次请求发送之前被调用. 
可以接受 wrk 命令行的额外参数. 通过 — 指定. 

delay函数 
这个函数返回一个数值, 在这次请求执行完以后延迟多长时间执行下一个请求. 可以对应 thinking time 的场景. 

request函数 
通过这个函数可以每次请求之前修改本次请求的属性. 返回一个字符串. 这个函数要慎用, 会影响测试端性能. 

response函数 
每次请求返回以后被调用. 可以根据响应内容做特殊处理, 比如遇到特殊响应停止执行测试, 或输出到控制台等等.

1. function response(status, headers, body)

2. if status ~= 200 then

3. print(body)

4. wrk.thread:stop()

5. end

6. end

done函数 
在所有请求执行完以后调用, 一般用于自定义统计结果.

1. done = function(summary, latency, requests)

2. io.write("——————————\n")

3. for _, p in pairs({ 50, 90, 99, 99.999 }) do

4. n = latency:percentile(p)

5. io.write(string.format("%g%%,%d\n", p, n))

6. end

7. end

下面是 wrk 源代码中给出的完整例子:

1. local counter = 1

2. local threads = {}

3.

4. function setup(thread)

5. thread:set("id", counter)

6. table.insert(threads, thread)

7. counter = counter + 1

8. end

9.

10. function init(args)

11. requests = 0

12. responses = 0

13.

14. local msg = "thread %d created"

15. print(msg:format(id))

16. end

17.

18. function request()

19. requests = requests + 1

20. return wrk.request()

21. end

22.

23. function response(status, headers, body)

24. responses = responses + 1

25. end

26.

27. function done(summary, latency, requests)

28. for index, thread in ipairs(threads) do

29. local id = thread:get("id")

30. local requests = thread:get("requests")

31. local responses = thread:get("responses")

32. local msg = "thread %d made %d requests and got %d responses"

33. print(msg:format(id, requests, responses))

34. end

35. end

https://sanwen8.cn/p/1d4kAUJ.html