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