| XX 5.0系统 性能测试方案 |
修订历史记录
为保证在日常运行及大型活动期间，稳定运行、应用快速，对进行性能测试，验证系统是否能够达到业务所需的性能指标，同时发现系统中存在的性能瓶颈，并进行改进，起到优化系统的目的。主要包括以下几个方面：
| 服务器 | 数量 | 硬件配置 | 软件环境 | 作用 |
| 压测机1台 | 1 | 8C16G | linux | 加压 |
| 应用服务器 | （mzapipress：4台，UAC：2台） | 8C 16G*6 | Tomcat | 应用服务器 |
| 数据库服务器 | 1 | 8C16G | mysql | 数据库 |
| redis | 1 | 8G集群版（2节点） | 缓存服务器 | |
| ES | 1 | ？ | ？ | |
| MQ | 1 | 共用PRE环境 | ||
| nginx | 1 | 共用PRE环境 | ||
| 文件服务器 | 1 | PRE服务 |
备注：服务器配置根据业务需要申请
脱敏、同步线上数据，保证被压测系统数据库量级和线上一致，
目前压测环境23万用户数据，线上1000万不都是活跃用户，有效用户数23万已足够
根据不同的业务场景，对应的具体接口入参可以从数据库提取、代码生成、计数器、随机数等方式来进行参数化，数据唯一性接口保证每次访问入参不重复，避免数据缓存造成压测误差
查询接口：在swagger中找到对应的api，通过参数去数据库导出入参数据。
写接口：根据业务需求造出对应入参数据。
| 类别 | 工具 | 判断维度 | 通过 | 备注 |
| 接口性能 | Jmeter | TPS | 参照4.2公式 | |
| 超时概率 | 小于0.5‰ | |||
| 错误概率 | 小于0.5‰ | |||
| 响应时间 | <200ms |
若在每天的某一时段里有很大的访问量，其他时间相对较少，可以用简单峰值法、二八法或九一法。
举例：
下图为2021年2月3日三亚地区推广力度较大的活动峰值数据，计算举例：
数据依据：活动流量，2月3号11点到12点一小时内访问量（打开次数）从1100激增到峰值52329，用户数从1500增加到峰值27198，一天内总访问量为9.04万，11点到13点之间总访问量为7.56万，总访问人数4.88万。平均页面停留时长20S
计算方法：根据活动集中访问的特殊性，按1/9原则计算活动并发数（90%用户量集中在10%时间内完成），52329*90%/3600*10%=130.825个/s，
按2/8原则计算日常并发数： (9.04万*80%)/（8小时*20%*3600）=12.5个/s，
预估：预估两年内小程序用户数从1000万以30%的增长速度，并发数若要满足未来两年业务需求，活动应满足130.825*（1.3*1.3）=约221个/s，日常满足12.5*1.3*1.3=约21个/s
平均响应时间计算：响应时间的2-5-8原则，取2秒体验要求，减去网络及各节点时间损耗，接口响应时间<200ms为达标
TPS=并发数/平均响应时间，当前至少要满足131/0.2=655TPS，两年后：221/0.2=1105TPS，以上指标为最低tps要求。
错误率：（失败交易数/交易总数）*100%，参考标准：一般成功率不低于99.4%,成功率99.7%为达标
根据节点数、配置、以及性能瓶颈三个维度去估算出压测/线上系数比n(1)，目前压测环境和生产环境节点配置一致，数据库及rides配置略低，若压测环境满足业务需求，则理论上生产环境能支撑相同压力
验证：同一个接口在同等并发下统计各环境tps，验证压测/线上tps系数比是否等于n(1)
| 资源 | 监控资源 | 通过 | 备注 |
| CPU | CPU sys% | 小于或者等于30% | CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。 |
| CPU利用率一般维持在70%左右的水平，高峰期达到90%的水平，是不浪费资源，并比较稳定的。 | |||
| CPU sys%小于或者等于30%, | |||
| CPU wait%小于或者等于5%。 | |||
| CPU wait% | 小于或者等于5% | CPU Load要小于CPU 核数。 | |
| System\Processor Queue Length | CPUload<4 | ||
| 内存 | SWAP利用率 | SWAP交换空间利用率要低于70% | 太多的交换将会引起系统性能低下。 |
| 硬盘 | Physical Disk\% Disk Time Logical Disk\% Disk Time | 小于等于80% | 正常值<10，此值过大表示耗费太多 时间来访问磁盘，可考虑增加内存、 更换更快的硬盘、优化读写数据的算 法。若数值持续超过80 (此时处理器 及网络连接并没有饱和)，则可能是内 存泄漏。 |
测试概述：
| 目的 |
|
| 方法 |
|
| 目的 |
|
| 方法 |
|
不断加大并发数、同时监控CPU,内存，CPUload，带宽，TCP连接数等各项性能指标，当某一指标达到瓶颈记录此时的并发数及性能瓶颈。
| 目的 |
|
| 方法 |
|
不断加大并发数，当RT和TPS出现交叉拐点时记录此时对应的并发数、RT、TPS及相应的性能资源参数。负载测试结果可在5.2压力测试结果文件中分析出最优性能，故此步测试可省略。
| 目的 |
|
| 方法 |
|
根据业务场景合理设计各个接口压力比，在确定比例之后，通过jmeter按比例施加压力，来检测系统在混合场景下性能。
按照日常平均使用量的80%，根据实际运行峰值时间段进行7*24小时测试，且资源利用率符合4.2节定义的标准。
5.6单台服务探容测试
| 目的 |
|
| 方法 |
|
综合活动、大型线上活动主要接口，并发数较高、调用率较高的接口，大型活动MZapi所有接口。
和各业务组SDM、TPM一起确认覆盖核心、关键、常用业务，从中提取接口。
根据APM监控，截取一段时间内实际业务调用频率TOP10接口、tps为TOP10接口，响应时长top10。
| 序号 | 角色 | 工作项 | 预计开始时间 | 预计完成时间 | 交付产物 |
| 一轮测试 | |||||
| 开发/运维 | 环境搭建 | 环境准备 | |||
| 1 | 测试 | 方案 | 性能测试方案 | ||
| 2 | 测试 | 脚本 | 性能测试脚本 | ||
| 3 | 测试 | 数据 | 数据 | ||
| 4 | 测试 | 运行脚本 | 执行压测 | ||
| 5 | 测试 | 报告 | 一轮性能测试报告 | ||
| 6 | 测试 | 优化 | 需要优化的接口清单 | ||
| 二轮测试 | |||||
| 1 | 开发 | 优化 | 优化 | ||
| 测试 | 运行脚本 | 执行压测 | |||
| 2 | 测试 | 报告 | 测试报告 | ||
| 3 | 测试 | 监测 | 稳定性测试（持续监测系统情况，有问题及时修复） | ||
| 4 | 测试 | 报告 | 稳定性测试报告 | ||
| 序号 | 风险类型 | 描述 | 等级 | 缓解策略 |
| 1 | 过程风险 | 由于加大并发导致接口大批量报错，压测无法进行下去 | 高 | 遇到阻塞问题及时抛出问题一起排查，推动艰难的及时找sdm沟通 |
| 2 | 环境风险 | 由于场景功能问题或对接系统环境达不到压测要求，致使调用接口不可用，导致的压测场景无法执行。 | 高 | 在环境部署完成后先进行基准测试，保证环境可用。 对接系统环境协调，尽量能满足压测调用 |
| 3 | 人员风险 | 开发调优资源不足，调优不能及时保障进度 测试人员兼做功能测试，测试进度会相互影响 | 中 | 根据测试方案时间安排，如有冲突提前报备 |
| 4 | 其他风险 | 由于不可预测原因导致压测不能按计划完成 | 中 | 每日同步性能压测进度，有风险及时抛出 |
