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包，但好些同学一提到这个，内心其实是抗拒的，或者觉得自己不行。