準確說JMeter是你項目上線前最該用、卻經(jīng)常被拖到最后才想起的那類工具。很多團隊直到線上出事故、老板質(zhì)問為什么這么慢的時候才急急忙忙找壓測方案結(jié)果一測就發(fā)現(xiàn)各種問題。而我第一次接觸JMeter也是被一個莫名其妙的線上故障拽進來的——某個模擬項目X的活動頁一到中午就卡死數(shù)據(jù)庫CPU飆到99%開發(fā)互相甩鍋最后只能老老實實搭壓測環(huán)境復(fù)現(xiàn)問題才定位到是一條慢SQL加接口并發(fā)沒做限制導致的。從那以后壓測在我這里就從可有可無的環(huán)節(jié)變成了每次發(fā)版前的標配。JMeter能做什么往大了說它可以模擬大量用戶并發(fā)訪問你的接口、數(shù)據(jù)庫、消息隊列驗證系統(tǒng)在高負載下扛不扛得住往小了說它也能幫你測單個接口在不同并發(fā)下的響應(yīng)時間用來做接口性能調(diào)優(yōu)、容量評估、瓶頸定位。無論你是后端開發(fā)、測試還是運維只要涉及到系統(tǒng)性能四個字JMeter基本是繞不開的入門工具。它對新手最友好的地方在于裝了就能用圖形界面點一點就能跑出第一個腳本完全不需要先啃一堆文檔。這篇文章我會把JMeter是什么、它背后運行的原理、以及從零到一跑通壓測腳本的完整步驟講清楚。重點放在為什么這么設(shè)計和怎么避開常見坑上而不是堆一堆官方術(shù)語。如果你照著文檔點過幾次但還是覺得云里霧里那這篇應(yīng)該能幫你把那些零碎的知識串起來。1. 一句話說清楚JMeter到底是什么以及它解決的痛點1.1 先理解壓測這件事到底在測什么在沒有性能測試工具之前你想驗證一個接口能不能撐住100個并發(fā)用戶只能靠肉眼召集幾十個人同時點按鈕。問題是人肉壓測既不精準也不可重復(fù)點幾下就累而且每個人的操作節(jié)奏完全不同測出來的數(shù)據(jù)根本沒法當成參考依據(jù)。JMeter本質(zhì)上是把人肉點擊這件事自動化、量化了。它用軟件線程模擬虛擬用戶讓每個虛擬用戶按照你設(shè)定的節(jié)奏發(fā)請求然后記錄這些請求的成功率、響應(yīng)時間、吞吐量。換句話說你告訴JMeter我要100個用戶每人連續(xù)請求30次它就用100個線程循環(huán)跑30輪最后把結(jié)果匯總成你認識的數(shù)字。這里有個關(guān)鍵認知JMeter測的是服務(wù)端能扛住多少壓力不是服務(wù)端運行得有多快。它更像是一個壓力制造機制造出符合你預(yù)設(shè)規(guī)模的流量再觀察系統(tǒng)在這個流量下的表現(xiàn)。所以當你聽到別人說用JMeter做性能測試時背后的潛臺詞通常是我想知道系統(tǒng)在極限情況下的表現(xiàn)、瓶頸在哪里、該買多少臺機器。1.2 為什么偏偏是JMeter而不是自己寫腳本當然你完全可以用Python腳本、Go程序自己寫并發(fā)請求很多大廠也確實有自研壓測平臺。但JMeter能成為開源領(lǐng)域最普及的選擇有幾個非常現(xiàn)實的原因第一零代碼上手。它提供了圖形界面添加線程組、HTTP請求、斷言都是按鈕操作業(yè)務(wù)測試人員也能快速上手。寫好腳本后還能用命令行無界面跑方便放進CI/CD流程。第二協(xié)議覆蓋廣。除了最常見的HTTP/HTTPS它還支持WebService、JDBC數(shù)據(jù)庫查詢、JMS消息、FTP、TCP等協(xié)議。這意味著你測完HTTP接口還能用同一套工具去壓數(shù)據(jù)庫連接池、壓消息隊列消費能力。第三擴展生態(tài)成熟。市面上的插件、文檔都非常多出了問題基本能找到對應(yīng)解決方案。它的核心是Java寫的如果你有Java基礎(chǔ)還能自己寫Sampler擴展特殊協(xié)議。我承認JMeter的界面看起來有點復(fù)古第一次打開的人很容易覺得它像上個世紀的軟件。但工具的價值不在好看而在于穩(wěn)定可靠、生態(tài)完整這點JMeter做得足夠好。1.3 適合誰學、什么階段學我見過不少初學者一上來就研究JMeter的分布式壓測、BeanShell腳本結(jié)果連線程組和取樣器的關(guān)系都沒搞清楚最后越學越糊涂。以我的經(jīng)驗按階段來看比較合理剛接觸性能測試先學會用JMeter跑通HTTP接口的并發(fā)測試看懂聚合報告里的三項核心指標吞吐量、平均響應(yīng)時間、錯誤率。做接口自動化階段學會用JMeter的參數(shù)化、斷言、關(guān)聯(lián)把你的測試腳本做得不依賴具體數(shù)據(jù)。做系統(tǒng)容量評估階段再研究分布式壓測、監(jiān)控系統(tǒng)指標、定位瓶頸。這篇文章主要服務(wù)的是第一和第二階段。把基礎(chǔ)打牢后面那些高階玩法都屬于按需查閱不用一開始就全部啃完。2. 拆開骨架JMeter的核心組件到底誰管誰JMeter的腳本文件以JMX結(jié)尾本質(zhì)上是一個XML格式的測試計劃配置。不管界面怎么變核心組件就那幾類線程組、取樣器、邏輯控制器、監(jiān)聽器、斷言、配置元件、前置/后置處理器。把它們的關(guān)系理清你就掌握了JMeter十之八九的邏輯。2.1 線程組虛擬用戶的大本營線程組是每個測試計劃里必須存在的東西它的圖標是個小人集合作用就是定義有多少虛擬用戶、以什么節(jié)奏跑。打開線程組的配置面板你會看到幾個關(guān)鍵參數(shù)線程數(shù)、Ramp-Up時間、循環(huán)次數(shù)、調(diào)度器。我逐個說清楚它們的實際含義線程數(shù)代表虛擬用戶的數(shù)量。注意每個線程就是一個獨立的用戶會話但每個線程之間默認不共享變量除非你特意配置共享。Ramp-Up時間所有線程從第一個啟動到全部啟動完成所花的時間。比如線程數(shù)是100Ramp-Up是10秒那就是每秒啟動10個線程。這個參數(shù)非常實用它決定了壓測是瞬間全部涌入還是緩慢爬坡模擬的場景完全不同。循環(huán)次數(shù)每個線程跑完一輪請求后是繼續(xù)跑下一輪還是停下來。填永遠并勾選調(diào)度器就可以按持續(xù)時間來壓測比如壓測10分鐘。調(diào)度器可以設(shè)置啟動延遲和持續(xù)時間適合長時間穩(wěn)定性壓測。這里有個最常見的誤區(qū)線程數(shù)不等于并發(fā)數(shù)。如果Ramp-Up時間是0100個線程會在瞬間全部啟動這時候并發(fā)可以近似等于線程數(shù)。但如果Ramp-Up設(shè)了60秒那前10秒可能只有幾十個線程在跑真正的并發(fā)是逐步上升的。所以看JMeter結(jié)果時先確認線程組的配置別把總線程數(shù)和實際并發(fā)混為一談。2.2 取樣器真正干活的手取樣器Sampler是JMeter里實際發(fā)出請求的組件。HTTP請求取樣器最常用配置里包含協(xié)議、域名、端口、路徑、請求方法、請求體等。取樣器的核心作用就是把你的請求按照協(xié)議規(guī)范發(fā)出去并接收服務(wù)端返回。你可以理解為線程組負責安排人取樣器負責幫每個人遞話。線程組里的每個線程都會執(zhí)行測試計劃下掛的取樣器并記錄結(jié)果供監(jiān)聽器統(tǒng)計。這里有一個新手經(jīng)常想不通的問題一個線程組下面掛了多個HTTP請求JMeter是按什么順序執(zhí)行的答案是按它們在測試計劃里的添加順序從上到下依次執(zhí)行。這就有意思了——如果前一個請求的返回結(jié)果需要傳給后一個請求使用你就得用后置處理器把值提取出來再通過變量引用傳給后面。這個機制被稱為關(guān)聯(lián)是接口測試腳本里非常重要的基本功。2.3 監(jiān)聽器把壓力測試變成看得懂的數(shù)字取樣器發(fā)出請求后結(jié)果默認是存內(nèi)存里的你得靠監(jiān)聽器把它可視化出來。常見的監(jiān)聽器有聚合報告Aggregate Report最常用。展示請求數(shù)、平均響應(yīng)時間、最小/最大響應(yīng)時間、錯誤率、吞吐量等匯總數(shù)據(jù)。這個監(jiān)聽器基本是壓測報告的標配。查看結(jié)果樹View Results Tree逐條查看每個取樣器的請求和響應(yīng)詳情一般用來調(diào)試腳本不適合正式壓測時開著因為它在高并發(fā)下會產(chǎn)生巨大的IO開銷。圖形結(jié)果Graph Results把響應(yīng)時間、吞吐量畫成曲線適合觀察整體趨勢。響應(yīng)時間圖Response Time Over Time需要插件支持可以查看響應(yīng)時間隨時間的變化趨勢用于定位是否存在某段時間突然變慢的情況。這里有個性能測試的常識正式壓測時監(jiān)聽器能不開就不開尤其是查看結(jié)果樹這類會記錄每個請求詳情的監(jiān)聽器。因為壓測本身會給服務(wù)端施壓如果JMeter自己也被監(jiān)聽器拖垮那測出來的數(shù)據(jù)就不準了。我一般習慣在開發(fā)調(diào)試階段開著聚合報告和查看結(jié)果樹正式跑壓測時只開聚合報告或者干脆完全無界面運行后通過生成的JTL文件再導入聚合報告。2.4 斷言、配置元件與邏輯控制器從會跑到有腦子有了線程組、取樣器和監(jiān)聽器腳本已經(jīng)能跑起來了但它還比較傻發(fā)完請求不管對不對請求里寫死的參數(shù)也換不了場景也只是一個順序執(zhí)行。要讓腳本更接近真實業(yè)務(wù)還需要三類組件斷言Assertion用來判斷請求返回是否符合預(yù)期。最簡單的響應(yīng)斷言可以檢查響應(yīng)文本是否包含某個關(guān)鍵詞比如登錄接口成功后返回success那就斷言響應(yīng)文本包含success。不符合斷言的結(jié)果會被標記為失敗計入錯誤率。這一步很關(guān)鍵因為沒有斷言的壓測錯誤率基本沒參考價值——你根本不知道服務(wù)端返回的是成功頁還是500頁。配置元件Config Element比如CSV數(shù)據(jù)文件設(shè)置、HTTP信息頭管理器、用戶自定義變量。它們提供請求所需的參數(shù)數(shù)據(jù)。最典型的是CSV數(shù)據(jù)文件設(shè)置你可以把1000個測試賬號放進CSV里讓每個線程從文件里取一行數(shù)據(jù)這樣就不會出現(xiàn)100個用戶同時用同一個賬號登錄的失真場景。邏輯控制器Logic Controller用來控制取樣器的執(zhí)行順序和次數(shù)。比如循環(huán)控制器可以讓某個請求循環(huán)執(zhí)行N次交替控制器可以輪流執(zhí)行不同的取樣器如果If控制器可以根據(jù)條件決定是否執(zhí)行某段邏輯。有了邏輯控制器你才能模擬復(fù)雜的用戶行為路徑而不是所有人都按同一個腳本跑。3. JMeter跑起來背后發(fā)生了什么工作原理逐層看看再多元件介紹不如理解JMeter執(zhí)行請求時的完整鏈路。這一節(jié)把它的運行原理拆開講理解之后配置什么參數(shù)都不會再心虛。3.1 從啟動到并發(fā)JMeter如何構(gòu)造虛擬用戶JMeter啟動測試后會做這幾件事根據(jù)線程組配置創(chuàng)建線程池。線程數(shù)就是池子大小。線程池中的每個線程開始執(zhí)行測試計劃中的取樣器鏈。取樣器按照協(xié)議構(gòu)造請求報文比如HTTP的Method、Headers、Body通過底層網(wǎng)絡(luò)庫發(fā)出去。收到響應(yīng)后JMeter把它封裝成一個SampleResult對象記錄開始時間、結(jié)束時間、響應(yīng)字節(jié)數(shù)、狀態(tài)碼、是否斷言失敗等信息。所有SampleResult被交給監(jiān)聽器/結(jié)果收集器處理最終匯總成你看到的指標。這里的技術(shù)細節(jié)是Java的多線程機制。每個虛擬用戶對應(yīng)一個Java線程線程的調(diào)度由JVM和操作系統(tǒng)完成。JMeter本身不主動調(diào)節(jié)每秒發(fā)出的請求數(shù)它只是盡可能快地讓每個線程循環(huán)執(zhí)行、發(fā)請求。所以同一個線程組配置在小并發(fā)下可能每秒發(fā)出100個請求在高并發(fā)下因為線程爭搶資源實際吞吐量可能上不去。換句話說JMeter的并發(fā)模擬是靠最大限度壓榨線程執(zhí)行速度實現(xiàn)的這也決定了它的一個特性JMeter機器自身的性能會直接影響壓測結(jié)果。如果壓測機CPU被打滿發(fā)出的請求速度就會下跌你看到的指標不一定是服務(wù)端真實的處理能力。這就是為什么大規(guī)模壓測要做分布式讓多臺機器分擔壓力。3.2 線程模型與線程組配置的關(guān)系為什么不能盲目設(shè)置幾千線程很多人一上來就把線程數(shù)設(shè)成5000想著并發(fā)越大越好結(jié)果JMeter直接卡死或者報一堆連接錯誤。原因在于每個Java線程都會占用棧內(nèi)存和系統(tǒng)資源5000個線程光是棧內(nèi)存就要數(shù)百MB甚至GB級別再加上每線程獨立的網(wǎng)絡(luò)連接、定時器資源開銷非?？捎^。所以合理的并發(fā)設(shè)計不是一步到位而是逐步加壓。比如先50線程跑5分鐘再100線程跑5分鐘再200線程跑5分鐘觀察系統(tǒng)在不同壓力下的表現(xiàn)找到拐點。這種階梯式壓測比直接干到5000線程有意義得多也更容易定位瓶頸。我還見過一種錯誤用法線程數(shù)設(shè)很大但循環(huán)次數(shù)只設(shè)1次。這樣所有線程在同一瞬間全部發(fā)請求壓力集中在開場那幾秒并沒有起到持續(xù)觀察的效果。更合理的做法是線程數(shù)適中比如100循環(huán)次數(shù)設(shè)為永遠并用調(diào)度器限定持續(xù)運行10分鐘。這樣能保持一個穩(wěn)定的并發(fā)壓力持續(xù)打向服務(wù)端更接近真實用戶長時間在線的場景。3.3 一個請求從發(fā)出到記錄JMeter內(nèi)部是怎么計算的以HTTP請求為例一個完整的SampleResult包含這些關(guān)鍵時間點發(fā)送請求前的起始時間戳連接建立耗時Connect Time發(fā)送請求到收到響應(yīng)的總耗時Latency在JMeter里通常指從請求開始到響應(yīng)開始的時間完整接收響應(yīng)數(shù)據(jù)的耗時Sample Time也就是監(jiān)聽器里顯示的響應(yīng)時間聚合報告里顯示的Average響應(yīng)時間是所有成功/失敗請求樣本響應(yīng)時間的算術(shù)平均值。這里有三個容易誤讀的點第一平均值會被極端大頭拉高。某個請求卡了10秒其余99個都只花100毫秒平均值也會變得很難看。所以除了看Average還要看90% Line、95% Line甚至99% Line也就是90%的請求都在這個時間以內(nèi)完成更接近絕大多數(shù)用戶的真實體驗。第二聚合報告默認對所有請求路徑混在一起統(tǒng)計。如果你的測試計劃里包含多個取樣器比如登錄和查列表聚合報告會分別列出每個取樣器路徑的數(shù)據(jù)也會有一個匯總行。第三錯誤率不是服務(wù)端返回500才算錯。響應(yīng)斷言失敗、連接超時、響應(yīng)碼非預(yù)期全部會計入錯誤。所以配置斷言一定要合理斷言太嚴格會導致很多實際成功的請求被標記為錯誤斷言太寬松又會導致真正的問題被忽略。我的經(jīng)驗是HTTP請求默認把響應(yīng)碼2xx/3xx視為成功如果你只關(guān)心服務(wù)端是否正常返回可以不加斷言如果你想驗證業(yè)務(wù)邏輯正確性再針對性地加響應(yīng)文本斷言。3.4 一臺壓測機不夠時分布式壓測的原理當目標系統(tǒng)的壓力需求非常大比如每秒幾萬請求時單臺JMeter機器自己先會成為瓶頸。JMeter的解決方式是分布式壓測一臺主控機Master負責管理腳本多臺執(zhí)行機Worker/Slave負責實際發(fā)請求。分布式壓測的工作機制簡單說主控機把測試計劃分發(fā)給各個執(zhí)行機各執(zhí)行機按照同樣的腳本各自生成虛擬用戶并發(fā)請求最后把結(jié)果匯總回主控機。這樣一來總并發(fā)量就可以變成每臺執(zhí)行機的并發(fā)數(shù) × 執(zhí)行機數(shù)量。但分布式不是隨便就能穩(wěn)定工作的幾個顯而易見的坑腳本和依賴數(shù)據(jù)必須同步到所有執(zhí)行機。你用的CSV參數(shù)文件、jar包都要手動同步到每臺機器上主控機不會自動幫你傳。執(zhí)行機與主控機的時間必須一致否則匯總出來的時間線會錯亂。這個問題在跨地域多機房壓測時特別明顯最好用同一網(wǎng)段內(nèi)的時間同步機制。網(wǎng)絡(luò)帶寬夠不夠。執(zhí)行機和目標服務(wù)之間如果走的是互聯(lián)網(wǎng)公網(wǎng)帶寬光網(wǎng)絡(luò)延遲和限速就會把壓測結(jié)果搞得一塌糊涂。最理想的情況是壓測機與目標服務(wù)在同一個內(nèi)網(wǎng)。執(zhí)行機的端口資源。每臺執(zhí)行機發(fā)請求會占本機的臨時端口Linux默認可用端口范圍大約3萬多短時間內(nèi)大量新建連接很容易把端口耗盡導致連接失敗。后面我會專門講這個問題怎么調(diào)優(yōu)。4. 從零到一完整跑通一個HTTP接口壓測腳本這一節(jié)按實際操作順序來你跟著做就能跑出第一個壓測腳本。我以剛部署好的某個模擬項目X的登錄接口為例來演示。4.1 環(huán)境準備JDK和JMeter的安裝JMeter是Java寫的所以第一件事是裝JDK。目前主流JMeter版本對JDK版本有要求我用的是JDK 17。裝好之后在終端執(zhí)行java -version確認一下。然后去官網(wǎng)下載JMeter的二進制壓縮包解壓后目錄結(jié)構(gòu)里的bin文件夾包含啟動腳本W(wǎng)indows下是jmeter.batLinux/Mac下是jmeter.sh。解壓即用不需要額外安裝。啟動圖形界面執(zhí)行./jmeter.sh -n # 這是錯誤示例圖形界面直接運行 ./jmeter.sh 即可更正一下直接運行./jmeter.sh就會打開圖形界面。-n參數(shù)是無界面模式后面在命令行壓測部分再說。建議把bin目錄加到環(huán)境變量PATH里后面用命令行跑壓測會頻繁用到。安裝完成后圖形界面頂部的Options菜單里可以切換語言為簡體中文JMeter 5.x以上支持菜單切換語言。4.2 創(chuàng)建測試計劃線程組參數(shù)這樣填在圖形界面左側(cè)樹形面板里右鍵測試計劃選擇添加 - 線程用戶 - 線程組。線程組是測試計劃的第一個必需組件。我把線程組參數(shù)按下面的值配置并用一個具體的壓測需求解釋為什么這么填線程數(shù)50Ramp-Up時間5秒循環(huán)次數(shù)10調(diào)度器不勾選需求是模擬50個用戶5秒內(nèi)全部進入并發(fā)狀態(tài)每個用戶循環(huán)執(zhí)行10次請求。這樣總請求量是50×10500個請求。Ramp-Up設(shè)5秒是為了讓并發(fā)逐步建立而不是瞬間50個線程同時打過去——瞬間啟動雖然更暴力但容易觸發(fā)一些與連接建立相關(guān)的假性錯誤不利于第一次跑腳本時排查問題。如果你希望壓力更平穩(wěn)可以把循環(huán)次數(shù)改成永遠然后勾選調(diào)度器并設(shè)置持續(xù)時間300秒這樣它就會持續(xù)跑5分鐘。4.3 添加HTTP請求取樣器和HTTP信息頭管理器在線程組上右鍵選擇添加 - 取樣器 - HTTP請求。配置面板里重點填這幾項協(xié)議https視你的服務(wù)而定服務(wù)器名稱或IPapi.example.com換成你的真實地址端口號443HTTP默認80方法POST路徑/api/login消息體數(shù)據(jù){username:testuser,password:123456}同一個線程組下再添加一個HTTP信息頭管理器設(shè)置Content-Type為application/json。這里非常關(guān)鍵很多接口返回415錯誤就是因為請求頭里沒有聲明JSON格式。在正式壓測前先在執(zhí)行計劃里加上查看結(jié)果樹監(jiān)聽器然后點擊菜單欄的綠色啟動按鈕跑一次1個線程1次循環(huán)的調(diào)試。在查看結(jié)果樹里展開請求確認響應(yīng)體是你預(yù)期的登錄成功返回。這一步叫腳本調(diào)試務(wù)必確認通過后再加大線程數(shù)否則后面跑出錯誤率都不知道是腳本配置有問題還是服務(wù)真扛不住。4.4 添加聚合報告與斷言讓結(jié)果有參考意義調(diào)試通過后加一個聚合報告監(jiān)聽器。右鍵線程組 - 添加 - 監(jiān)聽器 - 聚合報告。再加一個響應(yīng)斷言右鍵HTTP請求 - 添加 - 斷言 - 響應(yīng)斷言。配置要點是在測試字段里選擇響應(yīng)文本模式匹配規(guī)則選擇包含然后填入你接口返回的成功標志。比如這個登錄接口在用戶名密碼正確時返回字符串包含code:200斷言就填code:200。注意模式匹配里的引號要跟響應(yīng)體嚴格一致最好從實際響應(yīng)里復(fù)制過去避免引號中英文不一致的問題。加上斷言的目的是讓壓測結(jié)果里的錯誤率有意義。否則即使服務(wù)端并發(fā)一高就開始返回空頁面或500只要TCP連接建立成功JMeter也會把它當成成功請求。4.5 命令行無界面運行正式壓測的正確姿勢圖形界面跑壓測很方便但正式跑大量并發(fā)時建議切換到命令行模式。原因很簡單圖形界面本身會消耗較多CPU和內(nèi)存資源你要壓服務(wù)端結(jié)果壓測機先被自己拖垮了。命令行模式只保留最小運行開銷壓測數(shù)據(jù)可以輸出到JTL文件中跑完之后再打開圖形界面分析。命令行運行的基本格式j(luò)meter -n -t /path/to/test_plan.jmx -l /path/to/result.jtl -e -o /path/to/report_html解釋一下參數(shù)-n無界面模式-t指定JMX腳本路徑-l指定結(jié)果文件路徑JTL格式本質(zhì)是CSV-e在測試結(jié)束后生成HTML報告-o指定HTML報告輸出目錄這個目錄必須不存在或為空否則會報錯跑完之后打開HTML報告能看到比聚合報告豐富得多的圖表吞吐量隨時間變化、響應(yīng)時間百分位分布、活躍線程數(shù)等。我一般會同時保留JTL文件后面需要分析某個時間段的詳細數(shù)據(jù)時再導入圖形界面。一個小建議正式壓測時腳本里的查看結(jié)果樹監(jiān)聽器要么刪除要么用命令行參數(shù)-n跑之前把它禁用。它在高并發(fā)下會記錄每個請求的完整請求和響應(yīng)內(nèi)容產(chǎn)生大量IO開銷很容易成為JMeter自身的性能瓶頸。5. 壓測實戰(zhàn)那些一定會遇到的坑和排查思路最后這部分我分享一些實際壓測中反復(fù)踩到的坑。這些內(nèi)容在官方文檔里通常不會細講但每個都是真實項目中遇到過的。5.1 Connection refused連接被拒端口耗盡問題很早以前做壓測時遇到過一種情況并發(fā)剛開始不高一切正常一旦線程數(shù)提上去錯誤率就出現(xiàn)大量Connection refused。服務(wù)端監(jiān)控顯示CPU、內(nèi)存都還很健康但就是大量連接建立失敗。排查下來發(fā)現(xiàn)問題出在壓測機自己的臨時端口上。Linux系統(tǒng)默認的臨時端口范圍一般是32768~60999總共約28232個端口。短連接場景下每發(fā)一個請求就要建一個TCP連接請求結(jié)束連接關(guān)閉端口會進入TIME_WAIT狀態(tài)需要等待一段時間才能被重用。如果每秒新建連接數(shù)遠超端口回收速度端口很快就消耗殆盡新的連接就會報refused。處理辦法有兩類修改系統(tǒng)內(nèi)核參數(shù)縮小TIME_WAIT等待時長增大臨時端口范圍。從腳本層面讓JMeter復(fù)用連接也就是開啟HTTP請求配置里的KeepAlive選項。HTTP信息頭管理器里加一個Connection: keep-alive這樣同一線程內(nèi)的請求可以復(fù)用TCP連接不再頻繁建立新連接。這對壓測結(jié)果也更貼近真實瀏覽器行為。第一條需要在壓測機上用root權(quán)限修改/etc/sysctl.conf臨時生效可以執(zhí)行sysctl -w net.ipv4.tcp_tw_reuse1 sysctl -w net.ipv4.ip_local_port_range1024 65535但要注意tcp_tw_reuse只對主動連接方生效且需要配合時間戳選項。改系統(tǒng)參數(shù)之前先確認壓測機是主動方同時和運維確認生產(chǎn)環(huán)境不允許這樣改一般只管壓測機。5.2 響應(yīng)超時的另一個元兇壓測機線程數(shù)太大有一次壓測某支付接口服務(wù)端日志顯示請求處理耗時極低但JMeter聚合報告里響應(yīng)時間平均值高得離譜。最后定位到問題出在JMeter本身線程數(shù)設(shè)了3000JMeter所在機器的CPU已經(jīng)90%以上大量線程在排隊等著被調(diào)度請求還沒發(fā)出去計時已經(jīng)開始了服務(wù)端還沒看到請求JMeter這邊已經(jīng)感覺等了很久。這個問題屬于典型的壓測工具自身成為瓶頸。解決辦法是降低單機線程數(shù)改用分布式壓測或者優(yōu)化腳本減少非必要的組件開銷。在我個人的經(jīng)驗里單機線程數(shù)一般不建議超過800~1000。如果壓測需求確實更高優(yōu)先考慮多臺執(zhí)行機分攤而不是死磕一臺機器。5.3 腳本里的硬編碼數(shù)據(jù)會讓壓測毫無意義一開始寫壓測腳本時最常見的偷懶寫法是所有用戶都用同一個賬號登錄同一個訂單號查詢。這樣壓出來的數(shù)據(jù)當然能跑但完全不代表真實場景。原因有兩點一是真實系統(tǒng)里每個用戶的數(shù)據(jù)狀態(tài)不同服務(wù)端對不同數(shù)據(jù)的處理邏輯復(fù)雜程度也不一樣。全部用同一個賬號很可能只是打了數(shù)據(jù)庫緩存的熱點數(shù)據(jù)得出的性能數(shù)明顯偏樂觀。二是某些系統(tǒng)有賬號互踢機制同一賬號被多個會話反復(fù)登錄會出現(xiàn)大量登錄失敗或會話失效但那不是服務(wù)端性能問題純粹是腳本設(shè)計不合理。解決辦法是參數(shù)化。JMeter里最常用的是CSV數(shù)據(jù)文件設(shè)置準備一個CSV文件每行是一個獨立的賬號密碼然后在HTTP請求里通過${變量名}引用。CSV配置里有個線程間共享模式默認所有線程共享文件指針每個線程取到的行會錯開如果你希望每個線程固定使用一行可以改成當前線程組模式。另一個提升腳本真實度的手段是關(guān)聯(lián)。登錄接口返回一個token后續(xù)的查詢接口需要header里帶這個token。這時候就要在登錄請求上添加后置處理器從響應(yīng)里提取token存成變量再在后續(xù)請求的信息頭管理器里引用。沒有這一步腳本就只能訪問不需要鑒權(quán)的接口壓測的目標很容易跑偏。5.4 定時器不是隨便加的線程睡眠還是持續(xù)壓力JMeter里有一種常數(shù)吞吐量定時器很多人用它來控制請求發(fā)送速率。但有個細節(jié)定時器是在每個取樣器之前執(zhí)行的它的sleep時間是在發(fā)起請求之前等待而不是在請求結(jié)束之后。這會導致一個微妙的問題如果服務(wù)端響應(yīng)越來越慢定時器等待加上請求等待的時間會越來越長實際吞吐量就會顯著下降。想模擬用戶思考時間可以使用固定定時器或高斯隨機定時器想控制整體QPS最好從線程數(shù)和循環(huán)次數(shù)入手而不是依賴定時器做精細化限速。我的原則是能用線程數(shù)解決的節(jié)奏問題就不要用定時器否則腳本越復(fù)雜排查問題越困難。5.5 聚合報告的指標到底該盯哪幾項面對聚合報告里近20個指標新手很容易陷入數(shù)字的海洋。我的建議是壓測時先盯四項Samples總請求數(shù)確認請求是否按預(yù)期跑完如果遠小于理論請求數(shù)先查是不是線程還沒全部啟動或者大量請求被提前中止。Error%錯誤率系統(tǒng)性能惡化的直接信號。但記得結(jié)合斷言判斷這些錯誤是連接層錯誤還是業(yè)務(wù)斷言錯誤處理思路完全不同。Average響應(yīng)時間 90% Line反映整體響應(yīng)體驗。如果Average不高但90% Line很高說明存在少量長期卡頓的請求需要看看是不是有GC停頓、慢請求堆積。Throughput吞吐量單位通常是每秒請求數(shù)。并發(fā)數(shù)固定不變時吞吐量不上漲反而下降往往意味著服務(wù)端已經(jīng)到瓶頸加用戶不再有意義。很多人喜歡追求高并發(fā)下依然低延遲的數(shù)字但真實系統(tǒng)里這幾乎不可能。性能測試的真正價值在于找到拐點并發(fā)到多少時吞吐量不再上升、響應(yīng)時間開始陡增。那個拐點就是系統(tǒng)的承載上限也是你做容量規(guī)劃時最重要的參考數(shù)字。另外提醒一下壓測結(jié)果必須結(jié)合服務(wù)端監(jiān)控一起看。JMeter的聚合報告只告訴你表現(xiàn)怎么樣不告訴你為什么這樣。如果響應(yīng)時間飆高你需要同時看服務(wù)端的CPU、內(nèi)存、磁盤IO、GC日志才能定位瓶頸在應(yīng)用層、數(shù)據(jù)庫還是帶寬。只看JMeter報告就下結(jié)論相當于只看體檢單上的指標卻不知道問題出在哪個器官很難給出有效的調(diào)優(yōu)方向。我在實際項目中養(yǎng)成的一個習慣是每次壓測都固定記錄一張表格包含日期、腳本版本、線程數(shù)、Ramp-Up時間、循環(huán)次數(shù)、平均響應(yīng)時間、90%響應(yīng)時間、錯誤率、吞吐量?？此坪唵蔚L期積累下來你能清晰看到系統(tǒng)每次改動前后的性能變化趨勢這在排查這次上線后系統(tǒng)變慢類問題時特別有用。性能問題往往不是單次壓測跑出來就結(jié)束的它更像一個需要持續(xù)跟蹤的過程。當你把壓測融入日常迭代很多線上故障在發(fā)生之前就已經(jīng)被攔下了。