概述

在 jmeter 中,只要提到并发,99% 的同学立马想到线程组。需要多少并发就启动多少线程组,这已经成了大部分人的共识。这种理解方式很明显是把并发数和线程数的概念混淆了。线程组中不光有线程数,也有循环次数。然而大家在负载测试中都主动的忽略了循环的作用。jmeter 中的循环和 lr 中的迭代是一样的,都是为了模拟出压力,不要选择性无视它

实验

先列出下面两个需求,大家可以思考一下这两个需求在 jmeter 里面如何设置场景

需求 1:我有一个页面,需要测试一下最大支持多少用户并发?

此时要计算的是最大用户并发数,强调的是同时操作,也可以理解为同时发起请求
针对需求 1 我们可以通过 RPS 定时器或者阶梯加压线程组测试每秒最大的请求数(压测实战分析性能拐点

需求 2:查询功能,需要系统能够在 5 分钟内能完成 5000 笔查询业务,同时 90% 的用户响应时间不超过 3s。最大并发是多少?

此时不强调同时操作,而是强调业务量。也就是说不限制用户的操作时序,不考虑人的效率。把人当做机器,只要在 5 分钟内查询数满足 5000 笔即可。但是具体有多少用户才能在 5 分钟内查询 5000 次?它是由单次响应时间来决定的。这时就引入了一个经常被人讨论的公式:最大并发数=(单次响应时间 * 业务量)/总的业务时间。我的单次响应时间越快,用户每秒可点击的次数就越多,那么需求就越容易满足。

线程数和并发数

针对需求 2,我们如何在 jmeter 中设置场景?由上面的描述可以知道,我们可以计算出最大并发数。那么这个最大并发数对应的就是 jmeter 中的线程数。光有线程数不行,此时又引入了一个迭代的概念。假设单线程下,单次请求的平均响应时间是 200ms,那么这个单线程的请求 1s 内可以迭代 5 次。如果有 100 个线程,那么 1s 内就可以完成 500 笔业务。5 分钟内完成的业务数就是 5*60*500=15 万笔。回到我们需求 2,是不是远远超纲了?把线程数缩小,其实只需要 4 个线程,就可以在 5 分钟内超额完成 5000 笔业务了。4*5*5*60=6000

1-1
如图 1-1,勾选循环永远的意思就是不限制单位时间内的迭代次数,以此加载最大压力。
注:如果循环次数设置了固定值,那么下发那个持续时间的设置是无效的。线程组会优先根据你的固定循环次数去执行迭代。也就是说,固定循环次数的执行顺序优于持续时间!但是如果循环次数设置为永远,再设置持续的时间,那么就会根据你的持续时间去加载最大的压力。

事物完成线程组(TPS 线程组)

针对需求 2,jmeter 额外提供了一个线程组去满足它-- Arrivals Thread Group。在这个线程组中我们给予预期的业务量和业务时间,系统会自动启动线程去满足业务需求。

1-2
如图 1-2,表示我的预期 tps 是 50/s,在 2s 内达到预期值,同时保持这个 tps 运行 20s,那么 22s 内我的业务量是 22*50=1100

1-3
如图 1-2,最大的系统并发数(启动的线程数)是 319

总结

我们做性能测试,压力都是人为给予系统的。使用工具的目的也是为了模拟出用户的压力场景


↙↙↙阅读原文可查看相关链接,并与作者交流