242 lines
8.8 KiB
Markdown
242 lines
8.8 KiB
Markdown
## tmerclub商城压力测试文档
|
||
|
||
|
||
|
||
## 一、测试工具
|
||
|
||
|
||
##### **工具**：使用阿里云性能测试PTS分别进行单机，集群负载均衡测试，性能测试PTS参数相如下：
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
## 二、测试-普通订单
|
||
|
||
|
||
|
||
### 单机部署压测报告：
|
||
|
||
|
||
#### 服务器列表：
|
||
- 总服务器*1（8核32g）
|
||
- RDS数据库*1（8核16g）
|
||
|
||
#### 压测报告
|
||
|
||
|
||
|
||
- 每秒事务处理量tps（平均/峰值) ：440/502
|
||
- 成功率（请求/业务）：100%
|
||
- 平均RT（业务响应时间ms）：910
|
||
- 异常数（请求/业务） ：0/0
|
||
- 总请求数5.2w
|
||
|
||
|
||
|
||
#### RDS数据库*1：
|
||
|
||
**CPU使用率（%）**：18%
|
||
|
||
**内存使用率（%）**：20%!
|
||
|
||
|
||
|
||
#### 压测结果分析:
|
||
|
||
提交订单的处理流程分为以下几步：
|
||
- 提交订单-锁定并更改sku库存、插入数据到MySQL
|
||
- Canal监听MySQL数据库binlog,发送数据变动的mq
|
||
- 服务消费mq，将订单数据同步到Elasticsearch(用于搜索)和MongoDB(订单分库分表后，用于数据统计)
|
||
|
||
因此在单机部署的环境中，Canal、RocketMQ、Elasticsearch和MongoDB等中间件会消耗一部分服务器性能，
|
||
同时也限制了订单服务的性能。
|
||
|
||
|
||
|
||
|
||
|
||
### 集群部署压测报告：
|
||
|
||
#### 服务器列表：
|
||
- 中间件服务器*1（8核16g）
|
||
- 后端接口服务器*1（8核32g）- 服务器配置随订单服务部署数量增加而提升, 仅测试提交订单接口，其他服务性能维持在不影响订单服务即可
|
||
- 订单服务机器（4核4g）（1-8台）
|
||
- RDS MySQL数据库（8核16g）（1-4台）
|
||
- RDS Redis数据库（1GB）
|
||
|
||
|
||
|
||
#### 压测结果列表
|
||
|
||
| 订单服务数量 | TPS（平均/峰值） | 异常数（请求/业务） | 总请求数 | 成功率（请求/业务） |
|
||
| :----------: |:----------:| :-----------------: | :------: | :-----------------: |
|
||
| 1 | 682/769 | 0/0 | 8.1w | 100%/0 |
|
||
| 2 | 1311/1502 | 0/0 | 15.4w | 100%/0 |
|
||
| 4 | 2820/3022 | 0/0 | 33.5w | 100%/0 |
|
||
| 6 | 4151/4638 | 0/0 | 49.4w | 100%/0 |
|
||
| 8 | 5526/6145 | 0/0 | 65.7w | 100%/0 |
|
||
|
||
|
||
|
||
|
||
#### 压测结果分析
|
||
|
||
压测结果列表中的数据为：订单服务性能在不受中间件和其他服务影响下的压测报告
|
||
|
||
|
||
|
||
**提交订单流程使用到的服务列表**：
|
||
- 订单服务 - 提交订单接口所在服务
|
||
- 商品服务 - 锁定并扣除sku库存
|
||
- 鉴权服务 - token检验并获取登录用户的信息
|
||
- 搜索服务 - 消费mq同步订单数据到Elasticsearch和MongoDB
|
||
- 用户服务 - 同步订单数据中，插入更多下单用户的信息，便于后续的搜索与统计
|
||
|
||
|
||
|
||
**提交订单流程使用到的中间件列表**：
|
||
- MySQL - 存储订单及订单相关的数据
|
||
- Canal - 监听MySQL数据库binlog,发送订单数据变动的mq
|
||
- RocketMQ - 消息中间件
|
||
- Elasticsearch - 通过搜索服务同步订单数据用于订单列表查询
|
||
- MongoDB - 插入sku出库记录、通过搜索服务同步订单数据用于订单数据统计（分库分表后统计方案）
|
||
|
||
|
||
|
||
**分析**：压测过程中，以上中间件和服务都维持在不影响订单服务的性能。压测8个订单服务的情况下以4核4g服务器为标准，
|
||
除了商品服务的部署数量为2，其他服务部署数量是一台且都没有达到上限
|
||
|
||
|
||
订单模块分库分表后为8个数据库，且8个订单数据库都放置在一台MySQL，订单服务部署数量为4的时候达到上限，压测数据为：
|
||
|
||
|
||
|
||
新部署一个mysql并将四个订单的数据库迁移过去，一共两个MySQL,每个MySQL分别包含四个订单的数据库, 再次压测：
|
||
|
||
|
||
|
||
增加一台MySQL后数据库的性能不再是限制，同时TPS增加300又回到平均范围,继续增加订单服务部署数量到8台:
|
||
|
||
|
||
|
||
此时数据库性能又达到了上限，继续增加MySQL数量后：
|
||
|
||
|
||
|
||
由以上压测流程可知，一台阿里云RDS MySQL数据库对应四个订单服务(四核4g)时达到瓶颈，后续通过增加MySQL数量来继续部署更多的服务。
|
||
|
||
|
||
|
||
## 三、测试-秒杀订单
|
||
|
||
### 集群部署压测报告：
|
||
|
||
#### 服务器列表：
|
||
- 中间件服务器*1（8核16g）
|
||
- 后端接口服务器*1（8核32g）- 服务器配置随秒杀服务部署数量增加而提升, 仅测试秒杀订单接口，其他服务性能维持在不影响秒杀服务即可
|
||
- 秒杀服务机器（4核4g）（1-8台）
|
||
- RDS MySQL数据库（8核16g）
|
||
- RDS Redis数据库（1-8 GB）
|
||
|
||
|
||
|
||
#### 压测结果列表
|
||
|
||
| 秒杀服务数量 | TPS（平均/峰值） | 异常数（请求/业务） | 总请求数 | 成功率（请求/业务） |
|
||
|:------:|:-----------:| :-----------------: |:------:| :-----------------: |
|
||
| 1 | 2537/2790 | 0/0 | 30.2w | 100%/0 |
|
||
| 2 | 5079/5263 | 0/0 | 60.4w | 100%/0 |
|
||
| 4 | 9892/10202 | 0/0 | 117.7w | 100%/0 |
|
||
| 6 | 14389/14895 | 0/0 | 165.4w | 100%/0 |
|
||
| 8 | 18608/19436 | 0/0 | 221.4w | 100%/0 |
|
||
|
||
|
||
|
||
|
||
#### 压测结果分析
|
||
|
||
压测结果列表中的数据为：订单服务性能在不受中间件和其他服务影响下的压测报告
|
||
|
||
|
||
|
||
**秒杀订单流程使用到的服务列表**：
|
||
- 商品服务 - 保存sku出库记录(异步)，不直接影响秒杀性能
|
||
- 鉴权服务 - token检验并获取登录用户的信息
|
||
|
||
|
||
|
||
**秒杀订单流程使用到的中间件列表**：
|
||
- Redis(开启aof) - 存储订单数据(提高下单性能)，后续再插入MySQL(异步)
|
||
- RocketMQ - 消息中间件
|
||
- MongoDB - 存储sku出库记录
|
||
|
||
秒杀服务部署8台服务器后，Redis性能达到瓶颈，压测数据为：
|
||
|
||
|
||
|
||
新部署一个Reids, 再次压测：
|
||
|
||
|
||
|
||
增加一台Redis后，两台redis的cpu使用率都是：50%~60%。
|
||
|
||
|
||
**分析**：网关和鉴权服务的性能会影响秒杀订单性能，商品服务是异步保存sku出库记录，
|
||
因此不跟秒杀服务部署在同一台机器就不会影响秒杀性能，
|
||
秒杀订单数据存储在redis中，当redis性能达到瓶颈时，可增加redis的部署数量来继续提高秒杀订单性能。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
## 四、压力测试结果
|
||
|
||
以如上机器配置和条件,订单分别进行集群和单机进行下单的压力测试，最终结果无Error产生，JVM运行正常没有出现Jvm异常的情况。
|
||
|
||
|
||
### 普通订单
|
||
|
||
**单机部署压测结果**：机器吞吐量维持在440/502并发，在这种大量并发请求时场景响应时间平均为910ms
|
||
|
||
|
||
**集群部署压测结果**：
|
||
- 提交订单TPS: 682/769
|
||
- 八台订单服务机器TPS: 5526/6145
|
||
- 压测过程中成功率100%， 异常数量为0
|
||
- MySQL、其他服务和其他中间件不影响订单服务性能的情况下，增加订单服务部署数量，TPS也对应服务数量倍增
|
||
- 商城默认分库数量为8，可以对应8台MySQL, 订单服务数量是32，也就是八台MySQL都达到瓶颈时，TPS为: 2w(680*32)
|
||
- 默认分库性能达到瓶颈，通过增加分库数量，以继续实现性能的提升(分库数量可以通过配置扩容，不需要更改代码，但旧数据需要根据分片规则手动迁移到新数据库)
|
||
|
||
|
||
|
||
|
||
|
||
### 秒杀订单
|
||
|
||
**集群部署压测结果**：
|
||
- 秒杀订单TPS: 2537/2790
|
||
- 八台订单服务机器TPS: 18608/19436
|
||
- 压测过程中成功率100%， 异常数量为0
|
||
- 增加秒杀服务数量，TPS也对应服务数量倍增
|
||
- TPS为`1.8w`时Redis达到瓶颈，增加redis部署数量可继续提升秒杀订单性能
|
||
|
||
|
||
|
||
**综合以上结论**
|
||
|
||
1. 在Linux服务器上运行时，集群会比单机的并发性能要高，服务性能根据服务数倍增。
|
||
2. 服务的性能会受其他服务性能的影响，所以增加压测服务的数量时，与之相关的服务也要对应增加。
|
||
3. 秒杀数据直接存储于Redis中，而普通订单的提交是存储到Mysql，且有多个关联表也就是会多次连接mysql进行插入操作，所以普通订单下单的性能低于秒杀订单下单。
|
||
4. 我们再仔细观测，在所有的测试环节，内存占用并未出现过明显提高的情况，所以推荐购买服务器时，更需要注重CPU的性能与核心数。
|