上周帮南京河西的一个做本地生活的团队救火。大促当天支付接口雪崩，10分钟内挂了三次，客服电话被用户打爆，运营的优惠券刚发出去，就有一半人用不了。之前他们给我看的压测报告全绿，什么QPS扛到6000，平均响应时间180ms，完全符合上线标准。我当时刚喝完半碗鸭血粉丝汤，看到报告直接皱起眉头。
压测报告里的绿，可能是假的
我翻了下他们的压测脚本，差点把手里的冰美式泼在键盘上。
他们压测的时候，把所有下游依赖——支付网关、用户中心、优惠券服务——全mock成了固定1ms返回的接口。甚至连数据库，都提前用脚本把所有要查的商品数据提前灌进了Redis，缓存命中率直接拉到100%。
这哪是压测啊？这是给自己做了个全是满分的模拟考。
更离谱的是，他们的压测报告里只放了平均响应时间，99分位响应时间的列直接被藏在了报告最末尾的附录里，我翻到的时候才看到，QPS到5000的时候，99分位响应时间已经飙到了3s，早就超过了用户能容忍的阈值。
说实话，很多团队做压测的时候，为了拿到好看的数字，会不自觉地给环境”开小灶”：压测环境的机器配置比生产高，压测的时候把其他无关的业务流量全停了，甚至故意把压测的并发量卡到刚好能达标的数值。这种报告除了能给领导交差，半毛钱用没有。
别拿单机压测的结果套集群
之前碰到过一个做电商的团队，觉得压测只要测单台应用机器的性能就行。单台机器压到1200QPS的时候CPU才70%，他们拍板说10台机器就能扛1.2万QPS，完全能扛住大促的流量。
结果大促当天，流量刚到8000QPS，数据库直接挂了。
原因很简单：每台应用机器开的数据库连接池是50个，10台就是500个，而生产数据库的最大连接数才设的300。连接被打满之后，所有的请求都在排队等连接，整个系统直接卡死。
单机压测测出来的只是应用本身的代码性能，根本测不出来集群里的网络开销、服务发现的延迟、数据库连接数的瓶颈，甚至连负载均衡的转发损耗都测不到。你要是真的拿单机的结果去线性推算集群的容量，迟早要踩大坑。
我见过太多团队，压测的时候只盯着应用服务器的CPU使用率看，觉得CPU没到80%就没问题，根本不管数据库的慢查询、Redis的命中率、消息队列的堆积。等真的上线出问题了，才发现瓶颈根本不在应用层。
真正有用的压测，要和真实流量对齐
那到底什么样的压测才是有用的？
别再自己写那种每秒均匀发固定请求的压测脚本了。你压的请求参数，和真实用户的参数分布根本不一样。比如之前那个本地生活的团队，他们的压测脚本里，所有请求都是查同一个热门的火锅套餐，结果压测的时候缓存命中率100%，上线的时候用户的请求五花八门：有查自己三个月前的订单的，有搜冷门的奶茶店的，还有不停刷新优惠券页面的，缓存命中率直接掉到30%，数据库的查询量直接翻了十倍。
现在业内常用的方法是流量镜像，就是把生产环境的真实流量复制一份，导到压测环境里，压测用的参数、请求的分布、甚至用户的行为习惯，全和生产一模一样。这样测出来的结果，才是真的能反映生产的性能。
还有个很多人忽略的点：压测的时候一定要测突发峰值的场景。真实的用户流量根本不是均匀的，比如大促刚开始的那一分钟，流量会在几秒内翻三倍，你要是用恒定并发的压测脚本，根本测不出来这种突发流量下，服务会不会出现抖动。
上次帮那个本地生活的团队重新做压测，用流量镜像回放了去年大促的真实流量，才发现他们的优惠券接口，在QPS到800的时候就会出现慢查询——因为优惠券表的用户ID字段没建索引，之前的压测根本没压到这个接口，全压的商品查询，所以才没发现这个问题。
别把压测当成上线前走个过场的流程。
它是你上线前最后一次，用最低的成本找系统bug的机会。
我上周在南京软件大道的咖啡馆里，还碰到个刚毕业的小伙子，跟我说他们公司压测就是走个过场。真的，别等上线崩了才后悔，压测的时候多花点时间，比你半夜爬起来救火强一百倍。