一、测试内容
本次测试是针对账户分析进行的压力测试，在账户分析查询接口中，只对用户资产查询接口进行压力测试，其中不包含用户签名校验功能。
二、测试方法
本次采用apache的开源测试工具jmeter，采用本地动态拼装请求数据并通过http协议GET方式发送每日盈亏查询请求。并采用1000个用户账号测试访问情况。
三、测试目标
- 测试单机部署情况下最大TPS值
- 测试单机性能（内存，CPU）占用情况
四、测试环境
| 环境 |
操作系统 |
cpu |
内存 |
| 客户端 |
Win10 |
2核 |
4GB |
| 服务端 |
CentOS 7.6 |
24核 |
24GB |
五、系统部署服务
5.1、业务服务部署情况
5.2、业务部署后没有任务调度，空转情况资源使用情况
| Cpu使用率 |
内存使用（MB） |
缓存Buffer（MB） |
空闲内存（MB） |
| 0.2% |
11725 |
9590 |
2581 |
5.3、账户分析执行业务调度【行为分析空转】后资源使用情况
| Cpu使用率 |
内存使用（MB） |
缓存Buffer（MB） |
空闲内存（MB） |
| 20% |
12533 |
9591 |
1771 |
六、网络访问
Jmeter请求->中台(nginx)->账户分析测试服务器->大数据集群
七、性能测试结果与分析
将账号数据存放在csv文件中，通过读取csv数据作为参数，请求接口
7.1、jmeter集群压测（100进程-每个进行200线程）
7.1.1 测试样例 100*200
7.1.2、聚合报告
7.1.3时间响应结果图
7.1.4 结果分析
7.1.5 资源使用情况
7.2、jmeter集群压测（50进程-每个进行300线程）
7.2.1 测试样例
7.2.2、聚合报告
7.2.3时间响应结果图
7.2.4 结果分析
7.2.5 资源使用情况
7.3、jmeter集群压测（100进程-每个进行300线程）
7.3.1 测试样例
7.3.2、聚合报告
7.3.3时间响应结果图
7.3.4 结果分析
7.3.5 资源使用情况
7.4、jmeter集群压测（500进程-每个进行300线程）
7.4.1 测试样例
7.4.2、聚合报告
7.4.3时间响应结果图
7.4.4 结果分析
7.4.5 资源使用情况
八、结果汇总
本次只是针对账户分析其中一个接口进行测试，忽略掉本地签名，以及签名校验。资源使用情况统计如下：
| 并发数 |
样本 |
平均值 |
中位数 |
90%百分比 |
95%百分比 |
99%百分比 |
最小值 |
最大值 |
异常% |
吞吐量/sec |
Cpu使用率% |
内存使用 MB |
| 200 |
20000 |
450 |
21 |
909 |
1774 |
6920 |
0 |
63044 |
0.66% |
250.1 |
6.6 |
21.4 |
| 300 |
30000 |
689 |
37 |
1347 |
3007 |
10064 |
0 |
107461 |
1.17 |
200.5 |
7.3 |
21.4 |
| 300 |
15000 |
1245 |
640 |
3110 |
4425 |
9784 |
0 |
46924 |
0.12 |
205.7 |
21.1 |
21.4 |
| 500 |
126000 |
1098 |
125 |
2126 |
4588 |
15330 |
0 |
233023 |
1.98 |
256.3 |
23.2 |
21.2 |
结论：
（1）、300个进程之后客户端卡死。
（2）、500并发的时候，执行到12.6w时阻塞，吞吐量较低，样本数未执行完毕。
（3）、由压测结果来看，性能最好是在并发200的时候，吞吐量与并发数基本持平。
备注：为保证弹性，业务稳定，需要预留20%内存。