## tmerclub商城压力测试文档



## 一、测试工具


##### **工具**：使用阿里云性能测试PTS分别进行单机，集群负载均衡测试，性能测试PTS参数相如下：

![image-20220527171857399](../img/基本开发文档/压测/订单接口配置.png)

![image-20220527171857399](../img/基本开发文档/压测/PTS参数.png)










## 二、测试-普通订单



### 单机部署压测报告：


#### 服务器列表：
- 总服务器*1（8核32g）
- RDS数据库*1（8核16g）

#### 压测报告

![image-20220527180311734](../img/基本开发文档/压测/订单/单机/压测报告.png)

- 每秒事务处理量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的时候达到上限，压测数据为：

![4*订单-mysql上限](../img/基本开发文档/压测/订单/4/压测报告.png)

新部署一个mysql并将四个订单的数据库迁移过去，一共两个MySQL,每个MySQL分别包含四个订单的数据库, 再次压测：

![4*订单-mysql上限](../img/基本开发文档/压测/订单/4-2/压测报告.png)

增加一台MySQL后数据库的性能不再是限制，同时TPS增加300又回到平均范围,继续增加订单服务部署数量到8台:

![4*订单-mysql上限](../img/基本开发文档/压测/订单/8/压测报告.png)

此时数据库性能又达到了上限，继续增加MySQL数量后：

![4*订单-mysql上限](../img/基本开发文档/压测/订单/8-3/压测报告.png)

由以上压测流程可知，一台阿里云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性能达到瓶颈，压测数据为：

![8*订单-redis上限](../img/基本开发文档/压测/秒杀压测/8/压测报告.png)

新部署一个Reids, 再次压测：

![8*订单-redis上限](../img/基本开发文档/压测/秒杀压测/8-1/压测报告.png)

增加一台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的性能与核心数。