他们公司筹备了三个月的618大促，压测整整做了三轮，每轮报告都写得漂漂亮亮，说系统能稳扛2000并发。结果开抢10分钟，支付接口超时率直接飙到40%，整个订单链路瘫了一半。
同事在电话里拍着大腿骂，说我们明明压测的时候稳得一批啊，怎么上线就崩？
压测的第一坑：把并发数当唯一KPI
说实话，我见过太多团队的压测报告，上来第一行就是“本次压测支撑最高并发12000”，看着特别唬人，真到大促的时候该崩还是崩。
问题出在哪？根本没模拟真实的用户行为。
真实用户逛电商是什么样？刷商品页30秒，翻两三条评价，犹豫两分钟，点加购，可能还要切出去看个朋友圈，隔半小时才回来点支付。但压测脚本呢？写的是无限循环调用支付接口，没有任何浏览间隔，所有请求参数都是固定的爆款商品ID，连用户token都是批量刷出来的固定值。
这种压测跑出来的结果有啥用？缓存命中率能冲到100%，数据库根本碰不到磁盘，连接池永远是空闲状态。但真实流量进来的时候，用户搜的是各种长尾商品，翻的是不同店铺的详情页，缓存根本打不中，数据库连接池瞬间就被打满。
上次那个同事的问题就在这。他们压测的时候，所有请求都命中了热点商品的本地缓存，单台应用服务器的CPU使用率才30%。等真实大促流量进来，一半的请求都要去数据库查库存，连接池的上限直接被打穿，请求排队排到超时。
真的。别不信。
别在生产环境裸跑压测
很多人觉得压测结果不准，是因为测试环境配置和生产不一样，干脆直接半夜偷偷在生产环境跑压测脚本。
见过最离谱的一个团队，半夜12点在生产跑压测，没做任何流量隔离，直接把正常用户的请求给挤掉了。第二天早高峰发现数据库主从同步延迟了3小时，差点把前一天的订单数据搞丢。
不过话说回来，也不是说完全不能在生产环境做压测。很多中小团队根本拿不出和生产同配置的测试环境，压出来的结果根本没参考价值。这时候核心要做好的是流量隔离。
简单说就是给所有压测请求打个专属标识，从网关到应用，再到下游的数据库、MQ、缓存，所有组件都能识别出这是压测流量，直接路由到专门的压测库和压测消息队列，绝对不能碰真实的用户数据。
之前帮一个零售团队做压测的时候，就漏了给MQ的消息打标。结果压测产生的10万条模拟订单，直接进了真实的用户通知队列，给一万多正常用户发了“您的订单已支付”的假短信。最后赔了快两万的优惠券才把事儿平了。
现在想起来还后背发凉——当时要是再多压半小时，估计要把用户的真实账户余额都给扣错了。
压测不是为了找最高数字
很多团队压测完，就报一个“系统最大能扛5000QPS”的数字，整理成PPT给老板汇报，就完事了。
根本没人去拆解，这个5000QPS的瓶颈到底在哪。
是应用服务器的CPU到了80%就上不去了？还是数据库的慢查询拖了整体延迟？还是下游接的第三方支付接口本身就只能扛2000QPS，你自己系统再怎么优化也没用？
之前测一个内容推荐系统，压测到3000QPS的时候，接口延迟从50ms涨到了2s。一开始大家都以为是应用层的问题，调了半天线程池大小，改了半天垃圾回收参数，一点用都没有。最后扒了半小时的监控曲线才发现，是推荐模型的特征查询接口，每次都要去Redis拉300个用户特征，那个大key把Redis的入带宽直接占满了。
后来把大key拆成10个小对象，同样的硬件配置下，接口延迟直接降回60ms，能扛的QPS从3000涨到了8000。
你说这事儿闹的。之前为了扛流量，花了十万多扩容服务器，结果问题出在一个没人注意的Redis大key上。
最后说几个真的能落地的小事，别搞那些虚头巴脑的。
压测前先扒3个月的真实访问日志，把流量的波峰波谷、参数分布、用户行为间隔算明白，别上来就写固定参数的循环脚本。压测的时候别光盯着QPS数字跳，要同时盯着应用、数据库、中间件的各项指标，哪个组件先到瓶颈就记哪个。压测完别把报告扔在共享文件夹就完事，把找到的瓶颈列成整改项，排到下一个迭代的排期里，下次压测先验证之前的问题有没有真的解决。
哦对，还有。压测的时候别选工作日的半夜跑，万一脚本写炸了，第二天早上被用户骂的还是你自己。