7DGroup性能实施项目方案
管理组 发布 2022年09月25日
文档修订记录
目录
1.测试背景....................................................................... 4
1.1项目背景............................................................. 4
1.2性能目标............................................................. 4
2.测试范围....................................................................... 4
3.测试准则....................................................................... 5
3.1启动准则............................................................. 5
3.2结束准则............................................................. 5
3.3暂停/再启动准则................................................ 5
3.3.1 暂停准则................................................. 5
3.3.2再启动准则............................................... 5
4.业务模型和性能指标...................................................... 6
4.1业务模型/测试模型............................................. 6
4.2业务指标/性能指标............................................. 6
5.系统架构图.................................................................... 7
5.1系统技术栈......................................................... 7
5.2逻辑架构图......................................................... 7
5.3部署架构图......................................................... 8
6.测试实施准备................................................................ 8
6.1硬件环境............................................................. 8
6.2测试工具............................................................. 9
6.3监控工具............................................................. 9
6.4数据准备............................................................. 9
7.性能设计..................................................................... 10
7.1场景执行策略.................................................... 10
7.2场景设计........................................................... 10
7.2.1基准场景................................................ 10
7.2.2容量场景................................................ 10
7.2.3稳定性场景............................................. 11
7.2.4异常场景................................................ 11
7.3监控设计........................................................... 12
7.3.1全局监控................................................ 12
7.3.2定向监控................................................ 12
8. 项目组织结构.............................................................. 12
9. 输出..................................................................... 13
9.1过程性输出....................................................... 13
9.2结果输出........................................................... 13
10. 测试计划................................................................... 14
11.测试风险分析............................................................. 14
1.测试背景
1.1项目背景
为了配合7DGroup性能测试高级培训课程的同步实践,我们选取一个开源电商平台项目,同时也便于改造,并且该项目可以覆盖常见的技术栈。根据甲方提出的业务容量需求,进行性能测试,找到并优化系统中的性能瓶颈。
1.2性能目标
1.根据经典的电商下单流程,测试当前系统的单接口最大容量。
2.根据业务比例设计容量场景,充分利用当前资源,找到当前系统的性能瓶颈,并优化,以达到系统的最佳运行状态。
3.根据稳定性场景,判断当前系统可支持的系统最大累加容量。
4.根据当前系统中的异常,判断对性能产生的影响。
2.测试范围
序号 | 操作 | 接口 |
1 | 打开首页 | /home/content |
2 | 用户登录 | /sso/login |
3 | 用户信息查询 | /member/address/list |
4 | 商品查询(关键字) | /home/hotProduceList |
5 | 商品加入购物车 | /cart/add |
6 | 查询购物车信息 | /cart/list |
7 | 购物车信息确定订单 | /order/generateConfirmOrder |
8 | 生成订单信息 | /order/generateOrder |
9 | 支付前查询订单列表 | /order/list |
10 | 支付订单信息 | /order/paySucess |
11 | 支付后查询订单详情 | /order/detail/${orderId} |
3.测试准则
3.1启动准则
1. 确定系统逻辑架构和部署架构和生产一致;
2. 确定基础数据和生产一致或按模型缩放;
3. 确定业务模型可以模拟生产真实业务;
4. 环境准备完毕,包括:
1)功能验证通过;
2)各组件基础参数梳理并配置正确;
3)压力机到位,并部署完毕;
4)网络配置正确,连接通畅,可以满足压力测试需求。
5. 测试计划、方案评审完毕;
6. 管理组、脚本开发组、环境搭建组、架构组、分析调优组以及相关人员到位。
3.2结束准则
1. 达到项目要求的性能需求指标;
2. 关键性能瓶颈已解决;
3. 完成性能测试报告和性能调优报告。
3.3暂停/再启动准则
3.3.1 暂停准则
1. 系统环境变化:例如:系统主机硬件损坏、网络传输时间超长、压力发生器出现损坏、系统主机因其他原因需升级暂停等;
2. 测试环境受到干扰,比如服务器被临时征用,或服务器的其他使用会对测试结果造成干扰;
3. 需要调整测试环境资源,如操作系统、数据库参数等;
4. 该测试业务无法达到规划指标要求;
5. 出现测试风险中列出的问题等。
3.3.2再启动准则
1. 测试中发现问题得以解决;
2. 测试环境恢复正常;
3. 测试风险中出现的问题已解决;
4. 环境调整完毕。
4.业务模型和性能指标
4.1业务模型/测试模型
序号 | 操作 | 接口 | 业务比例 |
1 | 打开首页 | /home/content | 11% |
2 | 用户登录 | /sso/login | 5% |
3 | 用户信息查询 | /member/address/list | 5% |
4 | 商品查询(关键字) | /home/hotProduceList | 54% |
5 | 商品加入购物车 | /cart/add | 5% |
6 | 查询购物车信息 | /cart/list | 3% |
7 | 购物车信息确定订单 | /order/generateConfirmOrder | 3% |
8 | 生成订单信息 | /order/generateOrder | 3% |
9 | 支付前查询订单列表 | /order/list | 3% |
10 | 支付订单信息 | /order/paySucess | 3% |
11 | 支付后查询订单详情 | /order/detail/${orderId} | 5% |
4.2业务指标/性能指标
序号 | 操作 | 目标TPS | TPS标准方差 | 响应时间 | 响应时间 标准方差 |
1 | 打开首页 | 1000 | 5% | 100ms | 5% |
2 | 用户登录 | 1200 | 5% | 100ms | 5% |
3 | 用户信息查询 | 1000 | 5% | 100ms | 5% |
4 | 商品查询(关键字) | 1100 | 5% | 100ms | 5% |
5 | 商品加入购物车 | 1300 | 5% | 100ms | 5% |
6 | 查询购物车信息 | 1000 | 5% | 100ms | 5% |
7 | 购物车信息确定订单 | 1000 | 5% | 100ms | 5% |
8 | 生成订单信息 | 1000 | 5% | 100ms | 5% |
9 | 支付前查询订单列表 | 1000 | 5% | 100ms | 5% |
10 | 支付订单信息 | 1000 | 5% | 100ms | 5% |
11 | 支付后查询订单详情 | 1000 | 5% | 100ms | 5% |
通过和甲方确认,系统容量场景的目标TPS要达到2000,且在运维周期内有1 亿笔业务容量。
5.系统架构图
5.1系统技术栈
电商平台系统用到的主要技术栈如下表所示:
技术 | 说明 |
Kubernetes(k8s) | 容器云 |
Containerd | 应用容器引擎 |
Spring Cloud | 微服务框架 |
Knife4j | 文档生产工具 |
Elasticsearch | 搜索引擎 |
RabbitMQ | 消息队列 |
Redis | 分布式缓存 |
MongoDB | NoSQL数据库 |
Logstash | 应用日志收集 |
Prometheus | 资源监控系统 |
Grafana | 监控可视化看板 |
Skywalking | 链路追踪 |
Kibana | 日志可视化看板 |
JMeter | 压测工具 |
Kuboard | 微服务管理工具 |
5.2逻辑架构图
电商平台系统逻辑架构如下图所示:
5.3部署架构图
电商平台系统部署架构如下图所示:
6.测试实施准备
6.1硬件环境
电商平台系统涉及的硬件资源如下表所示:
序号 | 主机名 | 操作系统 | 配置 | IP |
1 | S5 | CentOS 7.8 64 bit | 2C/8G | |
2 | S6 | CentOS 7.8 64 bit | 2C/8G | |
3 | S7 | CentOS 7.8 64 bit | 2C/8G | |
4 | S8 | CentOS 7.8 64 bit | 8C/16G | |
5 | S9 | CentOS 7.8 64 bit | 8C/16G | |
6 | S10 | CentOS 7.8 64 bit | 8C/16G | |
7 | S11 | CentOS 7.8 64 bit | 8C/16G | |
8 | S12 | CentOS 7.8 64 bit | 8C/16G | |
9 | S13 | CentOS 7.8 64 bit | 8C/16G |
6.2测试工具
在性能测试过程中,我们将使用 JMeter 的 backend Listener 把数据直接发到 InfluxDB 中,然后再由 Grafana 来展现。
序号 | 软件 | 版本 |
1 | JMeter | 5.3 |
2 | InfluxDB | 1.8 |
3 | Grafana | 7.1.0 |
6.3监控工具
根据架构图以及RESAR 性能工程中的全局 - 定向的监控思路,我们在选择第一层监控工具时,要采集全量的全局计数器,采集的计数器包括各个层级,具体如下表所示:
序号 | 软件 | 功能 |
1 | Prometheus | 采集各类组件的计数器数据 |
2 | Grafana | 展现Prometheus收集的数据 |
3 | Skywalking | Java应用APM链路监控工具 |
4 | Elasticsearch | 存储各类日志 |
5 | Kibana | 展现各类日志 |
6 | Logstash | 采集各类日志 |
7 | Springboot admin | Springboot应用管理监控工具 |
6.4数据准备
在性能工程中,数据准备要满足两个特性:
1)满足生产环境的真实数据分布;
2)参数化数据一定要使用基础数据来覆盖真实用户。
具体目标数据量要求如下表所示:
序号 | 数据类型 | 表 | 目标数据量 |
1 | 用户信息 | ums_member | 250万 |
2 | 地址信息 | ums_member_receive_address | 250万 |
3 | 商品数量 | pms_product | 100万 |
4 | 订单表 | oms_order_item | 1500万 |
7.性能设计
7.1场景执行策略
为了模拟真实的线上场景,我们采用连续递增的策略,类似下图所示:
7.2场景设计
7.2.1基准场景
测试场景 | 基准场景测试 |
前置条件 | 1、性能脚本运行响应正确,无错误日志信息; 2、参数化文件准备完毕; |
测试方法
| 1、根据连续递增的测试策略,对各单交易进行压测; 2、监控并收集各组件的性能计数器数据; 3、分析压力场景、全局监控数据,并判断性能瓶颈; 4、对于存在性能瓶颈的交易,进行性能优化调整后,回归测试。 |
预期结果 | 1、系统的资源已经用尽; 2、各单交易稳定运行时的业务指标/性能指标满足既定值。 |
7.2.2容量场景
测试场景 | 容量场景测试 |
前置条件 | 1、各单交易稳定运行时的业务指标/性能指标满足既定值; 2、容量场景脚本已根据业务模型准备完毕。 |
测试方法
| 1、根据连续递增的测试策略,执行容量场景脚本; 2、监控并收集各组件的性能计数器数据; 3、分析压力场景、全局监控数据,并判断性能瓶颈; 4、对于存在的性能瓶颈,进行性能优化调整后,回归测试。 |
预期结果 | 1、容量场景中各单交易的实际业务模型和预期业务模型一致。 2、容量场景最大稳定的TPS满足既定值。 |
7.2.3稳定性场景
测试场景 | 稳定性场景测试 |
前置条件 | 1、容量场景最大稳定的TPS满足既定值; |
测试方法
| 1、根据连续递增的测试策略,以容量场景最大稳定的TPS稳定运行13.8小时; 2、监控并收集各组件的性能计数器数据; 3、分析压力场景、全局监控数据,并判断性能瓶颈; 4、对于存在的性能瓶颈,进行性能优化调整后,回归测试。 |
预期结果 | 1、各单交易的实际业务模型和预期业务模型一致。 2、稳定性场景过程中无性能瓶颈。 |
7.2.4异常场景
测试场景 | Order服务限流场景测试 |
测试方法
| 1、根据连续递增的测试策略,执行容量场景脚本稳定运行10分钟; 2、Order服务的限流阈值QPS的单机阈值设置为100,稳定运行5分钟; 3、取消Order服务的限流阈值设置,稳定运行5分钟后,场景结束。 |
预期结果 | 1、压力场景中稳定运行的TPS是100; 2、限流过程中出现的报错都是和系统繁忙相关的报错。 |
7.3监控设计
7.3.1全局监控
监控使用 Prometheus/Grafana/Spring Boot Admin/SkyWalking/ELK作为全局视角的第一层监控。对工具中没有覆盖的第一层计数器,在执行场景时通过执行命令来进行补充。
7.3.2定向监控
在具体性能分析过程,主要的定向分析工具如下表所示:
序号 | 工具 | 作用 |
1 | Jstack Jmap Arthas | 监控java应用 |
2 | Mysqlreport Pt-digest-query | 分析MySQL |
3 | Perf strace bpf | 跟踪操作系统级别调用 |
8. 项目组织结构
角色 | 职责 | 人员 |
管理组 | 1. 制定计划、方案 2. 保证进度 3. 控制风险 4. 协调人员 | 组长:xx 组员:xx、xxx、xxx |
脚本开发组 | 1. 编写压力脚本 2. 配置压力场景 3. 造数据 4. 确定业务模型 | 组长:xx 组员:xx、xxx、xxx |
环境搭建组 | 1. 搭建测试环境 2. 维护测试环境 | 组长:xx 组员:xx、xxx、xxx |
开发组 | 1. 代码优化 2. 代码逻辑介绍 | 组长:xx 组员:xx、xxx、xxx |
分析调优组 | 1. 分析项目中出现的所有性能瓶颈,并给出证据链 2. 给出明确的解决方案 3. 确定分析模型 | 组长:xx 组员:xx、xxx、xxx |
架构组 | 1. 画出架构图(逻辑、物理) 2. 画出泳道图 | 组长:xx 组员:xx、xxx、xxx |
9. 输出
9.1过程性输出
1)脚本
2)场景执行结果
3)监控结果
4)缺陷记录
9.2结果输出
1)性能测试报告
2)性能调优报告
10. 测试计划
见《7DGroup性能实施项目计划》。
11.测试风险分析
风险点 | 应对措施 |
参与者无法集中管理,存在交付产物延期风险 | 1. 项目分配到组,由组长组织大家进行任务拆解; 2. 会议跟进:每周1和3,管理组与各组组长开会同步进度和风险; 3. 奖励机制:管理组输出奖励机制,对提前完成的组进行奖励; 4. 成果展示:每周六,课程结束各组分享本周成果。 |
压测项目整体了解不深入 | 1. 宣讲:各组根据需要做的事情进行宣讲,以及未来的进度规划; 2. 开发和架构组同学,针对项目进行详细拆解,从部署到功能进行宣讲。 |