压测不是“用力砸”，而是要科学地找到拐点
服务器能够承受多大的并发量？这是每个站长迟早要遇到的问题。但是很多站长对压测的认识只停留在用工具来模拟几千个请求刷一下，看到响应时间没有爆炸就认为很稳。粗放的压测所得出的结论与不测一样。
真正的压测目的不是为了得到一个漂亮的数字，而是要找到系统从“健康”到“崩溃”之间的一个界限——这就是所谓的性能拐点。知道了拐点在哪里，就可以合理地规划好容量，从容地面对流量的高峰。
一、压测工具的选择
| 工具名称 | 适合场景 | 上手难度 | 分布式支持 |
|---|---|---|---|
| JMeter | HTTP接口、数据库、FTP全协议 | 中等 | 支持 |
| wrk/wrk2 | 超高并发HTTP基准测试 | 较低 | 单机为主 |
| Locust | Python脚本灵活定制场景 | 需编程基础 | 支持 |
| Apache Bench | 快速验证单接口性能 | 极低 | 不支持 |
选型建议：中小站点用JMeter图形化界面就可以搞定大部分场景；追求极致并发量时使用wrk2，单机可以轻松达到几十万QPS；遇到复杂的业务逻辑（比如登录态串联、动态参数等）的时候选择Locust，Python脚本编写起来比JMeter的GUI拖拽要灵活很多。
二、阶梯加压法
不能一步到位，应该一步一步来
一次性打满并发只能得出“系统挂了”的结果，不能得到任何过程中的信息。正确的做法就是阶梯式加压：
1：50并发 → 运行3分钟，记录基准数据
2：100个并发 → 运行3分钟，比较响应时间的增长
3：200并发 → 运行3分钟，查看错误率
4：为500并发，运行5分钟后找拐点
5：1000并发 → 直到系统性能下降或者崩溃
在每一个台阶上留30秒钟的时间，使服务器资源得到一定的释放。这样“逐步收紧”的方法可以画出完整的性能曲线，而不只是孤立的一个峰值数字。
加压参数的设置方法
- Ramp-up时间：不能马上全部打开，应该按照阶梯的20%来逐渐增加线程
- 思考时间（Think Time）：模拟真实用户操作间隔，通常设为1-3秒随机值
- 超时设置：连接超时5秒，响应超时10秒，防止大量的挂起请求把压测机给拖垮
- 断言规则：除了查看HTTP状态码为200之外，还需要验证响应体中的关键字段是否正确
三、核心指标和拐点判断
要监控的四个方面
1. 响应时间（RT）
P50、P95、P99三个分位值。P50表示一半用户的体验，P95表示大多数用户，P99表示长尾延迟。当P99在500并发下飙到5秒以上的时候，就说明系统已经出现了严重的排队等待现象。
2. 吞吐量（TPS/QPS）
每秒事务数或者请求数。当吞吐量曲线由线性增长转为平缓时，该点即为系统吞吐量极限。继续对系统施加压力，TPS不增反而下降，这是典型的过载现象。
3. 错误率
如果超过0.1%，就应该引起重视，如果超过了1%，就说明系统正在实质上丢弃请求了。常见的原因有：连接池用尽、数据库锁等待超时、Nginx worker_connections达到最大值。
4. 服务器资源
CPU利用率达到80%就达到了一个心理上的界限——超过这个数值就要考虑扩容了。内存要看available而不是free，free接近零但是available充足不代表内存不足。磁盘IO等待时间（iowait）超过20%，说明存储已经成了瓶颈。网络带宽可以用iftop或者nload来实时监控，不要让千兆网卡成为天花板。
拐点判断的“三看法则”
看曲线形状：RT曲线由平缓变成陡直，TPS曲线由上升变为走平，交叉的地方就是拐点。
看资源瓶颈：CPU打满或者iowait很高，表示硬件已经到达极限。
错误出现：错误率由0直接跳到一个不为0的值上，就是系统抗压能力的最明显标志。
四、承载能力换算和留有余地
压测得到的极限值不能作为容量规划的依据。以800并发时的系统变差为例，那么实际承载能力的计算方式就是：
安全承载能力=拐点并发数×0.7(安全系数)×0.8(冗余系数)=约450并发
0.7的安全系数是为流量波动留有的空间，0.8的冗余系数则用于突发流量以及运维操作时预留buffer。实际的容量规划还应该考虑业务峰值的具体数值——日常峰值只有200并发的话，450的安全线绰绰有余；而活动期间峰值预计达到800并发的时候，则要提前做好负载均衡扩容。
常见的容量瓶颈以及解决办法
- 数据库瓶颈：慢查询是第一杀手，用EXPLAIN逐个进行剖析，需要加索引就加索引，需要分表就分表
- 连接池太小了：MySQL的max_connections、PHP-FPM的pm.max_children、Redis的maxclients都应该根据并发量来设置
- 带宽不足：将静态资源通过CDN进行加速，对图片进行WebP压缩，单个页面的大小控制在2MB以内
- 缓存命中率不高：热点数据先预热到Redis中，在本地再增加一层OPcache
五、压测注意事项和避坑指南
压测机不能成为瓶颈。用一台2核4G的机器去测试目标服务器，一般的结果是压测机先受不了。分布式压测的时候，多台压测机的总并发能力应该明显大于目标系统的预期承载量，还要对压测机自身的CPU和网络情况进行监控。
不能在生产环境中直接压。压测产生的流量可能会触发WAF规则、打爆CDN回源带宽，甚至会被运营商误认为是DDoS攻击。测试环境要尽量和实际的配置一样，如果必须要在生产环境下进行压测的话，则应该选择凌晨低峰时段，提前通知相关人员，准备好秒级回滚方案。
业务的“隐性并发”问题。用户数量不等于并发量。一个每天UV达到10万次的网站，在高峰期的实际并发可能只有几百人。可以使用以下公式来粗略估算：并发数≈日均PV/（日活跃秒数×页面平均加载时间）更精确的数据需要通过埋点或者日志分析来获得。
压测的目的不是为了得到一个好看的数据，而是要弄清楚系统在哪一个环节最先崩溃。每次压测之后都要输出瓶颈分析报告，把TOP3的性能问题和优化方案列出来，这才是对以后的架构演进真正有用的东西。