压测对象和范围

压测对象：参与支付宝活动的商家小程序。
压测范围：小程序调用的商家后台接口。

压测对商家的意义

压测主要是为了发现系统中的性能瓶颈，避免因系统性能问题导致用户在使用过程中出现白屏、异常报错等问题影响用户体验。

压测过程中根据压测执行结果及服务器的资源消耗等情况，可以了解系统的服务承载能力、发现系统性能瓶颈，通过分析导致瓶颈的原因，例如慢SQL、带宽不足、参数设置不合理等等，通过技术优化提升系统性能，从而消除性能风险。

如果系统未做过压测，或者新开发的功能没有做压测，无法评估系统的承载能力，无法预判系统在什么时候需要扩容，无法根据活动流量的预判对系统进行合理的资源分配，容易造成流量突增导致宕机风险。

需要做压测的几种场景

新开发的系统或功能上线前需要了解其性能水位情况。
对系统进行技术调优、系统扩容前后通过压测进行性能比对。
参加支付宝活动前对系统进行性能评估。

压测方案的分类

根据压测场景不同，压测方案可简单可分为：单接口压测、混合压测、性能调优压测、长稳压测等。请根据需要选择不同的方案。

单接口压测：针对核心业务场景涉及的接口进行单独压测，分析单接口链路的瓶颈。
混合压测：针对业务场景进行混合压测，评估系统综合并发处理能力。
性能调优压测：测试应用系统参数、JVM参数、线程池参数等对系统性能的影响，并得出最佳实践的参数设置。
长稳压测：长期维持一个相对较高的并发量进行压力测试，观察系统反应情况。通过 24H * N 天的长稳压测，保证系统的稳定性，防止内存溢出、缓慢泄露，线程池、资源获取时的偶然竞争造成死锁、排队等现象；长稳压测的时间长度可根据具体情况适当减少，例如按照 JVM GC、Full GC 发生次数决定稳定性压测时间等。

压测前的准备工作

确定压测目标

在选好压测方案后开始做压测前，首先需要明确压测的目标需要达到多少 QPS，以及服务器资源消耗的预期情况。如果是参加支付宝活动，请联系相关的技术支持明确压测的预期目标。

PR链路分析

压测前梳理参加小程序业务的PR链路及链路涉及到的服务端服务，根据压测的目标 QPS、PR 链路中的接口 URL 出现次数计算压测的流量模型。如果 PR 链路分析不到位，将无法准确评估系统的性能情况，导致部分接口漏压，未压测接口可能存在性能瓶颈导致服务不可用。

PR 链路分析，一般遵循活动入口+层级分析法，如下图，每个页面涉及到与后台交互的接口都需要评估到位，同时根据每个页面、每个请求的转化率进行流量评估。

举例说明

假如小程序首页 150QPS，20％访问用户会下单，则下单购买需要能承载 30QPS，20% 用户会访问订单，则订单查询页面需要能承受 30QPS。假设现在商家服务端有如下接口，每个接口在链路中被依赖的情况如下，则评估后的压测目标 QPS 如下表所列：

链路名称	页面 QPS	链路涉及的接口	评估的压测目标 QPS
首页	150QPS	接口 A	换算后，每个接口实际目标 QPS：接口 A------150QPS接口 B------180QPS接口 C------60QPS接口 D------30QPS接口 E------30QPS
接口 B
下单购买	30QPS	接口 B
接口 C
订单查询	30QPS	接口C
接口D
接口E

注意：

这里说的 QPS，指的是从支付宝跳转到商家小程序页面的入口容量，如果该页面有 N 个接口，那么对应的流量会被放大到 N QPS，所以参加活动的小程序的压测都是做混合压测。
如果参加活动的多个小程序共用一个接口，需要按小程序个数 *QPS 进行混合压测。
如果参加活动的多个小程序的主链路涉及到的服务部署在相同服务器上，压测时需要将多个小程序的主链路混合场景同时进行压测，来测试系统资源消耗情况是否满足目标。

系统资源评估和准备

被压测系统环境准备

请综合评估后确认是在什么环境进行压测，如果是在生产环境进行压测，需要考虑对生产业务的影响；如果是在线下环境压测，需要考虑线下环境和生产环境的差异。压测前，压测链路包含的接口所涉及到的相关表，压测前建议单表数据量在 800W 以上再进行压测，数据量太少不容易发现慢 SQL。如果压测的过程中系统资源成为性能瓶颈，需对系统资源进行扩容。

带宽准备

压测是模拟高并发用户集中请求服务器的场景，对流量（特别是公网流量）的要求较高，压测前请根据单次请求的资源大小、QPS 综合评估需要的流量带宽情况。

带宽评估公式：带宽(bit)=RequestSize（用户请求一次访问的静态资源&报文大小，单位Bytes）* QPS（压测目标的QPS）* 8 (bit)。

例如：一次请求访问的静态资源+报文约 1MBytes：

假设 QPS 目标为 150 以上，则带宽需要升级到 1MBytes * 150 * 8=1200Mbit，即 1200Mbps 以上。
假设 QPS 目标为200以上，则带宽需要升级到 1MBytes * 200 * 8=1600Mbit，即 1600Mbps 以上。

压测工具准备

以下给出常用的几种压测平台工具，可根据需要进行选择。

压测脚本准备

压测前，对需要压测的PR链路进行梳理，整理出 PR 链路的接口文档，进行相关的压测脚本配置。

如果是 H5 页面，可以通过抓包的方式录制压测脚本。

压测注意事项

压测是全链路的，不能遗漏底层的调用，如果调用了下游服务（如第三方的城市列表等服务），需要确认下游服务的系统性能（TPS）。
压测结果返回中增加断言判断，根据正常业务场景的字段模拟判断返回结果是否正常，不能简单的根据 HTTP 状态值200来判断。
务必注意不能让压测数据污染生产数据（对于可能污染生产数据的接口，请做好识别准备工作，如压测时通过特殊字段或特殊参数进行区分）。
建议在测试环境(非生产环境)做一遍全面的慢SQL排雷压测，慢SQL检查的时间设置为1s，PR链路涉及到的所有关键表，压测前建议单表数据量在800W以上进行压测，数据量太少不容易发现慢SQL。
如果有缓存，但是缓存时间较短 （缓存有效期不足 12 小时），建议按无缓存压（压测时关闭缓存），注意缓存的更新策略，避免出现缓存击穿的情况。
压测是全链路的，需要将链路中涉及的全部接口混合压测，不能遗漏底层的调用，如果调用了下游服务（如第三方的城市列表等服务），需要确认下游服务的系统性能（QPS）。
压测持续时长建议10分钟以上、便于全面分析接口性能；
如果涉及支付环节，请自行 mock 支付宝侧的调用或使用支付宝挡板环境压测，切勿请求到支付宝的真实生产环境，以免产生不可预估的影响！！ （注意！模拟支付宝侧的返回结果必须设置与真实环境相同的返回结果延迟）。

压测结果与报告模板

除了最终的压测 QPS 数据之外，需要关注并记录压测过程中成功率、响应时间 RT、CPU、内存、系统负载 load 等情况。

根据使用的压测工具可以选择合适的模板进行压测报告的编写。

小程序压力测试方案