做Java后端開(kāi)發(fā)寫(xiě)業(yè)務(wù)代碼只占工作的一半另一半是搞清楚這套代碼在真實(shí)流量下到底扛不扛得住。我第一次認(rèn)真接觸壓力測(cè)試是在一次大促前的容量評(píng)估上團(tuán)隊(duì)只有一臺(tái)配置很普通的測(cè)試機(jī)卻要預(yù)估訂單接口在高峰期能不能撐住。當(dāng)時(shí)用的就是 JMeter——一個(gè)用 Java 寫(xiě)的開(kāi)源壓測(cè)工具解壓就能跑不依賴(lài)數(shù)據(jù)庫(kù)不用改一行業(yè)務(wù)代碼靠圖形界面加上命令行就能把并發(fā)量拉起來(lái)。這篇文章我打算把 JMeter 從安裝到出完整報(bào)告的鏈路講透包括線程組參數(shù)怎么算、命令行怎么跑、那些讓人抓頭的報(bào)錯(cuò)怎么排查以及怎么把它和日常的接口測(cè)試流程揉到一起。適合誰(shuí)看如果你是 Java 后端想給自己負(fù)責(zé)的接口做一次靠譜的容量評(píng)估如果你是測(cè)試崗正在從功能測(cè)試往性能測(cè)試轉(zhuǎn)或者你只是面試被問(wèn)到JMeter 線程組參數(shù)怎么設(shè)置想弄明白原理這篇內(nèi)容都能對(duì)上。我不會(huì)只貼一遍點(diǎn)擊流程而是把每一步背后的邏輯講清楚讓你換個(gè)項(xiàng)目也知道怎么改。全文涉及的關(guān)鍵詞會(huì)自然散落在各節(jié)里比如 jmeter 安裝、jmeter 壓測(cè)簡(jiǎn)單步驟、jmeter 性能測(cè)試步驟、jmeter 接口測(cè)試教程需要哪塊直接跳過(guò)去看就行。1. 壓測(cè)這件事Java后端為什么繞不開(kāi)JMeter1.1 從一次接口變慢說(shuō)起壓測(cè)到底解決什么問(wèn)題講個(gè)真實(shí)場(chǎng)景。某個(gè)查詢接口單次調(diào)用耗時(shí)從 80ms 漲到 600ms肉眼在測(cè)試環(huán)境完全看不出來(lái)因?yàn)橹挥幸粋€(gè)人在點(diǎn)。上線之后并發(fā)一上來(lái)線程池排隊(duì)、數(shù)據(jù)庫(kù)連接池被占滿、上游服務(wù)超時(shí)重試雪崩就這么來(lái)了。壓測(cè)的意義在于把這個(gè)過(guò)程提前到上線之前用可控的并發(fā)量把潛在的瓶頸逼出來(lái)而不是等用戶在群里喊著頁(yè)面轉(zhuǎn)圈才開(kāi)始救火。還有一種情況是容量規(guī)劃。產(chǎn)品說(shuō)預(yù)計(jì)峰值每秒 300 單那后端到底要幾臺(tái)機(jī)器、數(shù)據(jù)庫(kù)要不要加讀寫(xiě)分離、緩存該給多大內(nèi)存這些數(shù)字不能拍腦袋。JMeter 能給你的是——在給定硬件條件下接口的吞吐量上限、響應(yīng)時(shí)間隨并發(fā)變化的曲線、以及開(kāi)始大面積報(bào)錯(cuò)的那個(gè)拐點(diǎn)在哪。有了這條曲線加機(jī)器的決策才有依據(jù)。我個(gè)人的判斷標(biāo)準(zhǔn)很樸素凡是會(huì)對(duì)外暴露、會(huì)被多個(gè)用戶同時(shí)調(diào)用的接口上線前都值得跑一次壓測(cè)。別等出了問(wèn)題再回頭補(bǔ)那時(shí)候成本高得多。1.2 JMeter、ab、wrk、Gatling 之間怎么選工具選型這塊很多人一上來(lái)就問(wèn)哪個(gè)最好其實(shí)取決于你的場(chǎng)景。ab 輕量適合快速壓一個(gè)靜態(tài)接口但它不支持復(fù)雜場(chǎng)景和參數(shù)化wrk 性能極強(qiáng)單機(jī)就能打出很高的 QPS但腳本要用 Lua 寫(xiě)對(duì) Java 同學(xué)不太友好Gatling 用 Scala DSL報(bào)告漂亮學(xué)習(xí)曲線偏陡。JMeter 的優(yōu)勢(shì)在于三點(diǎn)一是純 Java跨平臺(tái)和 Java 項(xiàng)目的技術(shù)棧天然接近懂 Java 的人上手很快二是圖形界面加上豐富的元件取樣器、邏輯控制器、斷言、監(jiān)聽(tīng)器不用寫(xiě)代碼就能搭出登錄、下單、支付這種多步驟業(yè)務(wù)流三是插件生態(tài)成熟數(shù)據(jù)庫(kù)、MQTT、Kafka 之類(lèi)的協(xié)議都有現(xiàn)成擴(kuò)展。缺點(diǎn)也明顯——GUI 本身吃資源所以正式壓測(cè)必須走命令行。我的建議是做接口級(jí)、業(yè)務(wù)級(jí)的場(chǎng)景壓測(cè)選 JMeter做單接口的極限 QPS 摸底可以用 wrk 交叉驗(yàn)證。兩個(gè)工具跑出來(lái)的數(shù)字對(duì)不上是常事這時(shí)候更該懷疑的是壓測(cè)機(jī)本身的瓶頸而不是工具。1.3 裝 JMeter 之前先把 JDK 環(huán)境理順JMeter 是 Java 寫(xiě)的所以第一件事是確認(rèn)本地 JDK。這里有個(gè)坑JMeter 5.4 以后至少要 JDK 8JMeter 5.6 及以上建議 JDK 17。如果你機(jī)器上裝的是 JDK 8直接下最新版 JMeter 可能啟動(dòng)就報(bào)版本不支持。我的習(xí)慣是先java -version看一眼確認(rèn)版本對(duì)得上再下 JMeter。安裝步驟本身很簡(jiǎn)單去 Apache 官網(wǎng)下載二進(jìn)制包解壓到任意目錄配置好JMETER_HOME和PATH或者直接進(jìn)bin目錄雙擊jmeter.batWindows/jmetermacOS、Linux。如果雙擊一閃而過(guò)基本是 JAVA_HOME 沒(méi)配或者指向了 JRE 而不是 JDK這個(gè)在 jmeter 安裝教程里被反復(fù)提到但每年還是有人踩。還有一個(gè)容易忽略的點(diǎn)JMeter 默認(rèn)的堆內(nèi)存偏小正式壓測(cè)前建議改bin/jmeter或jmeter.bat里的HEAP參數(shù)比如設(shè)成-Xms1g -Xmx4g具體給多大取決于壓測(cè)機(jī)的物理內(nèi)存和你打算模擬的線程數(shù)。線程數(shù)一多GUI 模式的窗口會(huì)卡到?jīng)]法操作這也是為什么生產(chǎn)級(jí)壓測(cè)一定要用命令行。2. JMeter 內(nèi)部機(jī)制拆解元件、線程組與執(zhí)行順序2.1 測(cè)試計(jì)劃是一棵樹(shù)執(zhí)行順序有講究打開(kāi) JMeter 看到的那個(gè)左側(cè)樹(shù)形結(jié)構(gòu)不是隨便排的它代表真實(shí)的執(zhí)行順序。測(cè)試計(jì)劃Test Plan是根節(jié)點(diǎn)下面掛線程組Thread Group線程組下面掛取樣器Sampler、邏輯控制器Logic Controller、配置元件Config Element、前置處理器Pre-Processor、后置處理器Post-Processor、斷言Assertion、監(jiān)聽(tīng)器Listener。執(zhí)行時(shí)同一個(gè)線程組內(nèi)JMeter 按配置元件 → 前置處理器 → 定時(shí)器 → 取樣器 → 后置處理器 → 斷言 → 監(jiān)聽(tīng)器的順序走一遍。理解這個(gè)順序你才知道為什么有時(shí)候斷言沒(méi)生效、變量沒(méi)取到值——多半是元件掛錯(cuò)了層級(jí)或者作用域的先后順序搞反了。我見(jiàn)過(guò)最常見(jiàn)的錯(cuò)誤是把 HTTP 信息頭管理器掛在測(cè)試計(jì)劃根節(jié)點(diǎn)下然后想給不同線程組設(shè)置不同的 Content-Type。因?yàn)楦?jié)點(diǎn)下的配置元件對(duì)所有線程組生效后面掛的會(huì)覆蓋前面掛的結(jié)果就是怎么改都不對(duì)。正確做法是把信息頭管理器放到對(duì)應(yīng)線程組的內(nèi)部讓它只作用于那個(gè)線程組。2.2 線程組模型虛擬用戶、Ramp-up、循環(huán)次數(shù)到底怎么算線程組是 JMeter 壓測(cè)的核心三個(gè)參數(shù)必須搞懂參數(shù)含義設(shè)置邏輯線程數(shù)Number of Threads模擬的虛擬用戶數(shù)也就是并發(fā)數(shù)等于你預(yù)估的峰值并發(fā)或者你想驗(yàn)證的目標(biāo)并發(fā)Ramp-up Period多少秒內(nèi)把線程全部啟動(dòng)完越小越猛0 表示瞬間啟動(dòng)一般設(shè)為線程數(shù)的 1/5 到 1/10循環(huán)次數(shù)Loop Count每個(gè)線程執(zhí)行多少輪決定測(cè)試總時(shí)長(zhǎng)勾選永遠(yuǎn)則配合調(diào)度器定時(shí)停止舉個(gè)具體例子。你想模擬 100 個(gè)用戶并發(fā)Ramp-up 設(shè)為 10 秒循環(huán)次數(shù)設(shè)為 10那么總請(qǐng)求數(shù)大約是 100 × 10 1000 次前提是單線程每輪只發(fā)一個(gè)請(qǐng)求。Ramp-up 10 意味著每秒啟動(dòng) 10 個(gè)線程壓力是線性爬升的這更接近真實(shí)的用戶涌入過(guò)程。為什么不要一上來(lái)就把 Ramp-up 設(shè)成 0因?yàn)樗查g啟動(dòng) 100 個(gè)線程壓測(cè)機(jī)自己的 CPU 和網(wǎng)絡(luò)會(huì)先被自己打滿你測(cè)到的響應(yīng)時(shí)間里混進(jìn)了大量本機(jī)調(diào)度開(kāi)銷(xiāo)數(shù)據(jù)就失真了。真正靠譜的做法是先用較大的 Ramp-up 找到服務(wù)端的能力邊界再用陡峭的負(fù)載驗(yàn)證穩(wěn)定性。關(guān)于jmeter 模擬 100 用戶并發(fā)報(bào)告這個(gè)常見(jiàn)需求線程數(shù)填 100 只是第一步后面的監(jiān)聽(tīng)器和報(bào)告怎么配才是重點(diǎn)這個(gè)放到第 4 節(jié)細(xì)說(shuō)。2.3 作用域規(guī)則為什么你的斷言老是不生效JMeter 的元件有作用域概念而這個(gè)概念坑了無(wú)數(shù)新手。簡(jiǎn)單說(shuō)一個(gè)元件的作用域是它的父節(jié)點(diǎn)及其所有子節(jié)點(diǎn)。你把斷言掛在線程組下面它對(duì)這個(gè)線程組里所有取樣器都生效你掛在某個(gè) HTTP 請(qǐng)求下面它只對(duì)這個(gè)請(qǐng)求生效。有個(gè)真實(shí)案例同事寫(xiě)了個(gè)壓測(cè)腳本登錄接口的斷言一直通不過(guò)排查半天發(fā)現(xiàn)斷言掛在了一個(gè)復(fù)用的HTTP 請(qǐng)求默認(rèn)值配置元件下面而那個(gè)元件根本沒(méi)掛在登錄請(qǐng)求的父鏈路上。元件掛錯(cuò)位置JMeter 不報(bào)錯(cuò)就是靜默不生效特別容易浪費(fèi)時(shí)間。我的經(jīng)驗(yàn)是把斷言盡量靠近對(duì)應(yīng)的取樣器掛尤其是多個(gè)接口用了不同的成功判定標(biāo)準(zhǔn)時(shí)。別圖省事全掛線程組下面否則一個(gè)接口的失敗會(huì)污染整個(gè)線程組的成功判定報(bào)告里看不出到底是哪個(gè)環(huán)節(jié)出的問(wèn)題。3. 手把手搭一個(gè)能復(fù)用的 HTTP 壓測(cè)腳本3.1 測(cè)試計(jì)劃骨架與 HTTP 請(qǐng)求默認(rèn)值先說(shuō)骨架怎么搭。新建測(cè)試計(jì)劃之后第一件事是加一個(gè)線程組。然后加HTTP 請(qǐng)求默認(rèn)值配置元件把協(xié)議、服務(wù)器域名或 IP、端口、編碼這些公共信息填進(jìn)去。后面所有 HTTP 取樣器只要填路徑和方法就行改動(dòng)服務(wù)器地址時(shí)只改一處這是腳本可復(fù)用性的關(guān)鍵。如果你的接口需要登錄態(tài)還得加一個(gè)HTTP Cookie 管理器。這個(gè)管理器有個(gè)開(kāi)關(guān)叫每次迭代清除 Cookie壓測(cè)時(shí)一般關(guān)掉讓同一線程復(fù)用會(huì)話接口測(cè)試時(shí)反而要打開(kāi)模擬不同用戶。這個(gè)開(kāi)關(guān)在不同場(chǎng)景下的用法完全相反值得單獨(dú)留意。接著加HTTP 信息頭管理器常見(jiàn)的Content-Type: application/json、Accept: application/json都放這里。如果接口需要 Token可以從登錄請(qǐng)求的后置處理器里提取然后用變量引用的方式塞進(jìn)信息頭形成登錄—提取—帶 Token 請(qǐng)求的完整鏈路。整套骨架搭完你的腳本結(jié)構(gòu)應(yīng)該是清晰的線程組下面掛配置元件配置元件下面掛業(yè)務(wù)取樣器。這樣別人接手你的腳本五分鐘就能看懂哪塊是環(huán)境配置、哪塊是業(yè)務(wù)邏輯。3.2 參數(shù)化CSV 數(shù)據(jù)文件與函數(shù)助手壓測(cè)腳本如果所有請(qǐng)求都用同一份參數(shù)緩存命中率會(huì)異常高測(cè)出來(lái)的 QPS 虛高。真實(shí)場(chǎng)景里每個(gè)用戶的手機(jī)號(hào)、訂單號(hào)、查詢條件都不一樣所以參數(shù)化是必須的。最常用的是 CSV Data Set Config。準(zhǔn)備一個(gè).csv文件一行一條數(shù)據(jù)配置元件里指定文件路徑、變量名、分隔符、是否循環(huán)讀取。然后在請(qǐng)求里用${變量名}引用。注意幾個(gè)細(xì)節(jié)文件編碼最好用 UTF-8避免中文亂碼Recycle on EOF控制讀完是否重頭再來(lái)Stop thread on EOF控制讀完后是否停止線程。壓測(cè)時(shí)通常設(shè)成允許循環(huán)接口測(cè)試時(shí)設(shè)成讀完停止。另一個(gè)利器是函數(shù)助手Function Helper菜單里打開(kāi)。比如__Random生成隨機(jī)數(shù)、__UUID生成唯一標(biāo)識(shí)、__time生成時(shí)間戳、__counter生成自增序號(hào)。做冪等性測(cè)試時(shí)用__UUID給每個(gè)請(qǐng)求生成唯一業(yè)務(wù)號(hào)能有效避免重復(fù)提交被攔截這種干擾。參數(shù)化有個(gè)隱形收益它能幫你發(fā)現(xiàn)代碼里的線程安全問(wèn)題。單線程跑得好好的接口一旦參數(shù)換成不同數(shù)據(jù)、并發(fā)上來(lái)之后開(kāi)始報(bào)數(shù)據(jù)錯(cuò)亂那多半是共享變量沒(méi)加鎖或者用了非線程安全的集合。這種問(wèn)題用單測(cè)基本測(cè)不出來(lái)。關(guān)于jmeter restful 參數(shù)怎么寫(xiě)我的習(xí)慣是GET 請(qǐng)求參數(shù)放Parameters標(biāo)簽POST、PUT 請(qǐng)求的 JSON 放Body Data標(biāo)簽同時(shí)信息頭里聲明application/json。不要在 Body Data 里手動(dòng)拼 URL 編碼JMeter 不會(huì)幫你轉(zhuǎn)義容易出問(wèn)題。3.3 斷言設(shè)計(jì)響應(yīng)斷言與 JSON 斷言沒(méi)有斷言的壓測(cè)腳本等于沒(méi)做壓測(cè)。因?yàn)?HTTP 狀態(tài)碼 200 不代表業(yè)務(wù)成功——很多系統(tǒng)出錯(cuò)時(shí)也返回 200把錯(cuò)誤信息塞在響應(yīng)體里。這時(shí)候如果不斷言業(yè)務(wù)字段報(bào)告會(huì)告訴你錯(cuò)誤率 0%實(shí)際上接口全程在返回失敗?；A(chǔ)的用響應(yīng)斷言Response Assertion可以匹配響應(yīng)文本、響應(yīng)碼、響應(yīng)頭。比如判斷響應(yīng)體是否包含code:0或者判斷響應(yīng)碼是否等于 200。更推薦的是 JSON 斷言用 JSONPath 表達(dá)式直接提取字段判斷。比如$.code等于 0、$.data.orderId存在。JSONPath 的好處是不依賴(lài)字段順序和空白字符比字符串包含判斷更穩(wěn)。注意斷言別設(shè)太嚴(yán)格。曾經(jīng)有個(gè)腳本用響應(yīng)體完全相等做斷言結(jié)果接口多返回了一個(gè)traceId字段就全線報(bào)錯(cuò)實(shí)際業(yè)務(wù)毫無(wú)問(wèn)題。斷言的目標(biāo)是判斷業(yè)務(wù)是否成功不是做全字段比對(duì)。如果接口返回結(jié)構(gòu)復(fù)雜用 JSON 斷言配合多個(gè) JSONPath 組合判斷是性價(jià)比最高的方案。既不用寫(xiě)代碼又能覆蓋核心字段。3.4 結(jié)果收集結(jié)果樹(shù)、聚合報(bào)告與 HTML 報(bào)告導(dǎo)出監(jiān)聽(tīng)器負(fù)責(zé)收數(shù)據(jù)但它在 GUI 模式下非常吃內(nèi)存正式壓測(cè)要把它們都禁用。常用的幾個(gè)察看結(jié)果樹(shù)View Results Tree調(diào)試用能看到每個(gè)請(qǐng)求的請(qǐng)求頭、請(qǐng)求體、響應(yīng)體排查問(wèn)題神器。但它會(huì)把所有響應(yīng)存在內(nèi)存里壓測(cè)時(shí)開(kāi)著準(zhǔn)崩。聚合報(bào)告Aggregate Report給出樣本數(shù)、平均值、中位數(shù)、90% 線、95% 線、99% 線、最小值、最大值、錯(cuò)誤率、吞吐量。這是最常用的性能指標(biāo)來(lái)源。匯總報(bào)告Summary Report和聚合報(bào)告類(lèi)似字段略有差別。說(shuō)到j(luò)meter 察看結(jié)果樹(shù)導(dǎo)出很多人想在 GUI 里把結(jié)果導(dǎo)出成 CSV。結(jié)果樹(shù)左上角有個(gè)Save Table Data按鈕但它有個(gè)坑——數(shù)據(jù)量大的時(shí)候點(diǎn)下去要等很久而且容易卡死。更靠譜的做法是壓測(cè)時(shí)直接配置簡(jiǎn)單數(shù)據(jù)寫(xiě)入器Simple Data Writer或者命令行-l參數(shù)直接落盤(pán)成.jtl文件事后分析。圖形化報(bào)告是 JMeter 3.0 之后的重頭戲。命令行加上-e -o 報(bào)告目錄就能生成一套包含 TPS 曲線、響應(yīng)時(shí)間分布、錯(cuò)誤率趨勢(shì)的 HTML dashboard。這套報(bào)告拿去給團(tuán)隊(duì)看非常直觀比貼一堆數(shù)字強(qiáng)多了。3.5 非 GUI 命令行壓測(cè)參數(shù)到底怎么寫(xiě)正式壓測(cè)必須用命令行這是鐵律。GUI 模式本身要消耗 CPU 和內(nèi)存去渲染界面幾百個(gè)線程一開(kāi)界面卡死不說(shuō)測(cè)出的數(shù)據(jù)也不準(zhǔn)。命令行模板大概長(zhǎng)這樣jmeter -n -t order_test.jmx -l result.jtl -e -o ./report參數(shù)逐個(gè)說(shuō)-n表示非 GUI 模式-t指定測(cè)試計(jì)劃文件-l指定結(jié)果文件如果文件已存在會(huì)報(bào)錯(cuò)記得先刪或者換名-e表示壓測(cè)結(jié)束后生成 HTML 報(bào)告-o指定報(bào)告輸出目錄目錄必須為空否則報(bào)錯(cuò)。另外幾個(gè)常用參數(shù)-J用來(lái)覆蓋 JMeter 屬性比如-JthreadNum200可以在不改腳本的情況下改變量-r是分布式壓測(cè)時(shí)啟動(dòng)遠(yuǎn)程節(jié)點(diǎn)用的。分布式這塊一般單機(jī)壓不夠了才上注意主從機(jī)器的 JMeter 版本要一致防火墻端口要放開(kāi)。我踩過(guò)的一個(gè)坑壓測(cè)腳本里的線程數(shù)寫(xiě)死在 jmx 里每次調(diào)整都要開(kāi) GUI 改一遍再保存。后來(lái)學(xué)會(huì)用${__P(threads,100)}這種屬性引用的寫(xiě)法配合命令行-Jthreads500傳參改并發(fā)量再也不用開(kāi)界面了效率高很多。4. 高頻報(bào)錯(cuò)與排查速查表4.1 error writing to server 到底在說(shuō)什么java.io.IOException: Error writing to server是 JMeter 壓測(cè)里出現(xiàn)頻率最高的報(bào)錯(cuò)之一。字面意思是往服務(wù)端寫(xiě)數(shù)據(jù)時(shí)出錯(cuò)但它背后可能是好幾類(lèi)原因得逐個(gè)排除。第一種壓測(cè)機(jī)本地端口耗盡。客戶端每次建立 TCP 連接都會(huì)占用一個(gè)本地端口連接關(guān)閉后進(jìn)入 TIME_WAIT 狀態(tài)默認(rèn)要等 60 秒才能復(fù)用。幾百個(gè)線程高頻率請(qǐng)求端口很快就不夠用了。查看net.ipv4.ip_local_port_range和net.ipv4.tcp_tw_reuse這兩個(gè)內(nèi)核參數(shù)適當(dāng)擴(kuò)大端口范圍和開(kāi)啟 TIME_WAIT 復(fù)用能明顯緩解。第二種壓測(cè)機(jī)文件句柄數(shù)不夠。每個(gè) TCP 連接都占一個(gè)文件描述符ulimit -n默認(rèn)可能是 1024幾百個(gè)并發(fā)就頂?shù)搅?。用ulimit -n 65535臨時(shí)放大或者改系統(tǒng)配置永久生效。第三種服務(wù)端主動(dòng)斷連。比如服務(wù)端設(shè)置了 keep-alive 超時(shí)時(shí)間比客戶端的短服務(wù)端先關(guān)連接客戶端再寫(xiě)數(shù)據(jù)就報(bào)錯(cuò)。這時(shí)候要么調(diào)服務(wù)端超時(shí)要么在 JMeter 的 HTTP 取樣器里調(diào)整連接超時(shí)和響應(yīng)超時(shí)參數(shù)讓客戶端主動(dòng)控制連接生命周期。第四種網(wǎng)絡(luò)中間設(shè)備負(fù)載均衡、防火墻有并發(fā)或連接數(shù)限制超過(guò)閾值就重置連接。這種需要聯(lián)系運(yùn)維確認(rèn)。提示遇到這個(gè)錯(cuò)誤別急著改代碼先按本機(jī)資源 → 網(wǎng)絡(luò)中間層 → 服務(wù)端的順序逐層排查。我見(jiàn)過(guò)太多次問(wèn)題根本不在被測(cè)服務(wù)上。4.2 域名解析、連接超時(shí)與端口耗盡的區(qū)分報(bào)錯(cuò)信息不同排查方向完全不同整理成一張速查表更直觀報(bào)錯(cuò)關(guān)鍵詞常見(jiàn)原因排查動(dòng)作UnknownHostException域名解析失敗檢查 hosts、DNS 配置或直接用 IP 測(cè)試ConnectException / Connection refused目標(biāo)端口沒(méi)監(jiān)聽(tīng)或服務(wù)未啟動(dòng)用 telnet 或 nc 確認(rèn)端口連通性SocketTimeoutException響應(yīng)超時(shí)調(diào)大 JMeter 超時(shí)參數(shù)同時(shí)看服務(wù)端是否卡住Error writing to server端口耗盡、句柄不足、服務(wù)端斷連檢查內(nèi)核參數(shù)、ulimit抓包看誰(shuí)先斷OutOfMemoryErrorJMeter 自身堆溢出調(diào)大 HEAP 參數(shù)禁用結(jié)果樹(shù)監(jiān)聽(tīng)器這張表我?guī)缀趺看螇簻y(cè)前都會(huì)在腦子里過(guò)一遍。提前知道大概會(huì)遇到什么排查起來(lái)至少不會(huì)慌。另外強(qiáng)烈建議學(xué)會(huì)用netstat或者ss看連接狀態(tài)分布TIME_WAIT 和 ESTABLISHED 各有多少一眼就能看出是不是本機(jī)端口的問(wèn)題。4.3 壓測(cè)結(jié)果怎么讀TPS、RT、錯(cuò)誤率的三角關(guān)系很多人拿到聚合報(bào)告只看平均值這是個(gè)壞習(xí)慣。平均值會(huì)被少量極端值拉偏真正有參考價(jià)值的是 90%、95%、99% 分位線。比如平均響應(yīng)時(shí)間 50ms 看著很漂亮但 99% 線是 2000ms說(shuō)明每 100 個(gè)請(qǐng)求就有一個(gè)用戶等了兩秒這個(gè)體驗(yàn)是很差的。TPS每秒事務(wù)數(shù)不是孤立看的它和響應(yīng)時(shí)間、并發(fā)數(shù)之間有個(gè)近似關(guān)系并發(fā)數(shù) ≈ TPS × 平均響應(yīng)時(shí)間。所以你會(huì)看到隨著并發(fā)數(shù)增加TPS 先上升到達(dá)某個(gè)點(diǎn)后趨于平緩甚至下降而響應(yīng)時(shí)間開(kāi)始飆升——那個(gè)轉(zhuǎn)折點(diǎn)就是系統(tǒng)的容量拐點(diǎn)。錯(cuò)誤率也很關(guān)鍵。如果錯(cuò)誤率突然從 0 漲到 5%同時(shí) TPS 不升反降說(shuō)明系統(tǒng)已經(jīng)過(guò)載線程在排隊(duì)重試。這時(shí)候繼續(xù)加壓沒(méi)意義應(yīng)該回頭找瓶頸是數(shù)據(jù)庫(kù)慢查詢、線程池滿了還是緩存穿透。我的習(xí)慣是每個(gè)壓測(cè)場(chǎng)景至少跑三檔并發(fā)低檔確認(rèn)功能正常中檔看性能曲線高檔找極限。單跑一檔數(shù)據(jù)說(shuō)明不了太多問(wèn)題。4.4 壓測(cè)機(jī)自身的瓶頸排除這是最容易被忽略的一環(huán)。你有沒(méi)有想過(guò)你測(cè)出來(lái)的服務(wù)端性能上限可能其實(shí)是壓測(cè)機(jī)自己的上限判斷方法很簡(jiǎn)單壓測(cè)時(shí)同時(shí)監(jiān)控壓測(cè)機(jī)的 CPU、內(nèi)存、網(wǎng)絡(luò)帶寬和句柄數(shù)。如果壓測(cè)機(jī) CPU 跑滿、網(wǎng)卡帶寬打滿那測(cè)出來(lái)的數(shù)字就不可信。千兆網(wǎng)卡的實(shí)際上限大概在 900Mbps 左右換算下來(lái)如果單個(gè)響應(yīng)體是 100KB理論最大也就每秒一千來(lái)個(gè)請(qǐng)求。解決辦法有幾個(gè)把響應(yīng)體裁剪掉只壓接口邏輯不壓傳輸、啟用 gzip 壓縮、或者上分布式壓測(cè)用多臺(tái)機(jī)器分?jǐn)倝毫Α＿€有個(gè)小技巧是加常量吞吐量定時(shí)器把壓力穩(wěn)定在某個(gè)值避免瞬間峰值觸發(fā)本機(jī)瓶頸這樣數(shù)據(jù)更干凈。5. 進(jìn)階玩法錄制、數(shù)據(jù)庫(kù)參數(shù)化與 Beanshell 斷言5.1 HTTPS 腳本錄制與證書(shū)導(dǎo)入手工敲每個(gè)請(qǐng)求太慢尤其是接口多、參數(shù)復(fù)雜的業(yè)務(wù)流。JMeter 自帶的 HTTP(S) Test Script Recorder測(cè)試腳本錄制器能幫你自動(dòng)生成腳本。原理是它在本地監(jiān)聽(tīng)一個(gè)端口把瀏覽器的請(qǐng)求先轉(zhuǎn)到這個(gè)端口JMeter 記錄下流量再轉(zhuǎn)給真實(shí)服務(wù)端。HTTPS 場(chǎng)景會(huì)多一步JMeter 需要用它自己生成的證書(shū)來(lái)解密流量。這個(gè)證書(shū)在錄制器啟動(dòng)時(shí)自動(dòng)生成路徑通常在bin目錄下文件名是ApacheJMeterTemporaryRootCA.crt。要把這個(gè)證書(shū)導(dǎo)入到系統(tǒng)或?yàn)g覽器的信任列表里瀏覽器才會(huì)接受錄制器的解密。不導(dǎo)入的話HTTPS 請(qǐng)求會(huì)報(bào)證書(shū)錯(cuò)誤錄不全。關(guān)于jmeter 安全證書(shū)還有個(gè)常見(jiàn)困惑錄制結(jié)束后要不要把這個(gè)信任刪掉建議刪掉因?yàn)樗桥R時(shí)證書(shū)留在信任列表里沒(méi)有意義。另外生產(chǎn)環(huán)境的證書(shū)和這個(gè)臨時(shí)證書(shū)是兩回事別搞混。錄制出來(lái)的腳本通常有一堆冗余請(qǐng)求圖片、樣式、靜態(tài)資源需要手動(dòng)刪掉只保留接口請(qǐng)求。參數(shù)化也要重新做因?yàn)殇浵聛?lái)的都是固定值。所以錄制只是省了敲 URL 的功夫真正有價(jià)值的整理工作還得自己來(lái)。5.2 數(shù)據(jù)庫(kù)參數(shù)化取值JDBC 取數(shù)的完整鏈路壓測(cè)時(shí)如果參數(shù)需要從數(shù)據(jù)庫(kù)里查比如從訂單表里取 1000 個(gè)真實(shí)訂單號(hào)來(lái)壓查詢接口就要用到 JDBC 系列元件。完整鏈路是這樣先加JDBC Connection Configuration配置元件填數(shù)據(jù)庫(kù) URL、驅(qū)動(dòng)類(lèi)名、用戶名密碼。注意驅(qū)動(dòng) jar 要放到lib目錄下不然會(huì)報(bào) ClassNotFound。然后加一個(gè)JDBC Request取樣器寫(xiě) SQL 查詢?cè)赩ariable Names里給每一列起個(gè)變量名。查詢結(jié)果會(huì)被存進(jìn)這些變量最后在業(yè)務(wù)請(qǐng)求里用${變量名_1}、${變量名_2}這種方式按行引用。這里有個(gè)細(xì)節(jié)JDBC Request 有個(gè)Max Number of Rows to Retain參數(shù)控制一次取多少行。如果 SQL 返回幾千行全存內(nèi)存JMeter 堆會(huì)吃不消。建議配合LIMIT分批取或者把這個(gè)值設(shè)小一點(diǎn)。還有個(gè)常見(jiàn)問(wèn)題是連接池。JMeter 的 JDBC 配置默認(rèn)會(huì)維護(hù)連接池Max Number of Connections設(shè)太小壓測(cè)時(shí)數(shù)據(jù)庫(kù)取數(shù)會(huì)變成瓶頸。這個(gè)值一般要大于等于線程數(shù)。至于jmeter 數(shù)據(jù)庫(kù)參數(shù)化取值的具體寫(xiě)法SQL 里記得加排序因?yàn)椴槐ＷC順序的話多線程取數(shù)會(huì)亂序影響結(jié)果可復(fù)現(xiàn)性。5.3 Beanshell 與 JSR223 斷言什么時(shí)候用哪個(gè)內(nèi)置的響應(yīng)斷言和 JSON 斷言能覆蓋大部分場(chǎng)景但有些業(yè)務(wù)判斷邏輯特別復(fù)雜比如響應(yīng)里的金額字段必須等于請(qǐng)求里的金額乘以折扣率這種就得寫(xiě)代碼。Beanshell 斷言可以直接寫(xiě) Java 代碼用prev對(duì)象拿響應(yīng)數(shù)據(jù)String resp prev.getResponseDataAsString(); if (!resp.contains(\code\:0)) { prev.setSuccessful(false); prev.setResponseMessage(業(yè)務(wù)碼校驗(yàn)失敗: resp); }不過(guò)現(xiàn)在更推薦用 JSR223 斷言配合 Groovy 語(yǔ)言。原因很實(shí)際Beanshell 是解釋執(zhí)行的并發(fā)高的時(shí)候性能很差本身就成瓶頸Groovy 支持 JIT 編譯JMeter 還會(huì)緩存編譯后的腳本執(zhí)行效率高一個(gè)檔次。寫(xiě)法上差別不大def json new groovy.json.JsonSlurper().parseText(prev.getResponseDataAsString()) if (json.code ! 0) { prev.setSuccessful(false) prev.setResponseMessage(業(yè)務(wù)碼校驗(yàn)失敗: ${json.msg}) }注意不管是 Beanshell 還是 JSR223都別在腳本里寫(xiě)太重的邏輯。斷言執(zhí)行次數(shù)等于請(qǐng)求數(shù)每個(gè)請(qǐng)求都跑一遍稍微慢一點(diǎn)就會(huì)被放大成幾倍的性能損耗。我的經(jīng)驗(yàn)是優(yōu)先用內(nèi)置斷言能用 JSONPath 表達(dá)的絕不上腳本。腳本只用來(lái)處理內(nèi)置元件搞不定的邊界情況。5.4 插件擴(kuò)展MQTT 及其它協(xié)議怎么補(bǔ)JMeter 本體只覆蓋 HTTP、JDBC、FTP 等常見(jiàn)協(xié)議遇到 MQTT、Kafka、gRPC 這些就得靠插件。JMeter Plugins Manager 是管理插件的好幫手裝一次之后在界面里就能搜索安裝。MQTT 場(chǎng)景下需要下載 MQTT 插件把 jar 包放到lib/ext目錄重啟 JMeter 就能看到 MQTT 相關(guān)元件。MQTT 連接配置里要填 Broker 地址、客戶端 ID、QoS 等級(jí)、Keep Alive 時(shí)間這些。壓測(cè)時(shí)注意客戶端 ID 要唯一用__UUID或者變量生成否則多個(gè)線程用同一個(gè) ID 會(huì)互相踢下線。插件雖好但要注意版本兼容。JMeter 版本升級(jí)后老插件可能不兼容表現(xiàn)為重啟后元件消失或者直接報(bào)錯(cuò)。建議把插件版本和 JMeter 版本對(duì)應(yīng)關(guān)系記錄在項(xiàng)目文檔里團(tuán)隊(duì)換人時(shí)不至于抓瞎。6. 把 JMeter 接進(jìn)日常流程6.1 接口測(cè)試與壓測(cè)腳本復(fù)用很多團(tuán)隊(duì)把接口測(cè)試和壓力測(cè)試當(dāng)成兩件事維護(hù)兩套腳本其實(shí)完全可以復(fù)用。同一個(gè).jmx文件接口測(cè)試時(shí)線程數(shù)設(shè) 1、循環(huán) 1 次、開(kāi)啟結(jié)果樹(shù)和斷言壓測(cè)時(shí)改命令行參數(shù)、關(guān)掉 GUI 監(jiān)聽(tīng)器、拉高并發(fā)。腳本主體請(qǐng)求、斷言、參數(shù)化完全一樣。這樣做的好處是接口改了只要維護(hù)一份腳本就夠接口測(cè)試通過(guò)之后壓測(cè)腳本天然是功能正確的狀態(tài)不會(huì)因?yàn)槟_本本身寫(xiě)錯(cuò)導(dǎo)致壓測(cè)數(shù)據(jù)失真。用-J參數(shù)傳線程數(shù)、循環(huán)數(shù)、服務(wù)器地址就能做到一套腳本多種用途。我負(fù)責(zé)的項(xiàng)目里jmx腳本是跟著代碼一起提交到版本庫(kù)的。接口一改先跑接口測(cè)試模式驗(yàn)證再跑壓測(cè)模式評(píng)估影響流程很順。6.2 與構(gòu)建流程銜接的思路更進(jìn)一步可以把命令行壓測(cè)接進(jìn)持續(xù)集成流程。比如每次發(fā)布前自動(dòng)拉起一個(gè)測(cè)試環(huán)境跑一輪基準(zhǔn)壓測(cè)把 TPS 和響應(yīng)時(shí)間記錄下來(lái)和歷史對(duì)比。如果新版本性能下降超過(guò)閾值就卡住發(fā)布。實(shí)現(xiàn)思路不復(fù)雜CI 腳本里調(diào)用jmeter -n -t ... -l ... -e -o ...然后解析生成的 CSV 或者 HTML 報(bào)告用腳本提取關(guān)鍵指標(biāo)做對(duì)比。JMeter 本身也支持在測(cè)試計(jì)劃里用斷言判斷吞吐量是否達(dá)標(biāo)不達(dá)標(biāo)直接讓整個(gè)構(gòu)建失敗。難點(diǎn)不在工具而在于環(huán)境的一致性。壓測(cè)機(jī)的配置、網(wǎng)絡(luò)環(huán)境、服務(wù)端數(shù)據(jù)量每次都要盡量保持一致否則數(shù)字沒(méi)法橫向比較。我一般會(huì)在壓測(cè)前用同一套初始化腳本重置數(shù)據(jù)保證每次基線一致。做到這一點(diǎn)壓測(cè)數(shù)據(jù)才有長(zhǎng)期參考價(jià)值否則只是一次性的數(shù)字游戲。最后分享一點(diǎn)個(gè)人體會(huì)。我剛開(kāi)始做壓測(cè)時(shí)特別執(zhí)著于跑出一個(gè)漂亮的 TPS 數(shù)字后來(lái)發(fā)現(xiàn)真正有價(jià)值的是排查過(guò)程中發(fā)現(xiàn)的問(wèn)題——慢查詢、連接池配置不合理、鎖競(jìng)爭(zhēng)、緩存擊穿這些才是壓測(cè)的產(chǎn)出。數(shù)字只是結(jié)果瓶頸才是財(cái)富。現(xiàn)在每次壓測(cè)完我都會(huì)認(rèn)真整理一份分析記錄這次找到了什么問(wèn)題、定位過(guò)程是怎樣的、怎么解決的。攢上幾次之后團(tuán)隊(duì)對(duì)系統(tǒng)的理解會(huì)深很多下次遇到線上波動(dòng)也不至于手忙腳亂。