jmeter 面向目标的性能场景如何设计

说到 jmeter 设计性能场景,大家是不是第一想到的就是 jmeter 的普通线程组进行性能场景设计?

jmeter 普通线程组,对通过改变并发用户(线程数),找出或验证性能指标还是非常简单、方便的。

但是在企业中,做性能测试,就是这么简单的找性能指标就够了吗?显然不是。会经常遇到,通过确定定义的某个预期性能指标值,要你验证实际的性能情况是否能够超过预期期。比如:期望某个接口系统的处理能力不低于 200 次/秒,问你,这样的场景,你如何设计?

相信,有些同学,天生对性能测试感到畏惧,看到这样的问题,就不知道如何下手的。其实,这个题目很简单,就是看服务器对某个接口的 TPS 值是否能大于等于 200,就可以了。系统处理能力,说的就是我们性能测试中的 TPS。只要设计一个目标场景 TPS 能超过 200,而不报错,响应时间也在可接受的范围内就可以了。

但,问题是,这个目标场景要怎么设计呢?

有做过性能测试的同学可能会知道,在 loadrunner 中,有“手动场景”和“面向目标场景”,所以用 loadrunner 可以很简单实现。但是 jmeter 不一样,平常大家用的基本全都是“手动场景”类型,很少有同学懂得 jmeter 的面向目标场景该如何设计。

今天,我们就来给大家分析分析,jmeter 如何做面向目标的场景设计。

用 jmeter 工具,说到 TPS,肯定很多人就会想到吞吐量,就会在吞吐量上找突破口。通过一通百度,和一段时间自己的学习研究,肯定会发现,用一个“常数吞吐量定时器 Constant Throughput Timer”可以实现预设一个固定的 12000 的值(因为在这个定时器中,单位是每分钟),从而实现目标 200TPS 的诉求。

image.png

是的,这个定时器,确实就是可以实现这样一个目标。但是,接下来的问题是,用普通线程组,要设置多少并发用户,才能让这个 TPS 值达到呢?并发用户(线程数)设置小了,这个目标达不到,并发用户(线程数)设置大了,不能找出真实的 TPS 值。一个一个并发用户数去猜,时间浪费了,效率太低。这个又该怎么做呢?

今天在这里,柠檬班的 Allen 老师给大家讲一个方法思路。

大家可以去下载 jmeter 的插件管理器,然后再利用插件管理器,下载 jpgc 插件。然后添加 bzm - Arrivals Thread Group 线程组。

如果不知道下载插件,不会使用插件管理器下载 jpgc,可以搜索柠檬班,咨询柠檬班老师。

参考如下图设置:

image.png

第 1 个,Target Rate 设置为目标 12000,因为时间是分钟;第二个 RampUpTime 加速时长,随自己设置;第三个 Ramp-Up Steps Count 总共加速次数,随自己设置;第四个 Hold Target Rate Time 达到目标后,持续运行多长时间,随自己设置。

Tips:在图表 graph 下面,有个 Time Unit 单选,分钟\秒,切换后,上面的设置单位会发生变化,注意切换后,要按照需求更改相关设置数据。

大家可以看到,整个设置过程,完全没有设置并发用户数。也就是说,为了达到 200TPS 值,并发用户数,完全是在运行过程中动态调整变化的。我们只需要再添加 Active Threads Over Time 监听器,查看运行过程中,实时的并发用户数,再添加 Transactions per Second 监听器, 查看运行过程中,实时 TPS 值,我们就可以**通过这两个监听器,实时对比看到,在某个时间点 TPS 达到或超过 200,此时活跃的并发用户的值,就知道系统在多少并发用户数时,能满足预期目标**;如果发现运行过程中,已经报错,或相应时间超长,TPS 却始终都无法达到预期的 200,哪就说明,该接口无法达到预期目标。

是不是,突然发现,事情变得很简单了呢?

如果你还想知道具体是多少个并发用户(线程数)让接口达到 200TPS,我们再用一个 Stepping Thread Group,如下图配置:

image.png

实时观察活跃线程数和 tps 值,就能比较准确的找到并发用户数量了。

好了,jmeter 面向目标的场景设计,就给大家讲到这了,你是否已经掌握了呢?

更多有趣有料的软件测试知识,欢迎关注 柠檬班 微信公众号!

参考源代码

1 操作
Allen 在 2020-08-06 16:23:59 更新了该帖
回帖
请输入回帖内容 ...