1. 為什么需要 Flow Control Action一個常常被低估的流量控制組件做性能測試的朋友應(yīng)該都遇到過這種場景線程組里明明配置了并發(fā)用戶數(shù)但實際跑出來的請求節(jié)奏完全不受控。一會兒腳本跑到某個接口直接炸掉一會兒整個線程組停不下來調(diào)試的時候想看某一段請求的輸出結(jié)果腳本一口氣全跑完了日志滾動得像瀑布一樣。在 JMeter 里我們通常用定時器Timer來控制請求之間的間隔用邏輯控制器Logic Controller來控制分支和循環(huán)但真正到了要精確卡住某個節(jié)點的時候大家的第一反應(yīng)反而是去翻各種自定義 BeanShell 腳本或者 JSR223 組件。其實 JMeter 內(nèi)置了一個非常輕量、非常穩(wěn)的組件——Flow Control Action原名 Flow Control Sampler老版本的譯名是流控制采樣器專門用來干這個事兒。Flow Control Action 本質(zhì)上是一個不產(chǎn)生任何實際請求的空跑組件它有三種核心行為暫停Pause當(dāng)前線程指定的時長、或者直接中斷Stop/Stop Now整個流程。它解決的問題非常直接當(dāng)你需要讓某個線程在腳本運行的某個階段停下來等一等或者當(dāng)某些業(yè)務(wù)條件不滿足時優(yōu)雅地終止線程組的后續(xù)操作Flow Control Action 是最干凈的手段。寫這篇文章的原因也很樸素。我以前在項目里看到很多同事要么把所有暫停邏輯全部塞進固定定時器里要么為了實現(xiàn)動態(tài)暫停去寫一大段 Groovy最后踩了一堆奇奇怪怪的坑。所以我把 Flow Control Action 的用法、適用場景、參數(shù)細節(jié)和排查經(jīng)驗整理出來給做接口測試和性能測試的同行一個可以直接抄作業(yè)的參考。這篇文章適合剛接觸 JMeter 的測試新人也適合已經(jīng)寫了很久腳本、想簡化流程控制的同學(xué)甚至你對 BeanShell 控制流程已經(jīng)駕輕就熟也值得看一眼因為原生組件永遠是維護成本最低的方案。2. 核心原理解析不要把它當(dāng)成一個普通采樣器2.1 執(zhí)行機制與組件定位Flow Control Action 這個組件的位置很特殊它在 JMeter 的邏輯控制器分類下但它其實更接近一個動作或令牌。在 JMeter 的測試計劃樹里你可以把它掛在線程組下的任意位置也可以放進 If Controller、While Controller、Transaction Controller 里面甚至可以放在采樣器前后用來調(diào)整節(jié)奏。它的執(zhí)行機制并不復(fù)雜當(dāng)當(dāng)前線程運行到這個組件時JMeter 會根據(jù)你的配置執(zhí)行對應(yīng)的動作然后決定是繼續(xù)往下走、等待一段時間再往下走還是直接終止這條線程乃至整個測試計劃。關(guān)鍵點在于它本身不會發(fā)送任何協(xié)議請求不會消耗 TCP 連接也不會產(chǎn)生業(yè)務(wù)流量它就是一個純控制節(jié)點。這種設(shè)計的妙處在于控制邏輯和業(yè)務(wù)邏輯分離了。很多新手喜歡用一個返回特定標(biāo)記的取樣器來充當(dāng)暫停的角色比如請求一個不存在的資源然后靠響應(yīng)時間差來變相實現(xiàn)等待。這種方式特別不穩(wěn)因為網(wǎng)絡(luò)抖動、服務(wù)端處理快慢都會影響節(jié)奏。Flow Control Action 是本地 JVM 層面的操作不依賴網(wǎng)絡(luò)精度和穩(wěn)定性完全不一樣。另外一個容易忽略的點Flow Control Action 是在當(dāng)前線程的作用域內(nèi)執(zhí)行的。也就是說如果你在一個線程組里放了 100 個并發(fā)用戶每個用戶跑到這里都會執(zhí)行一次這個組件。所以如果你想要所有線程統(tǒng)一暫停多少秒你必須在所有線程的公共位置安排它或者結(jié)合其他機制來實現(xiàn)具體方法我在后面實戰(zhàn)部分會專門展開。2.2 與其他控制/等待方案的邊界對照要理解 Flow Control Action 的價值最好的辦法是把它和幾個容易混淆的方案放在一起對比。我在實際帶項目的時候經(jīng)常發(fā)現(xiàn)有人搞混這幾樣?xùn)|西導(dǎo)致腳本節(jié)奏完全不可控。第一個容易混淆的是固定定時器Constant Timer。Constant Timer 的作用是在它所在的 Sampler 之前插入一個固定延遲它是作用于是下一個請求之前的等待時間。而 Flow Control Action 的 Pause 動作是當(dāng)前線程立即停止運行 Duration 指定的時間然后再繼續(xù)執(zhí)行后續(xù)節(jié)點?？雌饋硇Ч愃频幸粋€本質(zhì)區(qū)別定時器的等待時間是在每個子采樣器之前獨立生效的如果你把它放在某個 Controller 里它會影響 Controller 下所有子節(jié)點的前置等待而 Flow Control Action 是強制中斷當(dāng)前線程的調(diào)度打斷之后回來是從它的下一個節(jié)點繼續(xù)跑。簡而言之定時器是推后采樣器的開始時刻Flow Control Action 是暫停當(dāng)前線程的執(zhí)行流這對調(diào)試和復(fù)雜腳本的流程控制差異巨大。第二個容易混淆的是 JSR223 里的Thread.sleep()。很多老腳本會用 Beanshell 的Thread.sleep(3000)來模擬暫停。這個問題在于如果你的 JSR223 組件配置不當(dāng)比如選了 Beanshell 而不是 JSR223 Groovy在高并發(fā)下會因為腳本解釋器生成對象的大量 GC 導(dǎo)致嚴(yán)重的性能損耗。Flow Control Action 是原生編譯的組件不存在腳本解釋器的開銷你在壓測腳本里放幾百個 Flow Control Action對線程調(diào)度的開銷也遠小于寫幾段 Beanshell。第三個方案是使用邏輯控制器中的 Interleave Control、Random Control 等來實現(xiàn)分支選擇但它們解決的問題是流程分發(fā)不是暫?；蚪K止。為了讓你一眼看清楚差異我整理了一個簡單的對照表方便在團隊里評審腳本時使用方案核心作用是否產(chǎn)生網(wǎng)絡(luò)請求性能開銷適用場景Constant Timer在采樣器之前固定延遲否極低模擬固定思考時間、限流Flow Control Action暫停當(dāng)前線程或終止線程組否極低動態(tài)等待、條件中斷、調(diào)試觀察Beanshell Thread.sleep直接阻塞線程否高腳本解釋器臨時調(diào)試不推薦用于正式壓測自定義取樣器兜底用真實請求消耗的時間變相等待是中非常不推薦屬于錯誤實踐2.3 為什么說它是優(yōu)雅的控制手段前面提到了多種方式但為什么 Flow Control Action 是優(yōu)雅的控制手段我覺得體現(xiàn)在三個層面。第一可維護性高。它就放在測試計劃里屬性和參數(shù)一目了然測試新人拿到腳本看這個組件就知道這里是在暫停 3 秒或者終止當(dāng)前線程。相比一行腳本if (vars.get(flag).equals(1)) { Thread.sleep(1000); }它直觀太多不用打開腳本編輯器去逐行讀代碼。第二粒度可組合。Flow Control Action 可以配合條件控制器實現(xiàn)復(fù)雜的流程編排。比如在登錄接口之后加一個 If Controller判斷響應(yīng)里是否返回了某個 token 字段如果沒返回就執(zhí)行 Flow Control Action 直接把這條線程終止。這樣既不用在業(yè)務(wù)請求里加斷言來中斷也不用寫復(fù)雜的 Groovy 代碼。這種組合方式讓測試腳本更像一個可視化的狀態(tài)機每一步都清清楚楚。第三調(diào)試體驗極佳。很多做壓測的同學(xué)在調(diào)試腳本時最痛苦的是腳本執(zhí)行得太快根本來不及看某個數(shù)據(jù)是否寫入成功或者某段邏輯是否執(zhí)行正確。把 Flow Control Action 的 Action 選為 PauseDuration 填個幾千毫秒插在關(guān)鍵采樣器后面腳本就能像 debug 模式一樣走走停停。調(diào)試完成之后把它摘掉或者改小 Duration就又恢復(fù)成跑全速的模式。這種體驗遠勝于在代碼里打斷點或鋪日志。3. 參數(shù)逐項拆解從 Target 到 Action一次性搞懂配置邏輯3.1 Target 參數(shù)單線程還是全線程組Flow Control Action 的配置面板上有兩個核心參數(shù)Target 和 Action。我在實際評審腳本時發(fā)現(xiàn)很多人壓根不看 Target 這個下拉框直接保持默認(rèn)。這個坑特別大因為 Target 決定了你這個組件要影響的范圍。Target 有兩個選項Current Thread當(dāng)前線程All Threads全部線程。選擇 Current Thread 時組件只對運行到它所在的這條線程產(chǎn)生作用。比如線程組配置了 50 個用戶那么這 50 個用戶分別跑到這里各自獨立執(zhí)行這個動作。如果動作是 Pause那么這 50 個用戶每個都會暫停同樣的 Duration然后各自繼續(xù)跑。這個選項適合做每個用戶自己的思考時間或每個用戶獨立的中斷判斷。選擇 All Threads 時組件會讓當(dāng)前測試計劃中所有線程組的線程都執(zhí)行這個動作。注意這里不只是當(dāng)前線程組是全部線程組。這意味著只要你有一個測試計劃里包含多個線程組其中一個觸發(fā)了 All Threads 的停止動作其他線程組的線程也會被中斷。這個行為很容易被忽略尤其是壓測場景里同時啟用了多個線程組做不同業(yè)務(wù)模塊的并發(fā)時一個組件突然 stop 掉了所有線程排查半天才發(fā)現(xiàn)是 Target 選錯了。我的建議是絕大多數(shù)場景選 Current Thread。All Threads 只在明確需要全局熔斷的場景使用比如某個依賴的底層服務(wù)直接不可用你想快速停止整場壓測這時候 All Threads Stop 就有用。不過這種場景我更推薦用監(jiān)控系統(tǒng)或命令行參數(shù)去控制而不是把控制邏輯寫死在腳本里原因后面講。3.2 Action 參數(shù)Pause、Stop 與 Stop Now 的細微差別Action 下拉框有四個選項Pause、Stop、Stop Now、Continue。上一句可能有人覺得 Continue 和沒放這個組件有什么區(qū)別我單獨解釋。Pause 是暫停當(dāng)前線程暫停時長由下方的 Duration 字段決定單位是毫秒。暫停結(jié)束后當(dāng)前線程會繼續(xù)從組件所在位置的下一條記錄開始執(zhí)行。請注意Pause 只對線程有效它不會取消任何已經(jīng)排隊等待的定時器也不會重置連接池狀態(tài)。它是純粹的線程阻塞操作。Stop 是溫和停止當(dāng)前線程當(dāng) Target 為 Current Thread 時或測試計劃所有線程當(dāng) Target 為 All Threads 時。溫和停止的含義是JMeter 會先停止啟動新的請求然后等待當(dāng)前正在執(zhí)行的采樣器完成最終才終止線程。如果在壓測過程中調(diào)用 Stop你不會立刻看到線程數(shù)歸零而是會看到線程逐步減少直到當(dāng)前活躍的請求跑完。Stop Now 是立即停止。它會中斷當(dāng)前正在執(zhí)行的采樣器直接終止線程整個測試計劃立刻停止。Stop Now 適用于一個確認(rèn)出問題的場景比如發(fā)現(xiàn)腳本參數(shù)化配錯了大量請求在打錯誤的數(shù)據(jù)再繼續(xù)跑下去只會污染監(jiān)控數(shù)據(jù)。這時候使用 Stop Now 能最大程度減少無效流量的產(chǎn)生。Continue 則是什么都不做直接放行。有同事問我既然什么都不做為什么還要提供這個選項有沒有想到它是干什么的其實它有它的場景。在分布式壓測時如果你通過屬性變量${__P()}動態(tài)控制某個 Flow Control Action 是執(zhí)行 Pause 還是 Continue那么 Continue 就是一個開關(guān)關(guān)閉的占位行為。比如你在遠程控制批次執(zhí)行時通過命令行傳入-Jaction.modecontinue這個組件就相當(dāng)于不存在而腳本不用改任何地方。Stop 和 Stop Now 的區(qū)別可以用一個比喻Stop 像你讓正在聊天的同事把話說完再下班Stop Now 像你在火警響起的瞬間直接拉著他跑。大多數(shù)日常調(diào)試場景Stop 就夠了但是當(dāng)你確信腳本本身已經(jīng)不可信同時你不想看到堆成山的錯誤日志時Stop Now 更合適。關(guān)于 Pause 的 Duration 參數(shù)我需要額外提醒一個單位問題界面寫的是毫秒不是秒。很多從 LoadRunner 或者其他壓測工具轉(zhuǎn)過來的朋友習(xí)慣性填了個 5發(fā)現(xiàn)腳本瞬間就跑完了還以為是沒生效。另外 Duration 支持 JMeter 函數(shù)所以你可以寫${__P(pause.duration,1000)}這樣在命令行執(zhí)行時就能通過參數(shù)動態(tài)調(diào)整暫停時長不用反復(fù)改腳本。3.3 作用域與放置位置的邏輯推演理解 Flow Control Action 的第三個關(guān)鍵點是作用域它放在測試計劃的哪個位置決定了它會影響到哪些后續(xù)節(jié)點。如果你把它放在線程組下、所有采樣器的前面那么每個用戶的第一件事就是先執(zhí)行這個動作。假設(shè)你配了 100 個用戶每個用戶啟動后先暫停 2 秒再用 ramp-up 拉長啟動時間整體上就會形成一個分批啟動的效果而不是所有用戶抵達測試計劃后就立即發(fā)請求。這在模擬系統(tǒng)預(yù)熱、Tuxedo 系統(tǒng)啟動或者數(shù)據(jù)庫連接池冷啟動場景時很實用。如果你把它放在某個事務(wù)控制器Transaction Controller的末尾那么它只影響這個事務(wù)內(nèi)部的執(zhí)行但要注意 Transaction Controller 默認(rèn)會生成一個總的事務(wù)采樣時間如果里面插入了暫停這個暫停時間會被計入整個事務(wù)的響應(yīng)時間。如果你把 Flow Control Action 放在 Similar Transaction 生成器外面比如掛在邏輯控制器的同一個層級那么它就不會干擾事務(wù)響應(yīng)時間的統(tǒng)計。如果放在 If Controller 內(nèi)部則可以通過判斷條件來動態(tài)決定是否執(zhí)行暫?；蛲Ｖ?。舉個實際的例子壓測登錄接口時某一次響應(yīng)返回了異常狀態(tài)碼比如賬號被鎖定此時你希望當(dāng)前線程不再繼續(xù)跑后續(xù)的下單、支付等請求立刻停止當(dāng)前線程以便執(zhí)行業(yè)務(wù)終止邏輯。那么你就可以在登錄采樣器之后加一個 If Controller條件表達式判斷變量的值匹配失敗就執(zhí)行 Flow Control ActionTarget 選 Current ThreadAction 選 Stop。關(guān)于作用域還有一個很容易和線程組專屬搞混的地方Flow Control Action 默認(rèn)是只對它所在的線程組的線程生效還是跨線程組答案取決于 Target。如果你選 Current Thread那嚴(yán)格限定在觸發(fā)它的那條線程。如果你選 All Threads它會影響測試計劃中的所有線程組。因此你不用太擔(dān)心誤傷其他線程組的問題只要不輕易選 All Threads 就行。4. 實戰(zhàn)場景拆解把 Flow Control Action 放進真實腳本里4.1 場景一模擬用戶思考時間實現(xiàn)動態(tài)多維壓測最常見的用法是模擬用戶思考時間。但很多人會直接加一個 Constant Timer固定 3 秒這其實只是最簡單的靜態(tài)模擬。真實的用戶行為是分布式的有的用戶看完頁面馬上點了下一步有的用戶可能發(fā)呆十幾秒。用固定定時器去模擬測出來的吞吐量指標(biāo)會與真實場景有偏差。把 Flow Control Action 和隨機變量配合可以做得更優(yōu)雅。舉個例子在查詢列表和查看詳情兩個接口之間放置一個 Flow Control Action然后 Duration 用${__Random(2000,8000)}這個函數(shù)來生成隨機的 2 到 8 秒暫停。每個并發(fā)用戶取到的隨機值都不一樣這樣整個壓測的流量模型就變成了類似隨機思考時間的分布。為什么用 Flow Control Action 而不是 Constant Timer 配合 Random 函數(shù)因為 Constant Timer 的隨機暫停只能作用于下一個采樣器假如你后面有兩個采樣器就變成每個都等一個隨機時間節(jié)奏就完全不對了。Flow Control Action 在作用位置上更精準(zhǔn)它只在你指定的節(jié)點打斷一次不會影響后續(xù)所有采樣器。稍微進階一點的做法是把 Duration 參數(shù)做成全局配置。比如測試計劃里加一個用戶自定義變量THINK_TIME_MS5000然后在 Flow Control Action 的 Duration 填${THINK_TIME_MS}。這樣你要修改思考時間只需要改一處變量。如果配合屬性參數(shù)用${__P(think.time,5000)}那么命令行壓測時直接傳參即可根本不需要打開 GUI 改腳本。4.2 場景二關(guān)鍵業(yè)務(wù)失敗后的熔斷與降級第二個典型場景是業(yè)務(wù)鏈路長、依賴環(huán)節(jié)多的情況。比如一個下單流程包含登錄、查詢庫存、創(chuàng)建訂單、鎖定庫存、支付、通知物流。前面的步驟都成功了萬一鎖定庫存失敗后面的支付和物流就沒有執(zhí)行的意義了。貿(mào)然繼續(xù)執(zhí)行不僅會生成大量失敗請求還會污染響應(yīng)時間的統(tǒng)計樣本。解決方案很直接在鎖定庫存接口后面增加一個 JSON 提取器或正則表達式提取器把響應(yīng)中的狀態(tài)碼提取到變量里然后放一個 If Controller 判斷狀態(tài)碼。如果狀態(tài)碼不是預(yù)期值就執(zhí)行 Flow Control ActionTarget 選 Current ThreadAction 選 Stop Now 或 Stop。這里要特別談一下 Stop 和 Stop Now 的選擇。如果這條線程的后續(xù)節(jié)點都是本線程的腳本步驟那么 Stop 就夠了因為當(dāng)前線程不排隊新請求等正在執(zhí)行的請求跑完就終止。但如果你在線程組中配置了循環(huán)Loop或者使用了 While Controller 會讓線程持續(xù)運行Stop 可能不會立即生效因為循環(huán)結(jié)構(gòu)可能又開始下一輪迭代此時用 Stop Now 更果斷。另外要注意Flow Control Action 執(zhí)行了 Stop 之后當(dāng)前線程會停止但整個線程組里其他線程怎么辦這取決于你 Target 的選擇。如果只想讓失敗的這個線程停止選 Current Thread如果想讓整個測試計劃停止選 All Threads。在一個多渠道多用戶混合壓測的場景里我更推薦 Current Thread 另一個線程組獨立監(jiān)控異常匯總數(shù)據(jù)。因為你不能因為一個用戶的庫存鎖定失敗就全線熔斷那樣測試就失去意義了。有時我們還想在停止前留下點痕跡方便事后分析?？梢栽?Flow Control Action 前面放一個 JSR223 斷言或者 Debug Sampler先記錄當(dāng)前上下文信息到日志文件然后再停止。這個組合在排查生產(chǎn)級別問題的時候特別有用。4.3 場景三并發(fā)啟動預(yù)熱與階梯式暫停壓測過程中我們經(jīng)常希望模擬服務(wù)剛重啟后第一批用戶涌入的場景。這時候系統(tǒng)里的緩存是空的連接池需要逐步建立如果所有用戶同時發(fā)送請求表現(xiàn)可能不是真實水平的反映而更像是緩存擊穿。Flow Control Action 可以實現(xiàn)一個簡易但有效的預(yù)熱策略。在測試計劃的最頂部放一個 Flow Control ActionTarget 選 All ThreadsAction 選 PauseDuration 設(shè)為${__P(warmup.pause,10000)}。這樣無論你啟動了十幾個還是上百個線程它們都會先共同等待 10 秒這段時間你可以做很多事情比如手動觸發(fā)緩存預(yù)熱腳本、確認(rèn)服務(wù)端日志開始打印新連接建立的消息。等這 10 秒過去所有線程會同時繼續(xù)執(zhí)行形成一個比較標(biāo)準(zhǔn)的并發(fā)沖峰。這個所有線程共同等待的效果用 Constant Timer 做不到因為 Constant Timer 是每個采樣器各自等待不會等齊其他線程。這也是 All Threads 模式最典型的應(yīng)用場景你在用一個同步屏障。當(dāng)然JMeter 自帶的 Synchronizing Timer同步定時器也可以實現(xiàn)一定程度的集合點等待但它側(cè)重的是同時發(fā)起請求而 Flow Control Action 側(cè)重的是統(tǒng)一延后啟動時刻兩者的語義不同。如果你要的是同時按一個按鈕再開始跑同步定時器更合適如果你要的是大家先歇一歇挪到指定時刻再繼續(xù)干活Flow Control Action 的實現(xiàn)更自然。階梯式暫停是另一個變體。比如你在循環(huán)里嵌套了 Flow Control Action并且 Duration 用${__groovy(vars.get(i).toInteger() * 1000)}這種動態(tài)計算值就能實現(xiàn)第一輪暫停 1 秒第二輪暫停 2 秒逐步拉開節(jié)奏。這常用于極端場景下的排隊等待模擬比如在你的測試計劃里用循環(huán)模擬用戶不斷重試而每次重試間隔都變長然后腳本里放置 Flow Control Action 就能實現(xiàn)這種退避策略。雖然這個邏輯用 JSR223 也能寫但用原生的 Flow Control Action 函數(shù)表達式至少少了一半維護工作而且發(fā)生死鎖的概率低得多。4.4 場景四調(diào)試與可觀測性增強最后一個場景可能被很多人忽略用 Flow Control Action 來輔助調(diào)試腳本。做接口測試最煩的一件事是腳本跑得太快你根本看不清某個變量在不同請求之間是怎么變化的。如果臨時把所有采樣器之間都加上暫停組件又顯得啰嗦。在實際調(diào)試時我通常會在關(guān)鍵的斷點位置插入一個 Flow Control ActionAction 選 PauseDuration 填一個足夠大的值比如 30 或 60 秒。然后在同一位置附近放置一個 Debug Sampler把當(dāng)時的變量值打印到查看結(jié)果樹里。跑一輪之后打開查看結(jié)果樹能看到每一步的變量快照但又不會因為腳本自動執(zhí)行完導(dǎo)致來不及看。這里有一個很妙的搭配你可以在 Debug Sampler 后面加一個 JSR223 斷言斷言失敗才執(zhí)行 Flow Control Action用 Groovy 寫vars.put(debug.hit, 1)然后用 If Controller 判斷變量為 1 再暫停。這樣腳本只在斷言失敗時才剎車正常路徑一路跑完非常干凈。調(diào)試完成后把 If Controller 的表達式改為${__P(debug.mode,false)}命令行不帶 debug 參數(shù)時整個暫停邏輯就變成了一股空操作完全不干擾壓測。5. 常見坑點與排查技巧實錄5.1 坑點一Duration 填了沒生效這個坑出現(xiàn)頻次極高。有一種情況是 Duration 填了個整數(shù)但沒意識到單位是毫秒填了 1 以為是 1 秒實際只有 1 毫秒。如果你觀察到腳本幾乎沒暫停先去檢查單位不要懷疑組件有問題。另一種情況是 Duration 使用了變量但變量在同請求中的提取器還沒有運行導(dǎo)致變量為空或返回非數(shù)字。比如你想用上一個響應(yīng)的時間來動態(tài)計算暫停時間然而你放錯了位置Flow Control Action 被放在了響應(yīng)提取器的前面此時變量還沒來得及被賦值Duration 就會解析失敗。解決方案是把提取器放在它對應(yīng)的采樣器之后Flow Control Action 之前。如果用的是${__P()}全局屬性則不存在這個問題但依然要注意命令行參數(shù)名是否拼寫正確。還有一種很隱蔽的情況在梯度壓測過程中Duration 寫的是${__P(duration,1000)}你啟動時確實傳了-Jduration-1而你的業(yè)務(wù)邏輯本來想在 -1 時跳過暫停但 JMeter 內(nèi)部會把 -1 處理成無限暫?；蛑苯訄箦e。不同版本的行為不完全一致我建議在取值后用 Groovy 函數(shù)包一層判斷。比如 Duration 寫成${__groovy((__P(duration,1000) as int) 0 ? 0 : (__P(duration,1000) as int))}雖然表達式看起來復(fù)雜但能保證邊界安全。5.2 坑點二Stop 和 Stop Now 都沒能停下來有朋友反饋在壓測中執(zhí)行 Flow Control Action 的 Stop 之后線程還在繼續(xù)發(fā)請求。遇到這個問題先別急著懷疑組件失效我排查過多次最終原因幾乎都是線程組循環(huán)條件沒有及時退出。JMeter 的線程組如果配置了循環(huán)次數(shù)Loop Count為無限即使當(dāng)前線程收到了 Stop 指令只要當(dāng)前迭代沒有結(jié)束它也會在本輪循環(huán)內(nèi)部優(yōu)雅地跑完再進入下一輪判斷。如果 Flow Control Action 出現(xiàn)在循環(huán)體的中間位置那么 Stop 之后它后面的采樣器還會繼續(xù)執(zhí)行完等整個循環(huán)體跑完才會停止。所以如果你希望停止之后立刻不再執(zhí)行任何采樣器那應(yīng)該用 Stop Now或者把 Flow Control Action 放在循環(huán)體的外面。另外需要注意如果測試計劃里有多個線程組并且使用tearDown線程組執(zhí)行清理腳本那么當(dāng)主線程組執(zhí)行了 Stop 之后tearDown 線程組仍然有可能會啟動。這在某些預(yù)期整個測試完全停止的場景中是意外的。要徹底終止包括 tearDown 在內(nèi)的任務(wù)需要 Stop Now 或者結(jié)合命令行斷言腳本的外部機制。5.3 坑點三大量使用 Pause 導(dǎo)致壓測不達標(biāo)這是一類性能問題。很多人在腳本里插入了大量 Flow Control Action 的 Pause導(dǎo)致總運行時長被拉得很長。在單實例跑功能腳本時沒問題但在分布式壓測時如果每個 agent 機器上都有幾十個虛用戶每個虛用戶都要獨立暫停那整體任務(wù)的完成時間會變得極不可控。而且如果暫停時間大大超過了服務(wù)端響應(yīng)時間壓測QPS會被拉低到無法反映系統(tǒng)真實性能。這個問題不算組件 bug而是建模思路出了偏差。如果要模擬真實用戶思考時間最具性價比的做法是在線程組層面設(shè)置固定定時器或高斯隨機定時器均勻地給每個采樣器加一點延遲。用 Flow Control Action 只在需要大量暫停的特定節(jié)點上打斷執(zhí)行。如果發(fā)現(xiàn)整個腳本里 Flow Control Action 占比太高建議你重新審視一下流量模型是否應(yīng)該用思考時間參數(shù)來代替零散硬編碼暫停。5.4 坑點四作用域誤判造成所有線程集體中斷曾經(jīng)有個同事排查了整整一個下午他寫了一個 If Controller判斷某個請求響應(yīng)碼非 200 時執(zhí)行 Flow Control Action打算把失敗線程篩掉。結(jié)果他選的是 All Threads導(dǎo)致只要有一個請求報錯整個測試計劃瞬間停止。這個問題最麻煩的地方在于現(xiàn)場的錯誤日志幾乎沒有因為線程都被強行停掉了只留下一臉茫然的壓測結(jié)果。判斷是否踩進這個坑的方法是查看 Flow Control Action 的 Target 下拉框如果確實選了 All Threads請立刻問自己一句我真的需要所有線程都陪我停嗎 在 99% 的單鏈路測試場景中你要的是 Current Thread。如果你確實要針對某個失敗的線程做熔斷影響范圍最好控制在這個線程內(nèi)部的后續(xù)邏輯而不要拖垮整個壓測。除非你在做故障注入或全鏈路降級演練否則別用 All Threads。5.5 坑點五Pause 在線程組關(guān)閉時無法打斷在高并發(fā)調(diào)試時你會點擊 JMeter 界面上的停止按鈕來強行中止測試。但如果此時某個線程卡在 Flow Control Action 的 Pause 階段它可能會一直等到暫停時間結(jié)束才能真正響應(yīng)停止請求。具體表現(xiàn)是你點了停止其他線程都陸續(xù)消失了但界面上還剩一個線程的曲線遲遲不歸零就是因為在 Pause 中。這個行為在很多版本中都存在。要解決這個體驗問題一個辦法是在 Pause 的 Duration 中不要用太大的值比如 60 秒以上的暫停會讓停止操作延遲特別明顯。更好的辦法是在調(diào)試階段使用 Stop Now因為 Stop Now 會中斷 Pause 狀態(tài)讓線程迅速釋放。不過要注意Stop Now 使用多了可能帶來一些連接未正常釋放的副作用在正式壓測中還是盡量用 Stop。另外在非 GUI 命令行壓測模式下CtrlC 中斷進程也會遇到類似的問題。如果前提是要優(yōu)雅退出可以通過外部的超時腳本配合shutdown指令來終止。這個鍋不能全讓 Flow Control Action 背但你了解了這個行為之后在設(shè)計腳本時會更有意識地控制單次暫停時長的上限。5.6 坑點六在事務(wù)控制器內(nèi)放置 Flow Control Action 導(dǎo)致響應(yīng)時間失真這個問題對結(jié)果分析的影響特別大。我在一次壓測里發(fā)現(xiàn)某個事務(wù)的 90% 響應(yīng)時間異常高排查到最后才發(fā)現(xiàn)是有人把 Flow Control Action 放在了事務(wù)控制器內(nèi)部并且設(shè)置了 3 秒的 Pause。這 3 秒自然被算進了事務(wù)的響應(yīng)時間導(dǎo)致整個事務(wù)的 TP90 數(shù)據(jù)完全失真。Flow Control Action 是邏輯控制組件不是業(yè)務(wù)請求它的耗時不應(yīng)被計入業(yè)務(wù)事務(wù)響應(yīng)時間。如果你需要在業(yè)務(wù)步驟之間插入暫停應(yīng)該把它放在事務(wù)控制器的外面。如果事務(wù)控制器范圍必須覆蓋多個采樣器且你還要在這多個采樣器之間暫停那就把事務(wù)拆成兩段或者用標(biāo)記性采樣器如后面接一個極小開銷的請求來分割盡量保證事務(wù)控制器內(nèi)部只包含真實意圖。不要圖省事把暫停直接塞進事務(wù)塊后續(xù)分析數(shù)據(jù)時你會后悔的。5.7 快速排查清單做實戰(zhàn)總結(jié)的時候我習(xí)慣把排查經(jīng)驗收斂成一張檢查表方便自己在交付腳本前快速自查。下面這份清單你直接拿走對照著過一遍流程控制相關(guān)的腳本會省下很多排錯時間檢查項關(guān)鍵動作是否通過Target 選擇確認(rèn)是 Current Thread 還是 All Threads非熔斷場景一律用 Current Thread是Duration 單位再次確認(rèn)單位是毫秒變量路徑與取值時機是否正確是Action 語義區(qū)分 Stop 與 Stop Now循環(huán)體內(nèi)部建議用 Stop Now是作用域位置Flow Control Action 不在事務(wù)控制器內(nèi)部不影響響應(yīng)時間統(tǒng)計是調(diào)試與正式模式是否用${__P()}參數(shù)控制啟停正式壓測時不需要調(diào)試暫停是分布式壓測一致性所有 agent 上的腳本版本一致暫停參數(shù)不依賴本機文件是6. 寫在最后Flow Control Action 只是起點流程控制的核心在建模這篇文章從 Flow Control Action 的定位、參數(shù)、實戰(zhàn)和坑點四個角度做了一次完整的梳理。我個人的體會是這個組件本身不難難的是建立一種流程控制的思維每個請求什么時候該發(fā)、什么時候不能發(fā)、發(fā)完不代表一定繼續(xù)下一步這些都是性能測試建模的一部分。Flow Control Action 有個比較容易被忽略的優(yōu)勢是它是 JMeter 原生組件在維護和交接上特別省心。你在腳本里放十個 Flow Control Action腳本運行時的開銷也極低更不會像 BeanShell 那樣因為腳本解釋器導(dǎo)致內(nèi)存不斷膨脹。換一個人來接手你的腳本時看著組件圖標(biāo)和參數(shù)列表基本一眼就能明白你要干什么不需要去翻 Groovy 代碼再猜邏輯。這也是我推薦團隊里盡量使用原生組件的核心理由。最后再分享一個小技巧。你在設(shè)計腳本階段可以先在所有關(guān)鍵接口后面放一個 Action 為 Pause、Duration 為${__P(pause,0)}的 Flow Control Action。調(diào)試階段通過命令行參數(shù)-Jpause5000來控制斷點等待時間。這樣平時跑全速調(diào)試時插樁不用在測試計劃里反復(fù)增刪組件。我個人用這個方案很久了每次接手的同事都會來問這個 0 秒暫停是干嘛的等他們理解了之后基本都會拷貝到自己的腳本里去用。Flow Control Action 并不會幫你解決所有流程控制問題但當(dāng)你需要優(yōu)雅地決定一條線程何時等、何時停、何時立刻結(jié)束它絕對是你工具箱里最趁手的那把螺絲刀。