服务器压力测试教程：用 ab 和 wrk 摸清并发上限

服务器压力测试，就是用工具模拟大量用户同时访问你的网站或接口，看服务器在多大并发下还能保持正常响应。
这篇教程面向零基础用户，用最常用的 ab 和 wrk 两款工具，带你从安装到出结果走完一遍，重点说清楚怎么读数据、怎么避免把线上业务打挂。

先搞清楚你要测什么

压测之前先明确目标，否则跑出来的数字没有意义。
常见需求有三种：

• 想知道当前服务器大概能扛多少并发，为升级配置或加带宽做参考。
• 接口改版或上线新功能后，验证性能有没有明显下降。
• 排查偶发变慢，看是数据库、后端程序还是带宽先到瓶颈。

明确目标后再选工具。ab（ApacheBench）安装简单、输出直观，适合快速测单个 URL；wrk 支持多线程和长连接，更适合压高并发场景。
两者都只发起 HTTP 请求，不会帮你分析代码逻辑，所以测试对象建议选一个具体的页面或接口地址。

准备环境与安装工具

以下命令以常见的 CentOS、Ubuntu 等 Linux 发行版为例，需要 root 或 sudo 权限。

安装 ab：

# Debian / Ubuntu
apt update && apt install -y apache2-utils

# CentOS / Rocky / AlmaLinux
yum install -y httpd-tools

安装 wrk（多数发行版仓库没有，需要编译）：

yum install -y git gcc make openssl-devel
# 或 apt install -y git gcc make libssl-dev
git clone https://github.com/wg/wrk.git
cd wrk && make && cp wrk /usr/local/bin/

验证是否装好：

ab -V
wrk --version

能打印出版本号就说明可用。

几个准备工作别跳过：

• 测试地址优先选测试环境，不要在业务高峰期直接压生产环境。
• 如果只能压生产，先跟相关同事确认，并设置较低并发逐步加量。
• 提前记录服务器当前 CPU、内存、带宽使用情况，方便对比。
• 确认目标 URL 返回正常，先用浏览器或 curl 打开一次。

用 ab 发起第一轮测试

ab 的基本用法是 ab -n 总请求数 -c 并发数 URL。
先跑一个小量级热身：

ab -n 1000 -c 10 https://你的域名/

含义是总共发 1000 个请求，同时并发 10 个。
注意 URL 末尾如果测首页，建议带上 /，否则可能被当成目录跳转。

测试完成后重点看这几行输出：

• Requests per second：每秒请求数，也就是常说的 QPS，越高说明吞吐能力越强。
• Time per request：平均每个请求耗时，单位毫秒，越低越好。
• Failed requests：失败请求数，理想情况是 0。
• Percentage of the requests served within a certain time：延迟分布，看 95% 和 99% 的请求耗时更有参考价值。

想逐步加压，可以把并发从 10 调到 50、100：

ab -n 5000 -c 50 https://你的域名/
ab -n 10000 -c 100 https://你的域名/

观察 QPS 是否随并发上升。
如果并发翻倍而 QPS 不再增长、延迟却明显升高，说明已经接近瓶颈。

用 wrk 压更高并发

wrk 的写法是 wrk -t 线程数 -c 连接数 -d 持续时间 URL：

wrk -t4 -c100 -d30s https://你的域名/

表示用 4 个线程、100 个并发连接，持续压 30 秒。
输出里主要看：

• Requests/sec：即 QPS。
• Latency：延迟的平均值、标准差和最大值。
• Socket errors：连接错误数量，出现非 0 要留意。

wrk 默认不带请求头，如果接口需要指定 Host 或认证，可以用 -H 参数：

wrk -t2 -c50 -d20s -H "Host: 你的域名" https://你的域名/api/test

压测过程中另开一个终端，用 top、free -m、iftop 观察 CPU、内存和网络，就能看出瓶颈大概在哪个环节。

这些坑最容易踩

• 并发一次拉太高。 从高并发起步很可能直接把服务打挂，甚至触发云厂商的防护。建议 10、50、100 这样阶梯式加。
• 只测一个静态页就下结论。 静态页几乎不消耗后端资源，真正要看的是带数据库查询或业务逻辑的接口。
• 忽略失败请求。 Failed requests 不为 0 时，QPS 再高也没有意义，要先解决报错。
• 在错误的时间压测。 业务高峰期压测会干扰真实用户，尽量选低峰或测试环境。
• 不看服务器日志。 压测后记得查 Nginx 或应用日志，确认没有大量 5xx 和超时。

结果怎么验证和记录

一次完整的压测，至少记录三组数据：

• 并发 10 时的 QPS 和平均延迟。
• 并发 50 时的 QPS 和平均延迟。
• 并发 100 时的 QPS、延迟和失败率。

把这三组和服务器监控曲线放在一起看，通常能找到 QPS 增长放缓、延迟陡升的那个并发点，这就是当前配置的参考上限。

如果压测结果不理想，常见方向包括：程序有慢查询、连接池太小、Nginx 或后端进程数配置偏低、带宽跑满。
可以先看服务器监控定位，再针对性调整，改完重新压测对比。

有一点要额外留意，压测结果和测试机、网络、被测环境都有关，不同时间的数字会有波动，不要拿单次结果当绝对结论。

常见疑问

ab 显示连接被拒绝怎么办？

先确认 URL 能正常访问，检查服务是否在监听对应端口，以及本机防火墙或安全组是否放行。

可以压测别人的网站吗？

不建议。
未经授权对他人服务器发起压测可能被视为攻击行为，请只测试自己拥有或已获得授权的目标。

压测时 QPS 很低，一定是服务器不行吗？

不一定。
压测机本身的 CPU、网络或到目标服务器的链路也可能成为瓶颈，可以换一台网络更好的机器复测。

服务器压力测试不是跑一次就完事的工作，重点是建立一套可重复的测试方法：固定目标接口、阶梯式加并发、记录 QPS 和延迟、对照服务器监控定位瓶颈。
按本文步骤先跑通一轮，再根据你自己的业务场景调整并发和测试时长，就能逐步摸清服务器的真实承载能力。