亲宝软件园·资讯

展开

JMeter之If Controller深究二

宝路 人气:1

1.背景

接上文JMeter之If Controller深究一,在上文中提到压测采用的是JMeter3.1版本,本篇继续深究。基本确定问题原因后,宝路这边又做了不同版本的JMeter对比实验,这次加入了自己常用的5.1.1版本(目前官方最版版本5.2.1)。

2.实战

压测机器配置(台式机):

测试脚本一:

测试脚本二:

两个脚本的唯一区别就是其中一个脚本采用了if逻辑控制器

  • JMeter3.1测试结果(测试脚本一):

TPS曲线图(100vu):

RT曲线图(100vu):

从TPS、RT图看出,100vu下曲线都非常平稳,此时压力机CPU消耗约7%,宝路这边还做了100vu下其他RT(可在脚本设置)的压测,测试结果是一样的,由于篇幅有限就不贴图了。

  • JMeter3.1测试结果(测试脚本二):

TPS曲线图(100vu):

RT曲线图(100vu):

恩,从图就可以看出TPS、RT曲线波动非常明显,压测过程中压力机CPU消耗约50%,较第一次高了约43%。此次执行的脚本与“测试脚本一”就多了一个if逻辑控制器而已,其余配置均一样。

咱们继续实验,将上面的JMeter换成5.1.1进行相同场景压测。

  • JMeter5.1.1测试结果(测试脚本一):

TPS曲线图(100vu):

RT曲线图:

从图可以看出,压测脚本一(不带if逻辑控制器),JMeter5.1.1 与 JMeter3.1 压测结果几乎一致。

  • JMeter5.1.1测试结果(测试脚本二):

TPS曲线图:

RT曲线图:

恩?有点意思。。。。压测脚本二(带if逻辑控制器)JMeter5.1.1测出的结果可以分析出TPS与RT关系明显不正常, 再看看JMeter3.1测试出的结果也不稳定。

此时,只有去分析源码了,看过源码还真是发现了问题:宝路对比了5.1.1与JMeter3.1的源码发现主要区别:

JMeter3.1

JMeter5.1.1

从上图可以看出:3.1中的USE_RHINO_ENGINE默认值是true,而5.1.1中默认是false。

宝路在jmeter.properties找到了javascript.use_rhino属性:

将javascript.use_rhino属性改成false,对JMeter3.1测试结果(测试脚本二)进行了复测:

TPS曲线图:

RT曲线图:

这就与JMeter5.1.1测试结果(测试脚本二)相吻合佐证了jmeter.properties中官方对javascript.use_rhino注释。那么Rhino跟Nashorn 有啥区别呢?

Nashorn 一个 javascript 引擎。从JDK 1.8开始,Nashorn取代Rhino(JDK 1.6, JDK1.7)成为Java的嵌入式JavaScript引擎。Nashorn完全支持ECMAScript 5.1规范以及一些扩展。它使用基于JSR 292的新语言特性,其中包含在JDK 7中引入的 invokedynamic,将JavaScript编译成Java字节码,与先前的Rhino实现相比,这带来了2到10倍的性能提升。

   性能测试脚本不建议搞的太复杂,这样会较少不要的性能开销。从压测结果也能看出:仅仅是加了一个if逻辑控制器,压力机的CPU消耗翻了7倍。比较简单做法的就是sampler加响应断言,对于前后交易依赖性比较强的交易,如果前交易失败了,可以直接跳出本次迭代,进行下次迭代。

从性能实验结果还能看出,即使采用了Nashorn引擎,性能照样存在一定问题(可以理解成bug),所以不建议使用。

有的同学可能又说了,我的测试场景涉及交易就是比较复杂,如果脚本设计的不够强壮,压测过程中错误信息不容易定位。这个确实是个问题,宝路也遇到了,在JMeter之If Controller深究一中所提及的问题,其实不光if 逻辑控制器这个一个问题。脚本中每个sampler 都用了JSR223后置处理器来获取返回报文,再截取返回报文关键域做断言。

嗯?JSR223后置处理器这有啥问题呢。。。。高并发下,非常容易PermSize内存溢出。

有时候,脚本搞的过于复杂也不会什么好事。。。。那就没有解决方案了么?其实是有的,那就是自己写jar包,但好些同学一提到这个,内心其实是抗拒的,或者觉得自己不行。

加载全部内容

相关教程
猜你喜欢
用户评论