背景

  • 公司对 http 接口都是直接用 wrk 进行压测,简单快捷
  • 刚好有个压测任务分到我
  • 而且中台跟 Lua 也有关系,刚好 wrk 也支持 Lua 脚本,所以学起来,再用起来

 

介绍

  • wrk 是一个类似 ab(apache bench)、jmeter 的压力测试工具,官方称它为:现代的 HTTP 基准测试工具
  • 用 C 编写的 HTTP 协议压测工具
  • 底层基于 epoll 和 kqueue 实现,使用了多线程和多路复用 IO(非阻塞 IO),利用异步的事件驱动框架,通过很少的线程就可以压出很大的并发量
  • 降低测试工具本身性能开销对测试结果准确性的影响
  • 支持使用 LuaJIT 脚本,可以执行 HTTP 请求生成、响应处理和自定义报告

 

它的定位

  • 轻量级性能测试工具
  • 仅支持 HTTP 协议
  • 仅支持单机压测,多机器压测需要每个机器都手动执行一次 wrk 命令
  • 不可取代 Jmeter、LR 等专业性能工具

 

架构&简单源码解析

  • 在 wrk 里面,每个线程都有自己独立的 Lua 虚拟机和 Event Loop
  • 通过命令行参数 -c 指定的连接数,会平均分给所有线程,每个新建的 socket,都会调用 fcntl 将其设置为 NONBLOCK,即非阻塞,然后托管给 Event Loop
  • 直接使用 redis 的 Event Loop 实现,适配了不同操作系统的实现
  • 启动的时候,每个线程都会新建一个 Lua State,并调用 luaL_dofile 加载命令行参数 -s 指定的 lua 脚本文件
  • 如果没有自定义的 lua 脚本,wrk 默认发送的是 HTTP 1.1 GET 请求,用长连接
 

语法格式

Usage: wrk <options> <url>
  Options:
    -c, --connections <N>  Connections to keep open
    -d, --duration    <T>  Duration of test
    -t, --threads     <N>  Number of threads to use

    -s, --script      <S>  Load Lua script file
    -H, --header      <H>  Add header to request
        --latency          Print latency statistics
        --timeout     <T>  Socket/request timeout
    -v, --version          Print version details

  Numeric arguments may include a SI unit (1k, 1M, 1G)
  Time arguments may include a time unit (2s, 2m, 2h)

  

参数说明

  • -c:与服务器保持的 http 连接数
  • -d:压测持续运行时间,可以是 2s、2m、2h
  • -t:启动的线程数
  • -s:指定 lua 脚本
  • -H:自定义 http header 请求头,例如:"User-Agent: benchmark-wrk"
  • --latency:打印延迟统计数据
  • --time:http 超时时间,如果在此时间内未收到响应,则当做超时

 

数字参数:可以使用 1k、1M、1G 单位

 

-t

  • 一般是 CPU 核数,最大不要超过 CPUx2 核数,否则会带来额外的上下文切换,将线程数设置为 CPU 核数主要是为了 WRK 能最大化利用 CPU,使结果更准确(截取网上,暂时没看到官方推荐)
  • 和并发数没有直接关系
  • 查看 Linux CPU 总核数:
grep processor /proc/cpuinfo |wc -l

 

-c

  • 连接数(connection)可以理解为并发数
  • 一般在测试过程中,这个值需要使用者不断向上调试,直至 QPS 达到一个临界点,便可认为此时的并发数为系统所能承受的最大并发量
  • 实际上,wrk 会为每个线程分配(c/t)个 socket 连接
  • 每个连接会先执行请求动作,然后等待直到收到响应后才会再发送请求,所以每个时间点的并发数大致等于连接数(connection)

 

官方 Tips

  • 运行 wrk 的机器必须有足够数量的临时端口可用,关闭的 socket 必须快速回收
  • 仅更改 HTTP 方法、路径、添加请求头或正文的用户脚本不会对性能产生影响
  • 每个请求的操作,特别是构建新的 HTTP 请求,以及 response() 的使用将必然减少可以生成的负载量

 

简单栗子

启动 2 个线程,保持 5 个 http 连接打开的状态下,持续压测 10s 的基准测试

wrk -t2 -c5 -d10s https://httpbin.org/get

qps 是 14.85

 

启动 16 个线程,保持 400 个 http 连接打开的状态下,持续压测 5s 的基准测试,并打印延迟统计数据

wrk -t16 -c400 -d5s --latency https://httpbin.org/get

qps 是 578.7

 

结果解析

Running 5s test @ https://httpbin.org/get   压测时间5s
  16 threads and 400 connections   共16个测试线程,400个连接,和上参数设置一样
  Thread Stats   Avg      Stdev     Max   +/- Stdev
                平均值    标准差     最大值  正负标准差的范围,越大表示值和平均值不会差很多,离散也不大,表示 Avg 相对可信
    Latency   311.74ms  211.97ms   1.57s    90.79%
    延迟
    Req/Sec    47.86     31.17   170.00     66.79%
    每个线程每秒的完成的请求数
  Latency Distribution 延迟分布
     50%  234.77ms
     75%  244.43ms
     90%  402.99ms
     99%    1.26s     99% 的请求在 1.26s 内完成
  2938 requests in 5.08s, 1.21MB read  5.08 s内共处理完成了 2938 个请求,读取了 1.21MB 数据
  Socket errors: connect 166, read 0, write 0, timeout 1   Socket 成功连接 166个,超时 1 个
Requests/sec:    578.70  平均每秒处理完成 578.7 个请求,QPS=578.7
Transfer/sec:    243.05KB  平均每秒读取数据 243.05KB

 

-t 的一些实验

测试资源

  • 施压机:16c32g
  • 受压机:8c16g

接下来对某个接口进行基准测试

 

16 个线程,400个并发量,持续运行 5min

qps:20504.3

 

64 个线程,400个并发量,持续运行 5min

qps:19948.69

 

128 个线程,400个并发量,持续运行 5min

qps:18811.35

 

结论

  • 线程数增加,qps 反而下降
  • 初步可以认为,-t 线程数取系统 CPU 核数是一个比较靠谱的建议