0


jmeter线程数与用户数、tps的认知误区

误区一:jmeter 线程数就是用户并发数

案例:

业务需求:要求tps达到500/s,1000并发数2秒完成处理

大部分的测试同学是这样压测的,将jmeter的线程数直接从200、300、400这样调试到tps出现拐点。如果400线程符合了,就说明支持400的用户数。
更有部分同学验证第二点的时候,直接压测1000个线程

误区:
1、正常的压测过程是,先压测出一个线程下的tps,然后根据以下的公式算出大概需要的jmeter线程数,以上的例子中,如果一个线程下的tps为10tps。那你的jmeter 线程数只需要50个线程就够了。完全不需要200以上,那是在浪费资源

线程数 = 业务tps / 单个线程tps

2、jmeter 的虚拟用户数大小不能说明支持的用户数是多少,这里jmeter 的用户数只代表jmeter的压力大小而已,支持的用户数跟你的tps 以及用户的请求次数有关。比如这里的500tps。如果业务场景是一个用户只操作一次接口,那就说明是这个接口能支持500的用户数,这里指的是支持最小的用户数。如果这个接口,1万个用户数,只有1000个是同时操作,那就是这个接口的并发度只有十分之一,那这个接口的支持用户数就是,500tps/0.1 = 5000,也就是支持5000的用户数。

.支持最大并发用户数=TPS /并发度

3、那什么时候下,jmeter的线程数就是支持的用户数呢。需要满足两个点,第一,jmeter 脚本设置循环1次,第二,单接口。

误区二:jmeter 线程数不断增加

在真实压测过程中,我们会发现,当我们压测符合业务需求的时候,我们还会不断的去加压去压测。直接把服务器压到90%的cpu。很多人理解这样的场景是为了验证:如果用户超出了当前评估的用户数,系统会不会挂掉。
根据以下的公式(只代表是这种关系,不能完全等价该公式),你的tps不变的情况下,线程数不断增加,响应时间是肯定是增加的,以致完全超时,所以当你的报告发现大量的超时时,你可以考虑是不是线程数过大了。所以,压测到最优的tps后,就不需要压测了,哪怕最后你的线程数只需要100个线程。有些人很担忧,100个线程,这压力哪够呀,加到1000一步步试。最后压测下来,发现根本没啥区别,除了响应时间大了一点。那就是在浪费你的时间成本。当然这个100线程能体现最优的tps。

tps= 1000/响应时间 * 线程数

那我们怎么解决这个用户是否超量带来的系统问题呢。本质上是业务的需求,也就是说,我们首先怀疑的是,这个tps是否满足了用户数超量的情况。


本文转载自: https://blog.csdn.net/LANNY8588/article/details/120390534
版权归原作者 小生测试 所有, 如有侵权,请联系我们删除。

“jmeter线程数与用户数、tps的认知误区”的评论:

还没有评论