JMeter之If Controller深究一
1.背景
大家最近還好麼，截止目前新型冠狀病毒累計確診病例已超7萬4千多例，希望大家無論是在家辦公還是單位辦公，一定要注意自我防護。今天跟大家分享一下，最近一次真實生產壓測遇到的問題，如題：if controller，本次它是主角。
2.目的
下面進入正題：本次主題是與If邏輯控制器有關，相信有些同學對這個邏輯控制器使用非常熟練。那麼這個邏輯控制器到底有什麼問題呢？本期寶路就來分享下一次真實生產壓測遇到的坑。
偽指令碼結構圖：
從指令碼結構圖看出：邏輯性很強，前交易成功才會執行後交易，判斷是通過邏輯控制器來實現的。感覺指令碼很完美。。。然而在壓測過程中卻出現了不合乎常理的現象。生產壓測結果：
TPS趨勢圖：
RT趨勢圖：
恩？RT、TPS趨勢圖對應關係不對啊。。。。壓測過程中TPS呈現逐漸下降趨勢，RT趨於平穩，繼續增加併發使用者數，RT變化不明顯，TPS仍呈現逐漸下降趨勢。（正常現象：隨著併發使用者數增加TPS增長，響應時間不變或略有增長；或TPS增長不明顯，響應時間增長明顯）
開發人員從伺服器的日誌分析得出：各交易耗時很短，伺服器壓力並不大。這就有點尷尬了，於是乎就開始了各種排查， 最後由於時間緊迫，最後被迫使用LR11現場編寫指令碼進行壓測。恩？LR11壓測卻沒這個現象，然而LR11並不支援JDK1.7，這也就導致部分重點交易未壓測。
回去之後，寶路這邊就開始分析到底是什麼原因導致這個奇怪的現象。先想著看看能不能復現，如果能復現問題就好解決了。
思路：保持指令碼整體結構不變，採用JMeter官方自帶的Java Sampler代替原指令碼中的sampler，當然如果能自己手寫Java Sampler也可以不採用官方自帶的（JMeter均採用相同的3.1版本）。大家要自己寫Java Sampler的話，可以參考寶路的寫的：
為了簡單快速驗證，我先替換一個請求進行驗證（其餘請求暫時遮蔽），測試結果：
TPS趨勢圖：
RT趨勢圖：
哈哈，復現了。。。。緊接著，我把if邏輯控制器禁用掉並將下面的Sampelr複製到f邏輯控制的上層，大家自行腦補，就不佔圖了，測試結果如下：
TPS趨勢圖：
RT趨勢圖：
從複測結果可以出：TPS、RT曲線 非常穩定。對比兩次結果可以看出，問題出在了if邏輯控制器。一開始我懷疑是不是我指令碼中的if邏輯控制器使用方法有問題，檢查了下，也網上搜了搜相關資料，沒啥毛病啊。。。。。
此時給我的感覺就是JMeter3.1版本的if邏輯控制器有嚴重的效能問題。下篇文章給大傢俱體分析if邏輯的原始碼及效能實驗驗證。