IT教程 ·

JMeter之If Controller深究二

Robot Framework自动化测试框架核心指南-如何使用Java编写自定义的RobotFramework Lib,RobotFramework自动化测试框架-Selenium Web自动化(二)关于在RobotFramework中如何使用Selenium很全的总结(上)

1.背景

接上文,在上文中提到压测采纳的是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解释。那末RhinoNashorn 有啥区分呢?

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),所以不发起运用。

有的同砚大概又说了,我的测试场景触及生意业务就是比较庞杂,假如剧本设想的不够强健,压测过程当中错误信息不轻易定位。这个确实是个问题,宝路也遇到了,在中所说起的问题,实在不光if 逻辑控制器这个一个问题。剧本中每一个sampler 都用了JSR223后置处理器来猎取返回报文,再截取返回报文症结域做断言。

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

有时候,剧本搞的过于庞杂也不会什么功德。。。。那就没有解决方案了么?实际上是有的,那就是本身写jar包,但好些同砚一提到这个,心田实际上是抗拒的,或许以为本身不可。

GO语言slice详解(结合源码)

参与评论