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