jmeter-事务控制器与并发控制器与if控制器项目实践

前言

在做性能压测的时候,除了做单接口这种基准压测,我们还需要多接口串联的混合场景,比如打开小程序展示的首页,购物下单时的结算页。如果这些接口都是串行的,那就非常简单了,仅仅只需要创建事务控制器,将所有的接口放进去就行了。但是,事实上,这些接口并不都是串行的,有些是并行的,众所周知,jmeter的每个线程组请求是从上而下的,只有上一个请求成功了才会进行到下一个请求,并不能做到并行处理,所以,针对这个场景,该怎么解决?
在这里插入图片描述

解决方案

使用并发控制器与if控制器解决,并行控制器可以让线程组下的请求同时发出,if控制器可以作为逻辑判断,判断上一个步骤是否成功,如果出错则不请求。

1、并发控制器
1.1 安装

Options>Plugins Managers>搜索 Parallel Controller勾选进行安装,如下所示:

在这里插入图片描述

1.2 添加

添加并发控制器
在这里插入图片描述
勾选Generate parent sample,这样生成的报告才能看到该事务

1.3 验证

怎么验证线程是不是同时并发的呢,使用表格查看结果
在这里插入图片描述
分别创建两个并发控制器,一个加两个请求,另一个加四个请求,结果如下,可以看到两个控制器下的线程请求的时间几乎都一致的。

在这里插入图片描述
注意:并发控制器下不能设置事务控制器,也不能再次设置并发控制器,否则会报错
但事务控制器下可以设置并发控制器

2、if控制器
2.1 添加使用

在这里插入图片描述
使用以下参数来判断上一个控制器或者线程是否通过,通过则执行,不通过则不执行。

${JMeterThread.last_sample_ok}

2.2 验证

记得勾选Generate parent sample
如果不用if控制器,结果如下:即使第一个控制器里的某个请求错误,第二个也还是会请求

在这里插入图片描述
查看并行控制器的最大时间:load time

在这里插入图片描述

加了if控制器,则不会请求第二个控制器了
在这里插入图片描述

实践
场景描述

进入小程序后,首页加载分为三个步骤,第一个步骤是查询用户,共有一个接口。第二个步骤是查询店铺与经销商,共有两个接口,第三个步骤查询商品,共有四个接口,每个步骤都是上下关系。

脚本编写

模型:

事务控制器:
 	if控制器:
       并发控制器:

在这里插入图片描述

请求参数计算:

业务要求tps100,我们统计出单个事务请求时间为400ms,则jmeter的需要线程数为100/(1000/400)=40线程,(这个只是模糊计算数据),所以,为了更好地观看数据,我们可以设置大于一至两倍的线程数。

此处我们使用阶梯式压测:

总共50个线程,每个步骤新增10个线程,执行15s。

注意,并发控制器需要勾选Generate parent sample,要不然事务控制器统计的是不是并发控制器最大时间

在这里插入图片描述

请求结果分析

tps走势
在这里插入图片描述
线程数走势
在这里插入图片描述
从上面的走势可以看出,42s左右的时候,线程数还是递增的,不过,tps却没有很高的递增,说明,tps已经出现了瓶颈,根据tps走势大概可以看出tps是在65徘徊,不超过80tps

聚合报告:
tps是平均值,一般我不以这个为准。报告也显示了,出错率0.01%。刚好符合999原则。
在这里插入图片描述

最终结果是:该首页页面事务支持的tps在65左右,最高不超过80tps。

疑问

线程数是否还需要加,继续加压只会让响应时间加长,报错率更高,完全没有意义了。

  • 1
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值