说出来好笑，他们压测的时候接口QPS稳在1200，上线刚十分钟就直接打到800的阈值触发熔断，客服后台直接被挤爆。
场景拍脑袋等于白测
刚进场的时候我翻了他们的压测脚本，第一反应是这根本不是压测，是给服务器做体能测试。
所有核心接口的压测QPS，全是拍脑袋定的数：首页接口拉到1000，商品详情拉到1000，下单接口拉到1000，连支付回调的接口都按1000的QPS打。完全不管真实世界里，用户在每个环节的分布比例是什么样的。
真实的用户行为从来不是平均分布的。生鲜类APP的用户，大概70%的人打开APP就停在首页刷推荐，只有20%的人会点进分类页，10%的人会主动搜商品，最后能走到结算付款环节的，连3%都不到。按他们之前的脚本，相当于把下单接口的流量放大了几十倍，压出来的结果自然和真实情况脱节。
还有个细节更离谱。他们的压测脚本里，用户从加购到提交订单的间隔设成了0秒。相当于没有用户在结算页停留，没有填地址选优惠券的过程，所有请求像疯了一样往数据库冲。之前测出来的数据库连接池耗尽的问题，上线后根本没出现——真实用户在结算页平均要待四十多秒，足够把之前攒的请求慢慢处理完。
太坑了。
假数据比没数据更可怕
聊完场景再看他们的测试数据，我当时差点把咖啡喷在屏幕上。
所有测试用户的收货地址全在同一个写字楼，所有商品的库存都是整整齐齐的10000件，所有搜索关键词全是“生鲜”两个字。压测的时候搜索引擎的索引命中率100%，连一次缓存穿透都没触发过。结果上线后，一堆用户搜“10斤装8424西瓜”“散养土鸡蛋30枚”这种长尾词，直接把搜索服务的响应时间从200ms拉到了2s。
之前的压测里，订单金额全是固定的50块，促销计算接口的分支逻辑——满减叠加、会员折扣、限时优惠券——根本跑不到，等于压了个寂寞。
后来我们重构数据构造逻辑的时候，先从生产环境导了过去三个月的全量脱敏数据，把搜索词拆成高频、中频、长尾三个层级，占比严格按照真实用户的搜索分布来；把订单金额从9.9的凑单小菜到399的整箱车厘子，按实际的成交占比生成；甚至连库存数，都专门加了一批剩3件、5件的临界值商品，把库存扣减的并发场景覆盖到。
压测用的数据，最忌讳“看起来很真，实际全是凑数的”。你以为插了十万条用户数据就算完事，要是这些数据的分布和生产环境差十万八千里，跑出来的性能结果，连给团队做参考的价值都没有。更别提有些团队为了图省事，所有测试数据都用同一段字符串生成，把数据库的索引命中率拉到100%，压出来的TPS高得吓人，上线后一碰到真实的复杂查询，直接卡成PPT。
别把压测搞成一次性表演
很多团队对压测的认知，还停留在“大促前花一周时间，把脚本写完跑一遍，出个报告就完事”。下次大促来了，再把之前的脚本翻出来改改，甚至重新写一遍。
太浪费了。
我们后来帮这个生鲜团队把压测的场景和数据构造逻辑拆成了可复用的模块，每次发版迭代的时候，只要把核心链路的压测跑一遍就行。比如新上了一个满减叠加的规则，只要在数据构造层把对应的规则参数加进去，不用重新造全量的测试数据。碰到大促前，再把流量模型往上调两倍，很快就能跑完全链路压测。
说实话，见过太多团队为了过项目验收，压测的时候专门挑性能最好的机器跑，把报告做的漂漂亮亮的，真到上线露馅的时候，擦屁股的成本是写压测脚本的十倍都不止。
当然也得提个醒。数据构造的底线是绝对合规，用户的手机号、真实姓名、详细收货地址，这些敏感信息必须做全量模糊处理，不能因为压测把数据安全搞出问题。还有压测的时候一定要做好流量染色和隔离，别把生产环境的真实用户请求给挤掉了——之前有朋友压测没做隔离，把真实用户的订单请求给覆盖了，赔出去的优惠券比他们写压测脚本的预算还高。
真的不值。