其他分享
首页 > 其他分享> > 性能测试连载 (8)-jmeter 实战分析并发、RPS、RT 公式换算

性能测试连载 (8)-jmeter 实战分析并发、RPS、RT 公式换算

作者:互联网

https://pan.baidu.com/s/1df1HDkFzChYNAbsSazizpw 提取码:hhn7
jmeter 全系列文档资料

https://pan.baidu.com/s/1rD3H9EGbu0u11E8ofpAl3A 提取码:8q65
性能测试初级到高级系列资料

前提

在阿里云 PTS 上有一篇文章讲解 VU、RPS、RT 换算,中间有一个公式介绍如下图

 

 

并发数 = RPS * 响应时间

于是我在本地做了几次实验,试图验证一下公式的准确性,实验网站 www.baidu.com

第一次实验

100 线程,一次迭代,启动时间 1s,线程组和聚合报告如图所示

 
 

 

 
从结果可以看出,100 并发/s,一次迭代,平均响应时间是 68ms
如果根据上面公式来看的话
RPS = 并发数/响应时间 = 100/0.068 ,大约是 1470/S
但是我们在线程组中可以看出,预置的 RPS 是 100/S
差距有点大哦~~~眉头紧锁,思考中
 

第二次实验

100 线程,持续迭代,1s 内启动线程,持续运行 10s。线程组和聚合报告如图所示。
 

 
 

 

从聚合报告可以看出来,平均 TPS= 1303。那么我们可不可以就认定这个 TPS=RPS 呢?
简单计算一下就知道了。
图中可以看出我们的平均响应时间是 72ms,那么 1 秒内大约能迭代 14 次。100 个线程下,一秒内大约能发送 1400 个请求。
因此我们的 RPS 大约是 1400/S
这样就能看出来,一秒内发送 1400 次请求,但是 1s 内只有 1300 个请求能响应完毕
我们再反向验证一下并发数
并发数 = RPS* 响应时间,1400* 0.072 等于 100.8,和线程组里面设置的并发数几乎相同。
如果我们用 Throughput=RPS 去反向验证
并发数 = RPS* 响应时间,1303* 0.072 等于 93,和线程组里面设置的并发数就有一些差距了。
这两次实验得出的结论:在持续迭代下,由于样本充足,所以公式成立。但是RPS!= TPS
 

第三次实验

这次我们直接加上 RPS 定时器,通过精准的 RPS 来验证公式
我们让 200RPS 保持 1 分钟,查看聚合报告
 

 
 

 

首先我们就能看出,在 200RPS 下,平均 TPS 只有 172!
其次,平均并发数 = 200*0.047 = 9.4   意味着我只需要 9 个线程,就可以在一秒内释放 200RPS 的压力
可以算出每个线程每秒的请求数是 200/9.4 =21,也就是一个线程一秒内最大迭代 21 次
反推每个请求的响应时间 大约 是 1000/21 大约是 47ms 
前后验证的结果都相符!

第四次实验

这一次我们直接在线程组中设置刚刚 20RPS 下得出的平均并发数值 9,反向推断出 RPS 的准确性

 

 

计算一下 RPS = 9 /0.043 约等于 209
 因为线程组只能设置整数,所以会和实验三有一些误差,不影响测试的准确性
 结尾语:从几次实验结果来看,在样本充足的情况下,公式是没有问题的

TesterHome 为用户提供「保留所有权利,禁止转载」的选项。 除非获得原作者的单独授权,任何第三方不得转载标注了「原创声明:保留所有权利,禁止转载」的内容,否则均视为侵权。 具体请参见TesterHome 知识产权保护协议

标签:RT,RPS,迭代,响应,并发,线程,100,jmeter
来源: https://www.cnblogs.com/minfanblog/p/14754916.html