一、性能测试的概念&意义
1、概念
通过技术的手段模拟大量用户同时访问被测应用,观察、记录和分析系统的各项性能指标的过程。
2、目的
评估系统的性能瓶颈,预测系统的最大用户负载能力
3、意义
能够有效评估系统的性能指标,用于系统的性能评估 2)能够识别系统的性能瓶颈,协助性能调优 3)能够指导突发流量承载方案的制定 4)能够用于系统运维成本的预算
二、性能指标理解
1、指标分析
(1)响应时间
用户通过客户端向服务端发出请求的时间为:T1
服务端接收到请求,处理该请求的时间为:T2
服务端返回数据给客户端时间为:T3
客户端接收到响应数据,处理数据呈现给用户时间为:T4
(2)响应时间系统视角
系统的响应时间 Ts= T1+T2+T3
该时间没有包括客户端对数据处理并呈现的时间 T4
(3)响应时间用户视角
用户眼中的的响应时间 Tu = T1+T2+T3+T4
用户通过客户端发出请求到客户端展现请求结果,这个时间越短越好
(4)响应时间服务器视角
服务器接收到客户端发送的请求,并给出响应,这个过程所消耗的时间为响应时间,即服务器仅关注 T2
从不同的视角下,衡量响应时间的指标也各不相同。在实际测试过程中,要明确以什么视角验证被测对象的性能。
2、并发
(1)并发用户数
简称 VU ,指的是系统中操作业务的用户。一般称为虚拟用户数。并发用户数跟注册用户数,在线用户数有很大差别。并发用户数一定会对服务器产生压力,而在线用户数只是挂在系统上,对服务器不产生压力
(2)在线用户数
在已有系统中选取高峰时刻,在一定时间内使用系统的人数,这些人数可认为是在线用户数
(3)注册用户数
数据库中存在的用户数。并发用户数可以取系统用户数的 10%,例如在半个小时内,使用系统的用户数为 10 万,那么取 10%(即 1 万) 作为并发用户数
(4)系统并发数
一般指测试工具为了模拟出用户并发压力而启动的线程,比如 jmeter 里面的 Thread。由于 jmeter 中的线程有迭代的概念,所以通过线程迭代数就可以模拟出用户单位时间最大的并发数。
注意不要把系统并发数和并发用户数* 的概念混在一起
3、吞吐量
单位时间内系统处理请求的数量。吞吐量直接体现了软件系统的业务处理能力
(1)衡量方式
Rps 请求数/单位时间
Hps 点击数/单位时间
Tps 通过事物数/单位时间
Qps 查询数/单位时间
(2)TPS 模型
随着压力不断增长,实测系统的资源会不断被消耗,TPS 值会因为这些因素而发生变化,并且符合一定的规律
4、基准测试
原点到 a 之间的系统性能,指以系统预期性能指标为前提,对系统不断增加压力,以验证系统能否达到预期性能
5、负载测试
a 到 b 的系统性能,是指对系统不断地增加压力或一定压力下的持续运行,直到系统的某项或多项性能指标达到极限,例如某种资源已经达到饱和状态等
6、压力测试
b 到 d 之间的系统性能,是指超过安全负载的情况下,对系统不断施加压力,直到系统崩溃,找出系统的瓶颈点和崩溃点。
Tps(每秒处理事务数)
一个事务是指客户端向服务器发送请求然后服务器做出反应的过程
单请求事物:事物由单个接口请求构成。如一次登录,一次查询
多请求事物:事物由多个接口请求构成。如登录 - 查询 - 新增 - 退出。这四步操作构成一个完整的事物
TPS 的决定性因素:事务是要靠虚拟用户完成
1 个用户在 1 秒内完成 1 笔事务,那么 TPS 就是 1
1 个事物响应时间是 1ms,那么 1 个用户在 1 秒内能完成 1000 笔事务。TPS 就是 1000
1 笔业务响应时间是 1s,那么 1 个用户在 1 秒内只能完成 1 笔事务。想达到 1000TPS 就至少需要 1000 个用户
因此可以说 1 个用户能产生 1000TPS, 1000 个用户也可以产生 1000TPS,由响应时间决定
5、Rps 每秒发起的请求数
并发数=rps* 平均响应时间
RPS 用来描述施压引擎实际发出的压力大小
RPS 模式主要是为了站在服务端视角去直接衡量系统的吞吐能力-TPS 而设计的
并发过低时可能达不到预期的 RPS,并发过高时可能压力过大直接压垮服务器
按照被压测端需要达到的 TPS 去设置相应的 RPS,应用场景主要是一些动态的接口 API,比如登陆、提交订单
7、吞吐量行业标准
金融行业:1000TPS~50000TPS,不包括互联网化的活动
保险行业:100TPS~100000TPS,不包括互联网化的活动
制造行业:10TPS~5000TPS
互联网电子商务:10000TPS~1000000TPS
互联网中型网站:1000TPS~50000TPS
互联网小型网站: 500TPS~10000TPS
提问:我有一个功能,需要测试一下最大支持多少用户并发?
此时要计算的是最大用户并发数,强调的是同时操作,也可以理解为同时发起请求,我们可以通过 RPS 定时器或者阶梯加压线程组测试每秒最大的请求数
三、吞吐量模式下的阶梯负载
RPS模式负载:RPS是request persecond,也就是每秒的请求数。我们通过持续不断地增加请求来对服务端施压,测试服务端的处理能力,找到瓶颈。
策略
第一次:并发 200,不限迭代次数,同时在请求下面加 RPS 定时器。目的是在 200 线程下,将 RPS 逐步增加到 1000/S,并持续运行一段时间
start=1 end=200,持续时间是 10。表示我们需要在 10s 内将 RPS(每秒请求数)均匀的从 1 提升到 200。
拐点判断方式
通过 Tps走势图观察拐点。吞吐量会随压力的增大呈抛物线状,抛物线的最高点处,即为当前测试环境下该请求的最大处理能力。吞吐量的拐点往往也就是响应时间的拐点。通过资源消耗判断拐点。比如测试中 Tps 仍呈上升趋势,但 CPU 资源使用率已高达 90%,就以此时 Tps 值为当前测试环境下该请求的最大处理能力。
注意:rps 是客户端每秒发起的请求,tps 是服务端每秒完成的请求。实际情况中,tps 往往和 rps 不等,因为要考虑到中间的网络和服务处理时间
启动 jmeter,运行一段时间之后我们观察一下监听器的数据图表Tps监听
RPS在 836/s 的时候开始出现拐点,请求曲线的角度开始收窄
TPS 在730/s 左右开始出现剧波动,可以认为这是吞吐量的一个拐点
在 1:00 秒的时候,也就是 TPS 达到730/S的时候,事物开始出现错误
1:此处可能就是一个性能瓶颈
2:有可能是百度对 ip 的访问量做了限流,防止爬虫
3:有可能是我当前环境的问题,包括带宽,内存,cpu 等等资源的限制,后期都需要考虑进去
在性能稳定的情况下,可以套用公式去计算出最大并发数:并发数 = RPS * 响应时间
1:稳定状态下,最大RPS= 836/S。这个值可以理解为最大支持 1 秒内 836个用户同时去访问。
2:稳定情况下,响应时间大约长期保持在160 ms
3:稳定情况下,峰值系统并发数大约是 836*0.16=134。这个值可以理解为只要启动 134个线程就可以在一秒内满足 836/s 的压力值。或者换个角度,也可以表示最大支持 134个用户在 1s 内不停的访问,一直达到瓶颈点
第二次:100 并发
这一次我们把线程数收紧,只给 100 线程。以此观察线程数降低的情况下,压力会不会变小观察到,请求数依然在 820-830 这个区间变缓
结论
此当前环境下,不论是本机资源,还是百度设置了限流等原因,我们的最大请求数只能维持在 820-830,最大 TPS 维持在 700-750之间,平均响应时间在160-170ms之间,最大系统并发数在 130 左右。超出这个范围就开始出现波动
四、并发用户模式下的阶梯负载
并发用户负载:
我们在讨论负载测试的时候,会说持续稳定地增加系统的负载。那么什么是持续稳定的增加负载呢?jmeter中,线程数可以看做是虚拟并发用户。那么我们想要稳定的增加负载,就需要持续不断地增加并发数。通过并发数的不断增加来考量各种性能指标的变化,找到拐点。
策略:
配置参数的完整描述为:给定负载并发用户数为500,从0秒开始,每3秒内增加50个并发用户数,3秒时刻完成50个并发用户数的启动后开始平稳运行10秒钟,依次下去,直到500个并发用户数全部都启动完成后,平稳运行100秒,然后每隔5秒减少100个并发用户数直到并发用户数减少为0时,负载测试结束。
结合响应时间,tps,活动线程监听器一起分析,可以看到在1分30秒左右的时候,响应时间突然飙升,用户数达到350个并发,这里可以认为是一个瓶颈点
五、如何快速的确定拐点
1、创建多个线程,每个线程数不同,逐渐递增
2、测试计划中,需要勾选独立运行每个线程组,勾选该选项的意义就是依次并发执行10、50、100、200线程,直到压测结束。
3、执行命令 jmeter -n -t E:\jmeter脚本\压测.jmx -l E:\jmeter脚本\聚合报告.jtl -e -o E:\jmeter脚本\webreport
4、分析测试报告
聚合报告如下,随着并发用户增加,平均响应时间在递增,报错率也在递增,TPS也随着用户数的增加和增加,到了500用户为最高点,1000并发用户反而降低
查看Response Times Over Time图表可以看到响应时间随着并发用户数递增,平均响应时间一直增加,当1000并发时,响应时间增加幅度最大
查看Transactions Per Second,从图表可以看出当并发用户从10递增到500,一直是递增趋势,然后500-1000,开始慢慢降低
查看 Hits Per Second,从图表可以看出当并发用户从10递增到500的时间段,每秒请求数一直是递增趋势,然后500-1000并发,请求数开始不增反降
得出结论,暂时不考虑其他因素,确定拐点就是500并发。
施压策略建议:
在实际的工作中,可能习惯性的高并发的去压,单台机器压测2000并发的也有见到过,这是不可取的。我们是为了找到系统最大处理瓶颈,这个需要一点点的并发往上加的,防止服务器太脆弱直接导致压跪掉是很有必要的。
通过很多性能测试案例,发现不需要用上万的用户并发去进行测试,只要系统处理业务时间足够快,几百个用户甚至几十个用户就可以达到目的。对于大型系统、业务量非常高、硬件配置足够多的情况下,5000用户并发就足够了;对于中小型系统,1000用户并发就足够了。
在做负载测试的时候,一般都是按照梯度施压的方式去增加虚拟用户数,而不是在没有预估的情况下,一次加几万个用户,交易失败率非常高,响应时间非常长,已经超过了使用者忍受范围内,这样做没有多大的意义。
如果觉得《jmeter 性能测试结果分析》对你有帮助,请点赞、收藏,并留下你的观点哦!