使用wrk测试QPS

xukun2025-01-052025-01-05

前言：我们有个上线到个人服务器的项目，如果想测试QPS，该怎么做？

做法->选择一个合适的压力测试工具：

Apache JMeter：功能强大，支持多种协议（推荐）
wrk：轻量级工具，适合 HTTP 性能测试
ab（ApacheBench）：简单易用，适合基础 HTTP 测试
k6：现代化工具，支持编程测试脚本
Locust：基于 Python，适合复杂测试场景

这里我们选择wrk进行压力测试，wrk是一个轻量级的工具，比较适合我们这种小型单体项目的测试

准备步骤：

首先准备一台Linux/Mac
在服务器上安装wrk，这里以阿里云部署的centos7.9为例

一.wrk安装

在 CentOS 上安装 wrk 可以通过以下步骤完成：

1. 安装依赖

运行以下命令，确保系统已安装必要的工具和库：

1
2
3

sudo yum groupinstall "Development Tools" -y
sudo yum install epel-release -y
sudo yum install git gcc make openssl-devel -y

Development Tools：用于编译源码。
openssl-devel：wrk 依赖 OpenSSL 库。

2. 下载 wrk 源码

使用 git 克隆 wrk 的代码库：

1	git clone https://github.com/wg/wrk.git

3. 编译 wrk

进入下载的 wrk 源码目录并编译：

1 2	cd wrk make

编译完成后，wrk 的可执行文件将出现在当前目录下。

4. 安装到系统路径（可选）

为了在系统全局使用 wrk，可以将编译好的文件复制到 /usr/local/bin：

1	sudo cp wrk /usr/local/bin

安装完成后，可以通过以下命令检查：

1	wrk --version

5. 测试 wrk

运行一个简单的测试命令，确认安装成功：

1	wrk -t2 -c50 -d10s https://baidu.com

二.使用wrk进行QPS测试

这是我的项目想要测试的接口：

1. 测试接口分析

接口路径：POST /question/add
功能：用于创建新的题目
关键参数

2. Lua 脚本编写

使用 wrk 工具测试创建题目接口时，需要构建 POST 请求。以下是 Lua 脚本的内容，保存为 create_question.lua：

wrk.method = "POST"
wrk.body = [[
{
  "appDesc": "测试接口",
  "appIcon": "https://arthur-1319075927.cos.ap-shanghai.myqcloud.com/app_icon/1862885531399229442/mSnrr7wH-u=557378182,1636691557&fm=253&fmt=auto&app=120&f=JPEG.webp",
  "appName": "TestApp",
  "appType": 1,
  "scoringStrategy": 2
}
]]
wrk.headers["Content-Type"] = "application/json"

此脚本：

指定请求方法为 POST
提供 JSON 格式的请求体，模拟一个标准的题目创建请求
设置 Content-Type 为 application/json

最后将我们写好的lua脚本上传到服务器wrk路径下

3. 执行 wrk 测试

运行以下命令以测试接口性能：

1	wrk -t4 -c100 -d30s -s create_question.lua http://aimian.ikunyyds.top:8101/api/app/add

-t4：使用 4 个线程
-c100：100 个并发连接
-d30s：测试持续时间为 30 秒
-s create_question.lua：使用上面创建的 Lua 脚本

注意：需要根据自己接口替换的实际地址！！！

4. 测试结果示例

运行后，输出结果如下：

Running 30s test @ http://aimian.ikunyyds.top:8101/api/app/add
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   685.46ms  280.69ms   1.87s    69.64%
    Req/Sec    42.16     36.40   242.00     75.53%
  4273 requests in 30.02s, 1.78MB read
  Socket errors: connect 0, read 0, write 0, timeout 1
Requests/sec:    142.32
Transfer/sec:     60.76KB

测试结果分析

吞吐量
- 总请求数：4273
  - 在 30 秒内，系统共处理了 4273 个请求
- Requests/sec：142.32
  - 每秒成功处理了约 142 个请求
延迟
- 平均延迟：685.46ms（可能服务器是马来西亚的，对接国内的网站延迟会更高）
  - 每个请求的平均响应时间接近 0.7 秒
- 最大延迟：1.87s
  - 个别请求耗时接近 2 秒
- 标准差：280.69ms
  - 响应时间波动较大
传输速率
- Transfer/sec：60.76KB
  - 系统每秒传输约 60.76KB 的数据，数据量较小，接口处理瓶颈可能不是在网络层
Socket 错误
- timeout 1：有 1 个请求因超时失败

6. 增强测试

延长测试时间
- 进行 1 分钟或更长时间的压力测试，观察系统在更高负载下的性能变化
1
wrk -t4 -c100 -d60s -s create_question.lua http://aimian.ikunyyds.top:8101/api/app/add
通过结果可以看到，和30s时变化不大，说明比较稳定

在测试期间，我们使用宝塔云的检测面板观察服务器资源的消耗：
增加并发
- 提升并发连接数（500），测试系统在极限压力下的表现：
1
wrk -t4 -c500 -d30s -s create_question.lua http://aimian.ikunyyds.top:8101/api/app/add
通过结果可以看到：Socket errors: connect 0, read 0, write 0, timeout 4137，说明超过我们服务器的极限了，所有请求都失败了，那么降低一点并发量试试
1
wrk -t4 -c300 -d30s -s create_question.lua http://aimian.ikunyyds.top:8101/api/app/add
通过docker stats可以看到，2H2G的服务器在并发量为300左右时，资源已经拉满了，所以我们到达了极限
监控资源使用