压测工具界的“悍马”：wrk使用

在上篇文章 每个后端都应该了解的OpenResty入门以及网关安全实战 中，我向大家介绍了 OpenResty 的入门使用是 WAF 防御实战，这篇文章将给大家继续介绍 OpenResty 入门之性能测试 篇。

成都创新互联是一家专注于成都网站设计、网站制作与策划设计,锡林浩特网站建设哪家好?成都创新互联做网站,专注于网站建设十余年,网设计领域的专业建站公司;建站业务涵盖:锡林浩特等地区。锡林浩特做网站价格咨询:18980820575

性能测试是软件开发中不可或缺的一环，它可以帮助我们评估系统的性能、稳定性、可扩展性等指标，为优化和改进提供依据。但是性能测试也是最容易失准的一种测试，因为它受到很多因素的影响，例如网络环境、服务器配置、压测工具、压测场景等。如果我们选择了不合适的压测工具或者没有设计好压测场景，那么我们得到的结果可能会与实际情况相差甚远，甚至导致错误的判断和决策。

俗话说工欲善其事必先利其器，那么如何选择一款合适的压测工具呢？首先 OpenResty 是 fork 自 Nginx 开发，基于 Nginx 原有的强悍性能（协程 + IO 多路复用 Epoll），其性能也很高。所以我们需要的是一款自身性能足够强悍，可以最大程度榨干 OpenResty 程序性能、服务端 cpu 资源的压测工具。

这里给大家介绍一款压测工具界的“悍马” —— wrk。wrk 是一款针对 HTTP 协议的基准测试工具，它能够在单机多核 CPU 的条件下，使用系统自带的高性能 I/O 机制，如 epoll，kqueue 等，通过多线程和事件模式，对目标机器产生大量的负载。wrk 支持 Lua 脚本来创建复杂的测试场景（这一点与 OpenResty 支持 Lua 脚本相同），也可以输出详细的响应时间统计信息。wrk 的优点有以下几点：

• 高性能：wrk 可以利用多核 CPU 的并行计算能力，同时使用多个线程和连接来发送请求，并且使用高效的 I/O 模型来处理响应。这样 wrk 可以在单机上产生高达数十万甚至数百万级别的 QPS（每秒请求数），远超过其他常见的压测工具，如 ab、siege、jmeter 等。
• 灵活：wrk 支持使用 Lua 脚本来定制压测场景，例如自定义 HTTP 方法、动态生成请求参数、修改请求头等。这样我们可以模拟各种复杂和真实的用户行为和业务逻辑，使得压测结果更加贴近实际情况。
• 简洁：wrk 的安装和使用都非常简单，只需要几条命令就可以完成。wrk 的输出也非常清晰和直观，可以显示每个线程和总体的响应时间和每秒请求数，并且可以打印出响应时间的分布情况，方便我们分析系统的性能瓶颈。

wrk 的安装

wrk 只能被安装在类 Unix 系统上，所以我们需要一个 Linux 或者 MacOS 环境。Windows 10 安装需要开启自带的 Ubuntu 子系统。

Linux 安装

对于 Ubuntu/Debian 系统，可以通过以下命令安装 wrk：

sudo apt-get install build-essential libssl-dev git -y
git clone https://github.com/wg/wrk.git wrk
cd wrk
make
# 将可执行文件移动到 /usr/local/bin 位置
sudo cp wrk /usr/local/bin

对于 CentOS / RedHat / Fedora 系统，可以通过以下命令安装 wrk：

sudo yum groupinstall 'Development Tools'
sudo yum install -y openssl-devel git
git clone https://github.com/wg/wrk.git wrk
cd wrk
make
# 将可执行文件移动到 /usr/local/bin 位置
sudo cp wrk /usr/local/bin

MacOS 安装

Mac 系统也可以通过先编译的方式来安装，但是更推荐使用 brew 的方式来安装, 步骤如下：

• 安装 Homebrew，安装方式参考官网 https://brew.sh （也就一行命令的事）;
• 安装 wrk: brew install wrk;

Windows 10 安装

Windown 10 需要在 Windows 功能 里勾选 适用于 Linux 的 Windows 子系统, 然后通过 bash 命令切换到 Ubuntu 子系统。接下来，参考 Linux 安装 的操作步骤，安装 wrk。

压测前准备

在开始压测前，我们还需要对测试环境进行一番调整，已配合压测工具 wrk 榨干 OpenResty 程序的性能。

单进程最大文件数

Linux 系统默认对每个进程能够打开的文件数有一个限制，通常是 1024 个。这个限制会影响到服务器能够同时处理的连接数，因此需要增加这个限制。增加的方法是修改 /etc/security/limits.conf 文件，添加如下内容：

* soft nofile 65535
* hard nofile 65535

其中 * 号表示修改所有用户的限制，soft 或 hard 指定要修改软限制还是硬限制，65536 则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。

这样就可以将所有用户的单进程最大打开文件数限制设为 65535 个。如果还不够，可以继续增大这个值，但要注意不要超过系统级的最大打开文件数限制，可以通过 cat /proc/sys/fs/file-max 命令查看这个限制。

最大打开文件数

查看 Linux 系统级的最大打开文件数限制，使用如下命令：

[root@VM-16-5-centos ~]# cat /proc/sys/fs/file-nr
2112 0 369508

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

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

修改完以后，还需要重启系统服务来生效：

sysctl -p /etc/sysctl.conf

Nginx 工作进程数量以及连接数

最后，我们还需要对 Nginx 的配置文件做一些修改，如下：

# 配置工作进程数量
worker_processes  1;

...

events {
    # 单个工作进程处理连接数量
    worker_connections  1024;
}

默认情况下 Nginx 有 master 和 worker 两种进程，master 进程用于管理 worker 进程，worker 进程用于处理外部请求也就是对外提供服务。

worker_processes 1 的配置说明工作进程数默认为 1。在多核机器上我们可以设置为服务器 CPU 的核数以提升 Nginx 的连接处理数。

worker_connections 1024 的配置说明单个进程能处理的连接数量是 1024，在大压力场景下，我们可以提升这个值，改为 10240。

最后，优化的 Nginx 配置文件如下：

# 根据cpu核数自动设置工作进程数量
worker_processes  auto;

...

events {
    # 单个工作进程处理连接数量
    worker_connections  10240;
}

wrk 的使用

wrk 的基本用法是：

wrk  

 是一些可选的参数，用来控制压测的配置， 是要压测的目标网址。

常用参数

wrk 支持以下常用参数：

• -c, --connections ：指定要保持打开的连接数；
• -d, --duration ：指定压测的持续时间；
• -t, --threads ：指定要使用的线程数；
• -s, --script ：指定要加载的 Lua 脚本文件；
• -H, --header ：指定要添加到请求中的 HTTP 头；
• --latency：指定要打印响应时间统计信息；
• --timeout ：指定套接字/请求超时时间；

wrk -c 100 -d 30s -t 4 --latency http://121.4.xxx.xx/hello

Running 30s test @ http://121.4.xxx.xx/hello
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    60.74ms   94.62ms   1.82s    88.81%
    Req/Sec   710.91    118.29     1.02k    69.08%
  Latency Distribution
     50%   26.22ms
     75%   32.99ms
     90%  176.28ms
     99%  475.41ms
  84967 requests in 30.02s, 15.40MB read
  Socket errors: connect 0, read 0, write 0, timeout 2
Requests/sec:   2829.91
Transfer/sec:    525.08KB

Running 30s test @ http://121.4.xxx.xx/hello
  4 threads and 100 connections

Latency    60.74ms   94.62ms   1.82s    88.81%

Latency Distribution
     50%   26.22ms
     75%   32.99ms
     90%  176.28ms
     99%  475.41ms

Requests/sec:   2829.91

wrk -c 100 -d 10s -t 4 -s post.lua http://121.4.xxx.xx/hello

wrk.method = "POST"
wrk.body   = "name=tom"
wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"