-
- 测试目的
保证***服务能满足生产的业务压力需要。
- 性能测试:在一定约束条件下(指定的软件、硬件和网络环境等)确定系统所能承受的最大负载压力的测试过程。
- 事务:一个或者一系列操作。
- 并发数:单位时间内同时执行一种操作的用户数量。
- TPS:Transaction Per Second,每秒事务数量,单位是 事务/秒。
- TRT:Transaction Response Time,事务响应时间,指TPS稳定时的平均事务响应时间,单位是秒。
- 拐点:TPS & 虚拟用户曲线的凹凸分界点。
- 测试环境配置
-
- tcp队列数
-
- 测试环境配置
ss -lnt|grep 9587
LISTEN 0 1024 *:9587 *:*
-
-
-
- 服务器相关配置
-
-
- Linux内核版本
uname -a
Linux **** 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
- 逻辑CPU核数
cat /proc/cpuinfo| grep "processor"| wc -l
8
- 内存信息
cat /proc/meminfo
MemTotal: 32781240 kB
Jmeter、nmon等
系统压力测试是逐步增加系统负载,测试系统性能的变化,并最终确定系统可以最大可承受多大的负载。
-
-
- 系统压力测试操作步骤
-
- 编写性能测试脚本
- 利用测试脚本,并发测试
- 测试执行:采用阶梯方式,逐步增加并发用户数,直至在某一个并发用户数增加后TPS达到峰值。即找到拐点,获取拐点的负载数据,就是系统可承受的最大负载。
- 监控服务器数据
-
-
- 测试通过标准
- 系统资源消耗
- 测试通过标准
-
- 服务器CPU占用率<70%
- 事务通过率>99.9%
-
-
- 最大负载
-
-
- 最大TPS可满足生产环境的需求
- 性能测试数据分析
图一
从100个并发数往上增加,每60秒后增加100个并发数,直到增加到4000个并发数为止停止测试。呈一个梯度增加并发数(线程数)的趋势。
图二
通过图二可以看到TPS随着并发数的增加,呈现下降的趋势。红色线为通过事务数,绿色线为失败事务数。在13分左右,也就是并发数在1400时出现失败的事务,此时通过事务数的比例在99.9%以上,而到达23分左右,即2400个并发数时,通过事务数的比例小于99.9%,满足测试准出标准,故停止测试。
图三
通过图三的聚合报告,可以看到从并发数由100开始往上添加直到结束测试的过程中,平均响应时间为1515ms(1.5秒)。
-
-
- 事务响应时间
-
图四
可以看到图四事务响应时间随着并发数的增加,响应时间逐渐增长。虽然出现小幅波动,但在2400个并发数之前,事务响应时间未超过3000ms(3秒)。
-
-
- 服务器监控数据
-
| 平均占用率 | 最高占用率 | 闲时占用率 |
CPU | 32.85% | 43.10% | 12.60% |
内存 | 99.30% | 99.34% | 99.29% |
表一
由表一可看出经过SQL优化,添加索引之后,对服务器的压力减小,CPU不会跑满。
图五
图五为执行过程中监控服务器数据的截图。Linux的负载均值小于CPU核数(8核)。
- 测试结论
经过性能测试数据分析,可以看到,对服务器的压力在可接受范围内,根据测试准出原则事务通过率需在99.9%以上,故拐点的并发数为2400。建议基于报告中所示的服务器配置情况下,建议不要超过2400个并发数。