4. 堪比JMeter的.Net压测工具 - Crank 进阶篇

1. 前言

上一篇文章我们了解了bombardier，并知道了bombardier.yml与开源项目bombardier的关系，接下来的文章我们了解一下wrk、wrk2，并对比一下它们与bombardier的关系

2. 认识wrk

wrk是一种现代 HTTP 基准测试工具，能够在单个多核 CPU 上运行时产生大量负载。它结合了多线程设计和可扩展的事件通知系统，例如 epoll 和 kqueue。

其支持参数：

-c, --connections: total number of HTTP connections to keep open with
                   each thread handling N = connections/threads

-d, --duration:    duration of the test, e.g. 2s, 2m, 2h

-t, --threads:     total number of threads to use

-s, --script:      LuaJIT script, see SCRIPTING

-H, --header:      HTTP header to add to request, e.g. "User-Agent: wrk"

    --latency:     print detailed latency statistics

    --timeout:     record a timeout if a response is not received within
                   this amount of time.

基础用法：

运行了30秒的基准测试, 使用2个线程、100个http连接:

wrk -t2 -c100 -d30s http://127.0.0.1:8080/index.html

进阶用法:

每次发送三个http请求:

wrk -t2 -c100 -d30s --script ./pipeline.lua http://127.0.0.1:8080

新建pipeline.lua

-- example script demonstrating HTTP pipelining

init = function(args)
   local r = {}
   r[1] = wrk.format(nil, "/?foo")
   r[2] = wrk.format(nil, "/?bar")
   r[3] = wrk.format(nil, "/?baz")

   req = table.concat(r)
end

request = function()
   return req
end

3. 认识wrk2

wrk2是一个主要基于 wrk 的 HTTP 基准测试工具。是一个被 wrk 修改以产生恒定的吞吐量负载，并将延迟细节精确到高 9s（即当运行足够长的时间时可以产生准确的 99.9999%'ile）。除了 wrk 的参数之外，wrk2 通过 --rate 或 -R 参数（默认为 1000）采用吞吐量参数（每秒总请求数）

除支持wrk的参数之外，还支持参数：

-R, --rate: 采用吞吐量参数（每秒总请求数）,默认为1000

基础用法：

运行了30秒的基准测试, 使用2个线程、100个http连接、并保持每秒2000个请求的恒定吞吐量:

wrk -t2 -c100 -d30s -R2000 http://127.0.0.1:8080/index.html

高级用法与wrk一致，此处忽略不写

我们使用wrk2测试一下百度的压测情况

安装：

sudo apt install wget
sudo wget https://aspnetbenchmarks.blob.core.windows.net/tools/wrk2

运行：

./wrk2 -d 3s -c 200 -t 200 -R 10 -L https://www.baidu.com

输出了本次请求每秒请求次数、吞吐量以及详细情况：

Requests/sec: 每秒请求次数
Transfer/sec: 每秒吞吐量

4. 了解Microsoft.Crank.Jobs.Wrk

在Microsoft.Crank.Jobs.Wrk项目中Program.cs

检查平台是否是64位的Linux系统、并检查参数是否满足要求
通过HttpClient发送请求，并记录第一次发送请求所消耗的时间
下载wrk，并设置wrk是可执行的
通过yml传递过来的参数构建完整的wrk命令
将输出的结果使用追加到stringBuilder上，再赋值给output，
通过正则匹配结果，最后通过BenchmarksEventSource存储并输出到控制台或数据库、csv、json中

其中:

connections: 每个线程处理时保持打开的 HTTP 连接总数 N = 连接数/线程数
serverUri: 自定义url，如果此参数存在，则请求地址为: {serverUri}:{serverPort}{path}
serverPort: 服务端口
serverScheme: 服务的Scheme，默认http、支持http、https两种
serverAddress: 服务地址、不包含http、例如: www.baidu.com，如果serverUri存在，此配置无效，如果不存在，请求格式为: {serverScheme}://{serverAddress}:{serverPort}{path}
path: 服务接口地址，不包含域，例如: /api/check/healthy
warmup: 预热时间，默认15s，与执行duration类似，而并非压测次数
- 当warmup > 0时，会先预热warmup秒后再执行一次压测，第二次的压测才是最后返回的结果
- 当warmup = 0时，不进行预热，直接开始压测
duration: 测试时长，默认15s
threads: 线程数、默认：32
customHeaders: 自定义headers，如果预设headers中没有需要的header，则通过重写customHeaders，以完成自定义header的目的
pipeline: 管道数量，默认为1，当大于1时，支持同时发送多个请求
script: 如果pipeline不大于1时，支持自定义lua脚本以及lua参数{scriptArguments}