JMeter之If Controller深究二
宝路 人气:11.背景
接上文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包,但好些同学一提到这个,内心其实是抗拒的,或者觉得自己不行。
加载全部内容