上线前先压一遍：给网站做压力自测

上线之前用接近真实的流量形状压一遍，很多只有高峰期才暴露的问题能提前翻出来。压测不求精确复现线上流量，求的是找到系统的第一块短板。 一、压测看四个数 响应时间看 P95 和 P99（即 95%、99% 的请求快于多少毫秒），吞吐看 QPS，稳定性看错误率，资源看 CPU、内存、磁盘 IO。四个数要放在一起读：QPS 上不去但 CPU 很闲，瓶颈多半在数据库或锁上；错误率开始爬升的那个压力点，就是当前的容量上限。P95 和 P99 的差距能看出长尾：平均值合格但 P99 超过一秒，说明有一部分请求卡在慢路径上，平均值会掩盖问题。 二、逐步加压 别一上来就打满，从预估日常流量的五成开始，每轮翻倍。常用工具两选一： ab -n 2000 -c 50 http://test.example.com/ wrk -t4 -c100 -d60s http://test.example.com/ ab 简单直接，适合快速验证；wrk 多线程，能压出更高的并发。每轮记录 P95 和错误率，画出压力与响应时间的曲线，拐点位置比绝对数值更有意义。涉及写数据的接口压测时另建测试库，别把压力打到生产数据上。 三、定位瓶颈在哪一层 加压的同时在服务器上观察：top 看 CPU，free -h 看内存，iostat 看磁盘；数据库层用 show processlist 看堆积的查询，慢查询日志开着对照。观察要按秒级刷新，压测高峰几分钟就过，肉眼盯 top 容易错过峰值。nginx 访问日志里把慢请求单独统计一下，能看出是哪类接口拖后腿。典型现象是应用 CPU 不高但 QPS 卡死，十有八九是数据库连接池打满或慢查询锁表，连接池大小的默认值往往偏低，报等待超时先查这里。 四、两条边界 压测优先针对测试环境；确实只能压生产时，选业务低峰、小流量验证，并提前准备好回滚步骤。压力端自己也会成为瓶颈：测试机的带宽和 CPU 先撑不住时，读数就失真了。压测结果留档，日期、参数、结果三列记下，下次扩容时有历史基线可比。