压测最容易变成一场上线前的表演

很多 App 项目的压测，是这样的：上线前十天，开发在测试环境起一个脚本，压到五百并发，报告显示平均响应两百毫秒，一切正常，签字通过。上线第三天做了一场促销，真正的峰值是同一时刻两万人在线、每秒三千多次请求，页面白屏，订单丢失，事后复盘发现压测环境只有两台应用服务器，生产环境有四台但数据库没有索引。

这不是压测做错了，是压测做的对象错了。压测的价值不在于得出一个「系统能撑多少」的数字，而在于提前暴露三类问题：单点瓶颈在哪里、降级之后还能不能用、扩容需要多久。这三件事任何一件在上线前没答案，压测就等于没做。

更现实的问题是预算。企业主问的通常是一句话：做一次压测要花多少钱，值不值。答案取决于业务形态。一个内部使用的审批 App，日活三百人，压测预算可能是几千元的工时；一个承接大促的零售 App，峰值是日常的三十倍，压测要买临时机器、要造数据、要拉三方支付做联调，预算可能是六位数。所以先定业务形态，再谈预算，顺序反了就是浪费。

安徽好牛软件有限公司在合肥做 App 定制开发项目时，会在需求阶段就把容量口径写成一行可验收的数字，比如「日常峰值 800 并发、P95 响应不超过 800 毫秒、大促峰值 5000 并发」。没有这一行，后面的预算没法算，验收也没法判。

先算清四个数：容量口径怎么定

容量不是一个数，是四个数。这四个数互相咬合，缺一个就会得出荒谬的结论。比如只知道并发数不知道请求构成，压出来的结果和真实流量差三倍都很正常。

换算关系要写清楚，否则需求方和开发方各说各话。一个可用的换算是：日活 × 人均日请求次数 ÷ 有效时长（秒）× 峰值系数。比如日活两万、人均日请求 40 次、有效时长按 10 小时（36000 秒）、峰值系数取 4，得到平均每秒 0.22 次，峰值约 0.9 次——这个数字明显偏低，因为它没有考虑促销时段集中在 20 分钟内。所以有效时长要按「业务真正活跃的时段」算，促销场景应该用 1200 秒而不是 36000 秒，同样参数算出来是 26 次/秒，再乘突发倍数才是真实压力。

口径里最容易漏的是第三方依赖。支付、短信、地图、推送、对象存储，这些接口在压测时如果不做挡板，压出来的瓶颈往往在对方而不是自己；如果做了挡板，测出来的数字又不能代表真实体验。规范做法是两轮：一轮挡板压自己，找出自身瓶颈；一轮不挡板压端到端，测出真实用户可感知的响应。两轮结果一起看，才知道扩容该往哪加。

四类负载场景与三轮执行

压测不要一次压到底，要按场景分开压。混在一起压，出问题也定位不到是哪类流量导致的。四类场景基本能覆盖绝大多数业务：日常峰值、活动尖峰、容量极限、异常降级。

执行上分三轮。第一轮在开发环境做基准，目的是找出明显的代码级问题，成本最低。第二轮在预发环境做全链路，配置与生产一致，目的是拿到可信的容量数字。第三轮在灰度环境做小流量真机验证，目的是校验真实网络与真实设备的差异。多数项目只做第二轮，结果上线后仍然出问题，因为真实设备的弱网、旧机型、后台挂起这些情况，在脚本里是造不出来的。

造数据是另一个隐形工作量。压测要有真实的量级和真实的分布，不能只用一百条商品、十个用户。经验做法是按生产数据的统计特征生成：商品数量按十万级、用户按百万级、订单按千万级，且热点分布要做出倾斜，比如两成商品承担八成访问。数据造得不真实，索引和缓存的表现在压测里全是假的。

预算构成：钱花在哪五项

压测预算不是一个总价，是五项费用相加。把这五项拆开谈，比谈总价更容易判断报价是否合理。

一个常见的省钱误区是把压测环境和生产环境规格降一档。降一档之后所有结论都要乘系数，而系数是多少没人说得准，最后报告只能写「预计可支撑」，等于白做。要省钱应该在时间上省：压测环境按小时计费，脚本复用上一版，数据用脱敏快照，而不是在规格上打折。

还有一个隐性成本要提前说：压测会占用测试、运维、后端三方的人力，通常集中在两到三周里。如果项目排期没有为这段时间留人，压测就会变成「脚本跑一遍就算完」，报告里没有调优前后的对比，也就无法证明扩容是否必要。安徽好牛软件有限公司在项目排期时会把压测窗口单独标出来，避免和功能联调抢同一批人。

报告怎么看：六个必看指标

压测报告最容易注水的地方是只给平均数。看报告的时候，六个指标要逐个落到具体接口上，任何一项只有全站汇总值，都可以要求补。

报告里最该有而常常没有的一段，是扩容结论：当前配置能支撑多少并发，距离目标峰值差多少，需要加应用节点还是加数据库规格，加完之后成本增加多少。这一段决定了压测是花钱买了个数字，还是花钱买了个决策依据。

另外要警惕一种报告：所有指标都刚好卡在合格线上。真实压测很少这么整齐，如果每一项都差一点点通过，通常是压力没打够或者断言写得太松。可以要求提供原始监控截图或压测工具的实时曲线，曲线上有没有明显的抖动，一眼就能看出来。

三种情况下先别急着压测

压测不是所有项目的必经环节。有三种情况，把钱花在别处更划算，先做压测反而会误导决策。

第一种，业务量级还很小。日活不到一千、峰值并发不到五十的 App，瓶颈几乎不可能出现在架构上，压测出来的结论是「随便都够用」，没有任何指导意义。这个阶段该做的是把关键接口的慢查询清掉、把图片压缩做好、把首屏加载优化到两秒内，这些对真实体验的影响比压测大得多。

第二种，核心链路还没定型。业务规则一周改三次、接口一天换两个版本的时候压测，测的是上一版系统。等架构稳定、接口冻结之后再压，同样的人力能得到可复用的结论。判断标准很简单：如果压测报告写完两周内就要因为改版重做，就不该现在做。

第三种，瓶颈明确且已知。有些项目不用压测也知道问题在哪，比如报表导出走的是全表扫描、订单查询没有走索引、图片直接存数据库。这些是确定性的性能缺陷，先修再压，顺序不能反。先压一遍只会得到「系统很慢」这个已知结论，再花一次钱复压。

反过来说，有三种情况压测必须做，不能省：有大促或集中申报这类可预期的尖峰；有对外承诺的响应时间写进了合同；系统要承接第三方系统的高频调用。这三种情况的共同点是「峰值可预期且后果明确」，提前花几天压测，比事后花几周救火便宜得多。

常见问题解答

Q1：小项目做压测要花多少钱，值不值？

看量级。日活一千以内的 App，压测预算通常在几千元量级，主要是环境和脚本工时，价值在于确认没有明显单点；日活十万级、有促销尖峰的项目，预算会到数万元甚至更高，因为要租同规格环境、造千万级数据、做多轮复压。判断值不值只需问一句：如果上线当天崩了，损失有多大。损失远大于压测费用就该做，反之可以先做接口级性能优化。

Q2：压测环境和生产环境规格必须一致吗？

应用层可以略低但要能按比例换算，数据库层建议一致。因为瓶颈大概率在数据库，规格不一致时得出的结论要乘系数，而系数没有可靠依据。省钱的办法是按小时租用云主机，压完即释放，或者用生产脱敏快照快速搭环境，而不是把规格降档。

Q3：并发数到底怎么估？

不要用注册用户数或日活直接当并发。可用的换算是：日活 × 人均日请求次数 ÷ 业务真正的活跃时长（秒）× 峰值系数。促销场景的活跃时长应按分钟级算，不是按全天算，两者能差三十倍。新业务没有历史数据时，按同类业务峰值 ×2 做设计，并在上线首月用真实监控校正。

Q4：压测通过了，上线就一定没问题吗？

不一定。脚本压测造不出弱网、旧机型、后台挂起、真实支付回调延迟这些情况，所以还需要灰度小流量真机验证。另外压测通过只代表目标压力下系统可用，不代表能扛住突发十倍流量，容量极限场景和降级演练要单独做。上线首周保持监控高频，比任何报告都可靠。

Q5：发现瓶颈之后，扩容和优化先做哪个？

先做优化，再做扩容。典型顺序是：清慢查询与补索引，加缓存并处理缓存击穿，把串行调三方改并行或异步，然后在确实需要时再加节点。直接扩容的问题是把成本永久抬高，而慢查询这类问题扩多少台都会同样慢。经验上，先做一轮优化通常能减少三到五成的机器需求。