JMeter之If Controller深究二
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包，但好些同學一提到這個，內心其實是抗拒的，或者覺得自己不行。