作为研发不会进行服务调优 & 评估服务性能 ？作为测试搞不定性能测试？你需要这样一匹 “悍马“ —— wrk

Posted 2021-09-05 魏小言

文章目录

• • 背景
  • Wrk 介绍
  • 前期环境检查
  • • 最大文件数
    • 打开进程限制
  • 压力测试实操
  • • GET
    • POST
  • 性能数据衡量
  • Q&A
  • 附录

背景

  在服务模块开发完成进行交付时，总会有些数据需要提供，比如服务最大负载 QPS 、P99 如何等等…

  这些数据哪来的呢？ 一般都是 QA 同学进行模块压测，通过模拟上线负载，得到具体的服务性能数据。

  作为一名开发，如何独立对自己的服务做简单的性能评估呢？

  不急，这里介绍一款性能测试工具 —— Wrk ！轻轻松松拿下各种性能数据

Wrk 介绍

Wrk 是一款轻量级的 Http 基准测试工具。

• Wrk 充分利用系统多核资源，测试结果更真实！
    毕竟现在服务大都基于协程和异步 I/O 开发。
• Wrk 生产压力足够大，性能测试效果更好！
    单机的 wrk 产生的压力，可以轻轻松松让 nginx 跑满 CPU 。
• Wrk 使用灵活、便捷、易上手！
    依托 LuaJIT 和 Redis 设计，支持 Lua 脚本自定义请求。

下面就来介绍一下单机压测的实操流程！

前期环境检查

  由于单机进行性能压测，需要模拟一非正常的流量负载，需要对我们的环境进行些配置，以允许支持负载的正常进入。

最大文件数

  查看下当前系统的全局最大打开文件数：

$ cat /proc/sys/fs/file-nr
3984 0 3255296

  最后一个数字，就是最大打开文件数。如果你的机器中这个数字比较小，那就需要修改 /etc/sysctl.conf 文件来增大：

fs.file-max = 1020000
net.ipv4.ip_conntrack_max = 1020000
net.ipv4.netfilter.ip_conntrack_max = 1020000

  修改完以后，重启系统服务生效：

sudo sysctl -p /etc/sysctl.conf

打开进程限制

  除了系统的全局最大打开文件数，一个进程可以打开的文件数也是有限制的，可以通过命令 ulimit 来查看：

$ ulimit -n
1024

  这个值默认是 1024，是一个很低的数值。因为每一个用户请求都会对应着一个文件句柄，而压力测试会产生大量的请求，所以我们需要增大这个数值，把它改为百万级别，可以用下面的命令来临时修改：

• $ ulimit -n 102400「当前进程有效」

• 修改配置文件 /etc/security/limits.conf 「永久生效」
     hard nofile 1024000
    soft nofile 1024000

压力测试实操

  前期环境调整完后，就开始压测了。wrk 命令十分简洁，如下：

[XXXX@dev-1XX working]$ wrk2
Usage: wrk
Options:
-c, --connections Connections to keep open
-d, --duration Duration of test
-t, --threads Number of threads to use

-s, --script      <S>  Load Lua script file       
-H, --header      <H>  Add header to request      
-L  --latency          Print latency statistics   
-U  --u_latency        Print uncorrected latency statistics
    --timeout     <T>  Socket/request timeout     
-B, --batch_latency    Measure latency of whole   
                       batches of pipelined ops   
                       (as opposed to each op)    
-v, --version          Print version details      
-R, --rate        <T>  work rate (throughput)     
                       in requests/sec (total)    
                       [Required Parameter]       

  实操具体分两种类型:

• method = “GET” 类型
• method = “POST” 类型

GET

  通过指令行直接执行，无需额外参数数据处理。

wrk2 -r1000 -t12 -c400 -d30s http://127.0.0.1:8080/index.html？param1=string&param2=integer

  解析：Wrk 使用 12 个线程，保持 400 个长连接，持续 30 秒钟，来给指定的 API 接口发送 HTTP 请求。

POST

  需要借助 Lua 脚本完成参数的填充，Wrk 支持 Lua 脚本执行，一般只需要改动其几个常量即可。

wrk -d10s -U -R10000 -s …/scripts/post.lua http://127.0.01:8080/v1/get-config

post.lua Lua 脚本：

wrk.method = “POST”
wrk.body = ‘{“businessId”:21,“requestId”:“12312312312312”,“userId”:“188363934”,“deviceInfo”:“10B1193”}’
wrk.headers[“Content-Type”] = "application/json”

  解析：Wrk 使用 2 个线程和 10 个长连接，持续 10 秒钟来进行 POST 请求，参数为 Lua 脚本数据。

「不指定参数的话，wrk 会默认启动 2 个线程和 10 个长连接。」

性能数据衡量

  理论上，一般压测我们需要跑出最大负载就可以了，即 CPU 将近打满。所以我们不用把 Wrk 的线程数和连接数调整得很大，只要能够让目标程序跑满 CPU 就达到要求了。
  在压测期间，需要使用 top 或者 htop 这样的监控工具，来确认服务端目标程序是否跑满 CPU。
  从现象上来看，如果 CPU 满载，而且压测停止后，CPU 和内存占用迅速降低，那么压测顺利完成。

  下面我们看下压测结果数据：

wrk2 -r1000 -d30s http://127.0.0.1:8080/index.html？param1=string&param2=integer
  
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 595.39us 178.51us 22.24ms 90.63%
Req/Sec 8.33k 642.91 9.46k 59.80%
499149 requests in 30.10s, 124.22MB read
Requests/sec: 16582.76
Transfer/sec: 4.13MB

• QPS Requests/sec: 16582.76，表示服务端每秒钟处理了多少请求。
  Latency Distribution
  50% 134.00us
  75% 180.00us
  90% 247.00us
  99% 552.00us

• 耗时 Latency Distribution ，表示请求不同耗时分布区间，即 P99/90…

  通过这两个指标，可以大体完成对整个服务的性能评估！

Q&A

1、 wrk 中的 -r 是指什么？

-R/r 是每秒平均并发请求数，可以直接设置为目标 QPS ，通过观察对比 Requests/sec 和 Latency 数据，不断调整，最终判定最终 QPS。

2、Wrk2 和 Wrk 有哪些异同呢？为啥我们要用 Wrk2 呢？

Wrk2 是 Wrk 的升级版，最大的可见异同是 指令 添加了必填项 — rate，用于提供稳定的吞吐量以及更精确的延时统计；其它地方无明显区别。

3、在进行 Wrk 之后，可以拿到数据，如果达不到预期的效果，咋办？

会出现这种情况，通过压测，发现服务并没有预期的抗压！
在进行压测观察 CPU 负载时，可以结合 性能工具进行性能调优，比如 Go 的 pprof ，依据具体的 pprof 数据指标进行针对性调整。

附录

各种工具的熟悉使用，会让开发效率倍增！