性能压测别搞成上线前的自我安慰

去年618前在南京软件谷蹭朋友的冰美式，刚坐进会议室就撞见一屋子人盯着监控屏皱眉头。他们团队前前后后跑了三轮回压测，报告里明明白白写着系统能扛2倍峰值流量，结果预演时流量刚爬到日常的1.5倍，支付链路直接卡死，超时请求堆了上千条。 没人好意思说，之前的压测从一开始就走偏了。

压测的流量模型从根上就错了

他们之前的压测逻辑简单到离谱：把生产日志里的接口调用次数拉出来算个平均值，按平均值的1.2倍打均匀流量，跑满10分钟没报错就算通过。 这哪是压真实用户？ 真实大促的流量从来不是平的。用户点进首页可能刷3轮商品列表，蹲5分钟等优惠券刷新，看到满减提示的10秒内，会有近两成的人直接跳去结算页。你拿均匀的、没有行为逻辑的流量打上去，跟真实场景差了十万八千里。更别说很多团队压测时默认CDN缓存命中率100%，数据库没有慢查询，日志里的报错全当看不见——这种环境里跑出来的结果，除了能在汇报PPT上凑个好看的数字，半毛钱用都没有。

很多小团队总觉得自己没预算搞复杂的流量模拟，其实根本不用。把过去3个月生产上的真实调用链路串起来，按用户的操作顺序排好比例，哪怕用最朴素的脚本打流量，都比你对着理想模型算出来的峰值靠谱。

别只盯着响应时间那几个数字

我见过太多团队的压测报告，通篇只列两个数：平均响应时间、峰值QPS。只要响应时间压到200ms以内，QPS够到预设值，所有人就拍胸脯说系统稳了。 稳个鬼。 压测的时候，应用服务器的CPU是不是在85%的水位上飘了20分钟没降下来？数据库的连接池是不是已经被占满，后面的请求全在队列里排队？日志里是不是每隔3秒就冒一个Redis连接超时的warn，大家自动滑过去当没看见？ 上次碰到最离谱的一次，某团队压测报告写着系统峰值QPS能到1200，翻监控才发现，QPS刚到800的时候，网关的错误率已经冲到1.2%。这1.2%的错误率放到真实用户场景里，就是每100个点支付的人里，有1个会碰到重复扣款，或者付了钱看不到订单。 真正要看的从来不是那几个凑数的指标。是全链路的资源水位，是错误率出现明显抬升的拐点，是流量撤掉之后，系统能不能在3分钟内回到正常服务状态——毕竟真实的流量从来不会一直顶在峰值，潮起潮落的间隙，系统能不能缓过来，才是决定会不会出线上事故的关键。

压测出问题别转头就忘

很多团队压测完的流程，就是开俩小时会，把发现的问题列个共享文档，然后散会。至于文档里的问题有没有人改，什么时候改，改完有没有验证，没人盯。 还是开头说的那个朋友的团队，当时压测发现支付接口的数据库索引建错了，每次请求都要扫全表，单接口响应时间跑到800ms。会上拍板说下周改，结果开发忙着做新的弹窗活动，转头就把这事忘了。直到预演时支付链路崩了，才拍着大腿想起这个漏网的问题。就一个10分钟就能改完的索引，因为没人盯，差点搞砸整个大促。 压测不是考完试交卷就完事。每个发现的问题，必须写清楚谁来改、多久改完、改完要达到什么标准。比如那个索引问题，责任人是负责支付模块的开发，当天下班前改完，改完之后跑10分钟的单接口压测，确认接口响应时间降到50ms以内，才算闭环。 说实话，工具真的不重要。你哪怕花几万块买最贵的商业压测平台，流量模型是假的，问题整改没人盯，压出来的结果全是自欺欺人。反过来讲，你哪怕用最朴素的开源工具，把真实场景摸透，把每个漏出来的问题堵上，比啥都强。 前几天跟那个朋友聊天，他们今年618的压测，没有一上来就跑全链路，先花了3天把过去一年所有的线上故障都拉出来，每个故障点都专门打流量验证。最后大促当天，系统扛了平时3倍的流量，整体错误率才0.1%。 他说现在再也不把压测当上线前的例行公事了。 毕竟你压测时偷的懒，上线当天，用户会一笔一笔跟你算清楚的。