性能压测别被漂亮报表骗了

上周三晚上十一点半，部门群的消息弹得手机震个不停。运营说大促的预约链接点进去要转八秒的圈，技术侧的值班同学说上周刚做完全链路压测，报告写的清清楚楚系统能扛三万QPS，不可能崩。我盯着监控面板上飘成一片红的线程池排队指标，刚泡的大麦茶凉透了都没察觉。 真的，谁没在压测这事上踩过坑。

压测报告里藏了多少自欺欺人

太多团队的压测，从一开始就走偏了。 压测环境的配置和生产差三倍，压测前把缓存预热拉到命中率100%，数据库连接池开到机器能承受的最大值，甚至把应用的访问日志、错误日志全关掉，就为了让跑出来的QPS数字好看。最后报告做的花里胡哨，折线图整整齐齐，汇报的时候拍着胸脯说系统绝对能扛住峰值。别信。结果一上生产，用户带着各种奇奇怪怪的请求进来，缓存命中率掉一半，日志刷满磁盘IO，不到五分钟系统就卡成PPT。

说实话我见过最离谱的一次，某团队为了压出好看的数字，把生产的核心业务逻辑临时改成了空返回，压测完再改回来。最后上线的时候峰值到八千QPS直接全站崩，复盘的时候才发现，压测的代码和线上跑的根本不是一回事。 压测的核心从来不是跑出最高的QPS数字，而是还原真实生产环境的运行状态。如果压测的时候所有条件都开了最优buff，那跑出来的数字没有任何参考价值——总不能让真实用户也帮你把缓存拉满，把日志关了吧？

别拿实验室流量当真实用户

还有个常见的误区，就是压测的流量模型太假。 很多团队做压测，就是拿几个核心接口，用固定的参数循环打。比如登录接口，就一直拿那几个测试账号重复调用，根本不管真实用户的操作路径。真实用户哪有这么规整的？有刷半小时商品列表不买的，有加了十件购物车又删掉的，有输错三次密码被锁定的，还有提交订单的时候余额不足触发异常分支的。这些分支的代码路径，在你那种规整的压测流量里根本碰不到，真上线的时候，这些没被压到的分支往往就是拖垮整个系统的罪魁祸首。真的差很多。 之前我们团队踩过这个坑。最开始压测的时候就只打商品详情和下单两个接口，跑出来的QPS挺高，结果第一次模拟真实用户路径的时候，把从首页浏览、列表筛选、详情查看、加购、改地址、结算的整个跳转链路按真实比例模拟出来，QPS直接从三万掉到一万二。

对吧？那个虚高的三万QPS，说白了就是实验室里的数字，离真实的生产场景差了十万八千里。后来我们干脆把生产环境七天的真实流量录下来，按时间切片分配到压测流量里，甚至把用户的操作间隔、参数分布都还原，跑出来的一万二QPS，才是真的能扛的数。

压测完的优化才是真的难

很多团队觉得压测完，把报告往群里一发就算完事了。 哪有这么简单。压测跑出来一堆问题，慢查询占了60%的响应时间，连接池参数配的不合理，线程池排队超过阈值，这些问题不跟进优化，压测就是走个过场。 上次我们压测完列了二十三个性能问题，有要改代码的，有要加索引的，有要调整参数的。我们没搞什么大而全的整改计划，就按影响程度排优先级，先把占了最大头的两个慢查询加了索引，把日志的同步写改成异步批量刷盘。就这两个小改动，整体接口的响应时间直接降了40%。剩下的那些影响不大的小问题，跟着日常迭代慢慢改就行。 别总想着一次压测就把所有性能问题都解决。哪有那么容易？ 压测的价值从来不是那张打印出来的精美报告，而是在上线前把所有可能炸的坑提前踩一遍。真等大促当天系统崩了，再回头说之前压测过没问题，谁信啊。 上次压测完，我们团队三个小伙子在机房门口的大排档吃龙虾，算着剩下的优化项，喝了三瓶冰啤酒，就等着大促当天不报警。最后那天峰值扛了一万五的QPS，监控曲线平的像直线，那种爽感，比拿了季度奖还舒服。