文章内容
2026/1/6 19:18:34,作 者: 黄兵
Caddy 压测
在前面几篇文章中，我们价绍了什么是 Caddy 以及如何在 Caddy 中启用 Brotli 压缩，同时我们还使用 Caddy 配置了通配符证书。
这些配置完成之后，我们需要测试 Caddy 性能到底怎么样。
这次我们使用的是 wrk 进行测试。
我们通过以下命令安装 wrk：
apt install wrk -y
如果出现：
Unable to locate package wrk
wrk 并不在所有发行版的默认软件源中，尤其是：
-
Debian 10 / 11 / 12
-
Ubuntu 某些最小化镜像
-
云厂商精简系统
我们可以通过源码编译 wrk（最稳定），具体步骤：
1️⃣ 安装依赖
apt update apt install -y git build-essential libssl-dev
2️⃣ 拉取并编译
git clone https://github.com/wg/wrk.git cd wrk make
3️⃣ 验证
./wrk --version
如果看到版本号，说明成功。
有的时候服务器在 IPv6 Only 中无法访问 github，我们可以将这个文件下载下载之后上传到 vps 上。
我们下载下来的是 wrk-master.zip文件，我们开始解压：
一、确认是否已安装 unzip
先检查系统是否已有 unzip：
unzip -v
如果提示未找到命令，则安装：
apt update apt install -y unzip
二、指定解压目录
如果解压到指定路径，例如 /opt：
unzip wrk-master.zip -d /opt cd /opt/wrk-master
三、编译 wrk
解压完成 wrk-master.zip，下一步通常是编译：
apt update apt install -y build-essential libssl-dev make
编译完成后，当前目录会生成可执行文件：
./wrk --version
👉 可选（加入 PATH）：
cp wrk /usr/local/bin/
之后可直接：
wrk -t8 -c200 -d60s https://im.eu-.o.example.com/test.jpg
我们现在开始测试：
./wrk -t8 -c200 -d60s https://ima.eu.o.example.com/common-be424.min.css
测试结果：
Running 1m test @ https://im.eu.o.example.com/common-be2e.min.css
8 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 881.12ms 448.83ms 2.00s 61.60%
Req/Sec 27.24 15.18 100.00 64.53%
12255 requests in 1.00m, 2.08GB read
Socket errors: connect 0, read 0, write 0, timeout 792
Requests/sec: 203.97
Transfer/sec: 35.41MB1️⃣ 核心指标摘要
并发连接数（-c）: 200 线程数（-t）: 8 压测时长（-d）: 60s QPS: ~204 req/s 吞吐量: ~35.41 MB/s 平均延迟: 881 ms 最大延迟: 2.00 s 超时请求: 792 次
关键结论：
⚠️ 系统已经进入明显的 I/O 等待或后端阻塞状态
问题点精准定位
❗ 1. 平均延迟 881ms（非常高）
对于一个 .css 静态资源来说：
-
理想值：10–50 ms（CDN/内存缓存）
-
可接受值：< 200 ms
-
当前值：≈ 900 ms ❌
这意味着：
-
并非网络问题
-
请求在后端等待资源释放
-
极可能是 Swift / 磁盘 / 连接池瓶颈
❗ 2. 出现 792 次 timeout（这是红灯）
Socket errors: timeout 792
这说明：
-
wrk等不到响应 -
后端响应时间 > 2s
-
Caddy / Nginx 本身没有 crash，但被“拖死”
❗ 3. QPS 偏低（204 req/s）
200 并发下：
-
优秀对象存储：1k–5k req/s
-
你当前：≈200 req/s
说明瓶颈不是前端代理，而是：
👉 Swift 对象读取能力 or Swift 前的 Nginx 到 Swift 通道
❗ 4. 吞吐量反而正常（35MB/s）
2.08GB / 60s ≈ 35MB/s
说明：
-
单请求文件体积不小
-
磁盘 / 网络带宽不是第一瓶颈
-
是并发处理能力问题（非带宽问题）
下面是服务器资源占用截图：
CPU 使用率（2vCPU）
磁盘读写数据：
网络传输：
网络 PPS 数据：
刚才是 177KB 的大文件测试，现在我们使用 0.6 KB 的小文件测试：
./wrk -t8 -c200 -d60s https://im.eu.o.example.com/h-favicon.png
测试结果：
8 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 650.63ms 358.46ms 2.00s 62.27%
Req/Sec 39.28 20.21 151.00 68.49%
18306 requests in 1.00m, 19.76MB read
Socket errors: connect 0, read 0, write 0, timeout 4
Requests/sec: 304.64
Transfer/sec: 336.77KB结果 CPU 还是 200%，说明：
压测开始 → CPU 瞬间拉满
-
压测结束 → CPU 瞬间回落
没有抖动、没有锯齿。
这说明：
CPU 被请求处理线程线性吃满，而不是锁、IO 或死循环
这种情况只能增加 CDN 缓存了。
其它相关推荐：
5、
评论列表