导读：本站发过不少性能向文章：WordPress从3秒提到0.5秒、MySQL查询提速10倍、Nginx静态资源配置、内核参数调优。评论区常见一个追问：优化完了，怎么证明真的变快了？“感觉快了”不算数，同一时刻网络波动都能骗过你的体感。严谨的做法是压测：用工具模拟并发访问，把“快不快”变成“每秒能扛多少请求、99%的用户等多久”这样的硬数字。这篇讲压测的方法论和工具：ab快速上手、wrk高压模拟、k6场景化脚本，以及最容易被忽略的——压测姿势不对，数字全是自欺欺人。
一、先立靶子：压测到底测什么
压测不是“跑个工具看个分数”，开始前必须定义清楚三个指标，否则数字没有意义。
吞吐量（QPS或RPS）：服务器每秒处理完的请求数。同样的硬件，能扛的QPS越高说明资源利用越高效。
延迟（Latency）：单个请求从发出到收到响应的耗时。关键不是平均值，而是分位数：P50（一半用户的耗时）、P95、P99。平均数会撒谎——999个请求1毫秒加1个请求10秒，平均才10毫秒，但那个10秒的用户早关页面了。长尾才是体验杀手，盯P99。
错误率：压测中失败请求（超时、5xx）占比。错误率开始上升的那个并发点，就是你的服务实际承载上限，比任何QPS数字都诚实。
三者的关系：并发从低往高推，QPS先线性上涨，延迟缓慢爬升；到达某个拐点后QPS涨不动了，延迟开始陡增，错误率冒头——这个拐点就是系统的容量天花板。压测的本质就是找到这个拐点，并且确认拐点位置的延迟在你可接受的范围。
二、准备环境：三条铁律先立好
铁律一：别在生产环境上无脑压。压测本身就是一种自我DDoS，瞬时高并发可能触发商家风控、把同宿主机的邻居打挂（本站超售文章讲过容器架构的邻居效应）、或者让你的防火墙把测试机IP拉黑。生产验证选业务低谷时段，并发从低起步，见好就收。
铁律二：测试机和被测机尽量分离。在服务器本机上压本机（localhost），网络环节被完全跳过，测出来的QPS虚高，只适合排除网络变量做纯应用对比。真实容量评估要从另一台机器走公网压，代价是网络抖动会混入数据——两难时做两轮：本机压看应用上限，远程压看端到端表现。
铁律三：被测服务先预热。首次请求要加载类、建连接、填缓存，冷启动数据会严重拉低成绩。正式计量前先小并发跑一两分钟热身，数据库查询缓存、PHP的OPcache、页面缓存都填充到位再开始记录。
三、ab：五分钟上手的经典款
ab（Apache Bench）是Apache自带的压测工具，Debian系一行装好：apt install apache2-utils -y。
基本用法：
ab -n 10000 -c 100 https://example.com/
参数：-n总请求数10000，-c并发数100。含义：用100个并发线程把10000个请求打完。跑完输出报告，重点看三行：
Requests per second: 850.00 —— 这就是QPS
Time per request: 117.65 ms (mean) —— 单请求平均延迟
Percentage of the requests served within a certain time —— 分位数表，找到99%对应那行
ab的局限也要知道：它是单线程事件模型，自身能打出的压力有限（压不动高性能静态服务），不支持复杂场景，HTTPS下性能进一步打折。所以ab适合快速冒烟测试：“这台机器大概什么水平”，精细测量请上wrk。
四、wrk：现代压测的主力
wrk是多线程的现代压测工具，单机就能打满万级QPS，是当前个人压测的最佳选择。
安装：apt install wrk -y（或从源码编译获取最新版）。
基本用法：
wrk -t4 -c200 -d60s https://example.com/
参数：-t4用4个线程，-c200保持200个并发连接，-d60s持续压60秒。注意c应该大于等于t，连接会均分给线程。
报告解读（示例输出）：
Running 60s test @ https://example.com/
4 threads and 200 connections
Latency 45.62ms 20.11ms 310.05ms
Req/Sec 1.05k 105.32
198432 requests in 60.01s, 85.20MB read
Requests/sec: 3306.15
Latency Distribution
50% 42.11ms
75% 52.30ms
90% 63.87ms
99% 145.29ms
四行关键信息：平均延迟及波动、每线程QPS、总请求数、总分位数分布。这个例子的解读：QPS稳定3300，P50约42毫秒，P99约145毫秒——九成用户50毫秒内拿到响应，最慢的1%也要等145毫秒，对一个动态页面来说健康。
wrk的杀手锏是Lua脚本，能模拟带参数的POST、自定义Header、多URL混合压测。一个最常用的例子：混合压测首页和文章页，权重3比1：
local urls = { {'/', 3}, {'/post/123', 1} }
local sum = 0
for _, u in ipairs(urls) do sum = sum + u[2] end
request = function()
local r = math.random(sum)
local acc = 0
for _, u in ipairs(urls) do
acc = acc + u[2]
if r <= acc then return wrk.format('GET', u[1]) end
end
end
运行：wrk -t4 -c200 -d60s -s mix.lua https://example.com/ 。模拟真实流量结构（首页多、内页少）得出的容量数字，比单URL压测更接近实战。
五、压测的正确姿势：梯度推进
单点压测只给一个孤立的数字，科学做法是梯度扫描，画出完整的容量曲线：
并发50 → 100 → 200 → 400 → 800，每档跑60秒，记录每档的QPS、P99、错误率。你会看到类似这样的演变：
并发50：QPS 1800，P99 35ms，错误0
并发100：QPS 3200，P99 48ms，错误0
并发200：QPS 4100，P99 95ms，错误0
并发400：QPS 4300，P99 480ms，错误0.2%
并发800：QPS 4200，P99 2100ms，错误5%
解读：QPS在并发200到400之间见顶（约4300），这就是容量天花板；并发400时P99已劣化10倍，说明瓶颈开始排队；并发800纯殉葬。结论：这台机器的“舒适承载”是并发200、QPS 4000档，超过就该扩容或优化。把优化前后的梯度曲线摆在一起对比，优化效果一目了然——这就是给性能“算总账”的完整姿势。
六、从数字到瓶颈：压完之后的定位
压测告诉你“有多慢”，不告诉你“为什么慢”。结合服务器侧的实时观测来定位，压测进行时另开SSH盯着：
top 或 htop 看CPU：us高是应用计算瓶颈（PHP、Python的逻辑），sy高是系统调用频繁（频繁小IO），st高是宿主机超售抢你的时间片（本站超售文章详述过）。
free -m 看内存：available持续走低、swap开始活动，内存吃紧，压到极限会OOM。
iostat -x 1 看磁盘：%util接近100、await飙升，磁盘IO瓶颈，数据库重灾区。
ss -s 看连接：连接数暴涨不落，可能是后端处理不过来排队。
典型组合拳：压测时CPU us不高但QPS上不去、磁盘await高——瓶颈在数据库IO，去读本站MySQL调优篇；CPU us打满——应用层瓶颈，查慢逻辑或上缓存；一切正常但延迟高——检查Nginx配置，看是不是本站静态资源篇讲过的没开gzip、没设keepalive。
七、高频翻车点：数字失真的五种情况
压测数字看着漂亮，上线照样崩，多半踩了这几个坑。
坑一：压了缓存页当动态页。WordPress装了页面缓存插件，压首页等于压Nginx发静态文件，QPS虚高一个数量级。想测动态真实容量，带随机query string绕缓存：wrk脚本里给URL拼随机参数。
坑二：keepalive没对齐。wrk默认开长连接，ab默认不开，同一目标两边数字差好几倍不是服务变了，是连接复用策略不同。对比测试务必统一工具统一参数。
坑三：客户端先到极限。测试机自身CPU打满，打不出足够压力，QPS数字实际是“测试机的上限”。wrk多线程下注意观察测试机负载，客户端饱和就换更强的机器或分布式压。
坑四：压测时长太短。30秒内PHP-FPM进程池还没爬满、OPcache没完全命中，数字偏悲观；至少跑60秒再采样。
坑五：忽略日志这个隐形拖油瓶。压测时Nginx每个请求写一条access log，高QPS下磁盘被日志打爆，测出来的是“日志系统的容量”。准确测应用时可以临时关闭access log，正式容量评估则要保留日志（生产环境它就在那，是真实成本的一部分）。
八、k6与进阶路线
工具链再往上还有k6：用JavaScript写测试脚本，原生支持思考时间（模拟真人浏览间隔）、多阶段加压（ramp-up）、阈值断言（P99超过200ms自动判失败）。适合把压测做成CI流水线的一环：每次部署后自动压一轮，性能回退直接卡发布。个人站用wrk足够，项目化协作再上k6，工具为需求服务，别反过来。
结语
性能优化的闭环不是“改完了”，而是“改完并验证了”。给优化前后各跑一轮梯度压测，把QPS和P99摆在一起，提升是真是假、是玄学是工程，一目了然。本站此前的优化文章提供了弹药，这篇提供了靶场：方法论加上工具，你的VPS性能从此有账可算。
