前言：别等网站被挤爆才想起压测
很多个人站长的服务器配置都是"够用就行"，等某天文章上了热搜、流量突然暴涨，网站瞬间卡死甚至宕机，才想起来问：我这台服务器到底能扛多少并发？与其事后补救，不如提前用压测工具摸清服务器的性能底线。本文介绍站长最常用的三款压测工具 ab、wrk 和 siege 的实战用法，以及如何通过压测结果定位性能瓶颈，让你的网站在流量洪峰到来之前就做好准备。
一、ApacheBench（ab）：最基础也最常用
ab 是 Apache 自带的压测工具，几乎所有 Linux 发行版都能直接安装，使用简单，适合快速摸底。Debian/Ubuntu 安装命令：
apt install apache2-utils基本用法是 -n 指定总请求数，-c 指定并发数：
ab -n 10000 -c 100 https://www.example.com/表示用 100 个并发连接发送 10000 个请求。跑完之后重点看几组数据：Requests per second（每秒请求数，也就是 QPS，这是最重要的指标）、Time per request（每个请求的平均响应时间）、Failed requests（失败请求数，必须为 0）、Percentage of requests served within a certain time（响应时间分布，看 99% 的请求在多少毫秒内完成，比平均值更能反映体验）。比如结果里写着 Requests per second: 500，说明这台服务器在 100 并发下每秒能处理 500 个请求。压测时建议从低并发开始，50、100、200、500 逐级往上加，观察 QPS 和响应时间的变化曲线：QPS 随着并发上升而上升，说明还有余量；QPS 停滞甚至下降、响应时间直线飙升，说明瓶颈出现了。
二、wrk：高并发下的真实水平
ab 有一个明显的短板：它是单线程模型，在低配机器上并发拉高时，ab 自己反而成了瓶颈，测出来的结果不准。wrk 支持多线程、多连接，还能用 Lua 脚本模拟复杂请求，是目前社区公认更靠谱的压测工具。安装方式：
apt install wrk # Debian 11+ 自带
# 或者源码编译
git clone https://github.com/wg/wrk.git && cd wrk && make基本用法：-t 线程数，-c 连接数，-d 持续时间：
wrk -t4 -c200 -d30s http://www.example.com/表示用 4 个线程、200 个并发连接持续压测 30 秒。输出里 Requests/sec 就是 QPS，Latency 分布会给出 p50、p75、p99 等分位值，比平均值更有参考价值。wrk 还支持压测 POST 请求和带请求头的接口，用 Lua 脚本：
wrk -t4 -c200 -d30s -s post.lua http://www.example.com/api-- post.lua 脚本内容
wrk.method = "POST"
wrk.headers["Content-Type"] = "application/json"
wrk.body = '{"key":"value"}'注意 wrk 默认开启 keep-alive（HTTP 长连接），测出来的是长连接下的性能，这符合真实浏览器行为，但如果你想测每次新建连接的场景，脚本里执行 wrk.headers["Connection"] = "close" 即可。
三、siege：模拟真实用户流量
siege 的特点是模拟"多个用户同时访问多个不同 URL"的场景，更接近真实用户的访问模式。安装：
apt install siege基本用法：
# 并发 100，持续 1 分钟，访问 urls.txt 里的多个地址
siege -c100 -t1M -f urls.txt
# 或者直接压单个 URL
siege -c100 -t30s http://www.example.com/输出重点看 Transactions（完成事务数）、Availability（成功率，99% 以上才算健康）、Elapsed time、Response time（平均响应时间）和 Transaction rate（每秒事务数）。urls.txt 里可以放首页、文章页、归档页等多个 URL，模拟用户在整个站点的浏览行为，比单一 URL 压测更有说服力。
四、动态页和静态页分开测，瓶颈一目了然
压测的核心技巧是"对照实验"：同样的压测参数，分别打静态页面和动态页面，对比结果就能快速定位瓶颈在哪一层。拿一个典型的 LNMP 站点举例：
# 压测 Nginx 直接返回的静态文件
wrk -t4 -c200 -d30s http://www.example.com/static/style.css
# 压测 PHP 动态生成的页面
wrk -t4 -c200 -d30s http://www.example.com/index.php如果静态文件 QPS 很高（几千甚至上万）而动态页面只有一两百，瓶颈基本锁定在 PHP-FPM 或者 MySQL；如果两者都很低，那问题出在 Nginx 配置、带宽或者服务器本身（CPU 太弱、内存不足触发 swap）。进一步细分：压测动态页面时同时观察 MySQL 的慢查询日志，如果大量慢查询出现，说明 SQL 有问题，先优化索引；如果 MySQL 很闲但 QPS 上不去，那就是 PHP-FPM 的进程数（pm.max_children）配置不足。压测过程中用 top、vmstat 观察系统指标：CPU 是否打满、内存是否吃紧、swap 有没有被使用、负载（load average）是否持续超过核心数。这些数据结合起来，瓶颈在哪个环节就非常清楚了。
五、别忘了测 HTTPS：证书握手也是一笔开销
很多站长压测只测 HTTP，上线却是 HTTPS，结果实际表现和压测数据差距很大。HTTPS 比 HTTP 多了一次 TLS 握手，握手的 RSA/ECDHE 密钥交换是 CPU 密集型操作，并发高的时候证书握手本身就能拖垮服务器。所以压测一定要用 https:// 开头的地址：
wrk -t4 -c200 -d30s https://www.example.com/
# ab 需要额外指定证书校验参数
ab -n 10000 -c 100 -k -Z ECDHE-RSA-AES128-GCM-SHA256 https://www.example.com/对比 HTTP 和 HTTPS 的 QPS 差距，能直观看到 TLS 开销有多大。如果 HTTPS 压测结果不理想，可以从几个方向优化：启用 OCSP Stapling 减少客户端的证书链校验请求、开启 session cache 和 session tickets 让客户端复用会话、优先选择 ECDHE 密钥交换（性能远好于 RSA）、把 TLS 版本和密码套件配置精简到只保留现代加密组合。个人站长推荐直接使用 certbot 生成的配置，它默认就是经过优化的现代配置。另外压测 HTTPS 时注意 wrk 的 -c 连接数要小于系统可用端口数，否则会报地址耗尽错误。
六、结合系统指标定位瓶颈所在
压测工具只负责制造流量和统计结果，真正定位瓶颈要靠系统监控。压测进行的同时，另开一个终端跑 top 和 vmstat 1，逐层观察：如果 CPU 的 us 列接近 100%，说明 CPU 是瓶颈，考虑升级配置或者减少动态请求；如果 wa 列很高，说明磁盘 IO 在拖后腿，MySQL 的磁盘读写、日志写入都可能是元凶；如果 si/so 列（swap 换入换出）持续非零，说明内存不足，进程在内存和磁盘之间反复搬运，性能会断崖式下跌。用 free -m 看内存，用 iostat -x 1 看磁盘 IO 的 util 和 await 指标，用 ss -s 看 TCP 连接数。把这些数据和压测结果放在一起，就能画出完整的性能画像：比如压测发现 QPS 只有 200，同时 CPU 很闲、MySQL 慢查询刷屏，那答案就很明确——SQL 优化优先，加机器没有意义。很多站长一卡就想着升级服务器，其实大部分瓶颈都出在配置和代码层面，先压测再花钱才是理性的做法。
七、压测案例：给博客做了个"体检"
用我的一个 Typecho 博客举例，1G 内存、单核 CPU 的小鸡，平时日均 IP 几百，一直觉得够用。用 wrk 压测首页动态页面，4 线程 100 连接压 30 秒，结果 QPS 只有 85，p99 延迟 1.8 秒，这个数据意味着只要来一波稍大的流量（比如文章被首页推荐），网站就会卡成幻灯片。接下来做对照实验：压静态资源文件，QPS 直接到 4200，说明 Nginx 本身没问题；再看 MySQL，慢查询日志里几乎没有记录，说明瓶颈在 PHP-FPM。查看 FPM 配置，pm.max_children 默认设的 5，明显太小，PHP 进程排队严重。调整成 max_children=20 之后重新压测，QPS 提升到 230，p99 降到 400ms，效果立竿见影。再叠加一层缓存插件（把首页和文章页缓存成静态文件），再次压测 QPS 到了 1800。整个过程验证了一个重要结论：压测-对照-定位-调优-复测，这个闭环比凭感觉调参高效得多，也让我知道这台小鸡的真实底线是"开启缓存后能扛住中等流量"，心里有底了。
八、压测的注意事项与避坑指南
最后提醒几个压测时的关键注意事项。第一，绝对不要在业务高峰期对线上环境做高并发压测，建议先测测试环境，或者选择凌晨低峰期，压测前先备份数据库；第二，压测机本身的性能要足够，如果压测机和服务器在同一台机器上，结果会互相干扰，最好用另一台机器压；第三，注意系统文件描述符限制，并发拉高时报 Too many open files，先执行 ulimit -n 65535 调大；第四，压测结果要和真实业务结合看，QPS 高不代表体验好，还要关注 p99 响应时间，压测目标是"在可接受的响应时间内支撑足够的 QPS"，比如"p99 小于 500ms 时 QPS 能达到 300"。摸清底线之后，再配合缓存、CDN、静态化这些手段，把动态请求尽可能变成静态请求，你的网站就能从容应对流量洪峰了。