凌晨一点，某电商群突然炸了。
运营说大促页面转圈，研发说数据库CPU打满，测试说上周压过，没问题啊。后来一查，压测只跑了下单接口。优惠券核销、库存扣减、积分抵扣，全没串起来。接口单测像体检只量身高，真上场就喘。
压测到底在压什么
很多人把性能压测当成JMeter跑个脚本。不对。脚本只是扳手，你得知道拧哪颗螺丝。
核心看四样：吞吐量、响应时间、错误率、资源水位。吞吐量不是TPS一个数，得看业务混合比例。响应时间也别只看平均，P99能把人吓醒。错误率更阴，有些系统超时后返回空对象，前端不报错，用户看到的却是白屏。
我见过一个团队，压测报告写着TPS 8000，漂亮。上线后库存扣减重复，订单多卖三十单。为什么？压测数据里商品ID就一个，缓存命中率接近百分百。真实流量一来，缓存被打散，数据库直接跪。所以，压测目标要跟业务损失对齐，不是跟工具指标对齐。
先定业务模型再写脚本
流量模型怎么来？拍脑袋不行。
拉最近三十天日志。看峰值QPS，看用户行为漏斗。首页到详情页，详情页到下单，下单到支付，每一步转化率多少。再叠加活动倍数。大促不是线性翻倍，可能是尖刺。零点一波，十点一波，直播间再一波。
数据构造也麻烦。生产数据不能直接导，脱敏又容易把关联关系弄断。可以用影子库或者流量染色。染色就是给压测请求打标，让中间件知道这是测试流量，写进影子表，不污染真实数据。
链路长的时候，单压一个服务没意义。A调用B，B调用C，C查缓存。你压A，B和C在摸鱼。要压就压全链路，从网关到缓存到数据库。中间任何一段超时，前面的TPS都是假的。
环境数据和监控三件套
压测环境跟生产差多少？差很多。
机器配置低一档，网络带宽少一半，数据库参数没调，中间件版本还不一样。这种环境压出来的结果，只能证明脚本能跑通。要准，至少核心链路对齐生产。对不齐就承认误差，别拿数字忽悠老板。
数据量也要对齐。一张表生产五千万行，测试库五千行，索引随便建都飞快。上生产，慢SQL一出现，全链路堵死。
监控得提前布。应用层看APM，JVM看GC日志和线程池，中间件看连接数、队列积压，系统层看CPU、内存、磁盘IO、网络。压测时最好开着火焰图，瓶颈一冒头就抓。别等压完了再翻日志，那时候现场早凉了。
还有限流和降级。压测要验证这些开关是不是真能救命。阈值设错，等于没设。熔断一触发，整个链路雪崩，这种事故我见过不止一次。
那些把人带沟里的误区
并发数不等于QPS。并发是同时干活的用户数，QPS是每秒完成的请求数。业务响应时间一长，并发再高，QPS也上不去。所以调并发，不如先看响应时间卡在哪。
压测通过不等于高枕无忧。系统有预热，缓存有冷热，数据库连接池有慢启动。压测前不预热，前几分钟数据难看，后几分钟好看。报告只截好看那段，这不叫压测，叫美颜。
只压不观察，等于白压。压测时盯着监控，像开车看仪表盘。水温高了不停车，发动机迟早冒烟。
一份能落地的行动清单
别搞太复杂。小团队也能做全链路压测，只是范围收窄。
- 定目标：这次压测解决哪个风险？容量评估，还是瓶颈定位？写下来。
- 建模型：用生产日志算峰值QPS和混合比例，别自己编。
- 备数据：影子库、脱敏、流量染色，至少选一条路。
- 对齐环境：核心链路配置尽量贴近生产，差哪儿标哪儿。
- 布监控：APM、GC、慢SQL、中间件队列、系统资源，一个别少。
- 设阈值：超时、错误率、水位线，触发就停，别硬扛。
- 做演练：限流、降级、熔断，拉出来遛遛。
- 复盘：瓶颈是什么，改了什么，下次什么时候再压。
性能压测从来不是测试一个人的夜班。它是研发、运维、DBA、业务一起排雷。上线前多流点汗，总比上线后被人@到天亮强。
真的。别等用户先发现你的数据库扛不住。