8.8 KiB
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部署数量可继续提升秒杀订单性能
综合以上结论
- 在Linux服务器上运行时，集群会比单机的并发性能要高，服务性能根据服务数倍增。
- 服务的性能会受其他服务性能的影响，所以增加压测服务的数量时，与之相关的服务也要对应增加。
- 秒杀数据直接存储于Redis中，而普通订单的提交是存储到Mysql，且有多个关联表也就是会多次连接mysql进行插入操作，所以普通订单下单的性能低于秒杀订单下单。
- 我们再仔细观测，在所有的测试环节，内存占用并未出现过明显提高的情况，所以推荐购买服务器时，更需要注重CPU的性能与核心数。