很多團隊一提性能測試第一反應(yīng)就是“拿Jmeter壓一下接口看看響應(yīng)時間長不長、有沒有報錯”。但真正經(jīng)歷過線上事故復(fù)盤的人會明白性能測試從來不是“壓一下看穩(wěn)不穩(wěn)”這么簡單。它背后是一件需要策略、指標體系和邊界條件支撐的系統(tǒng)工程。這篇內(nèi)容我想從“基礎(chǔ) 策略”兩個詞切入把性能測試的準備邏輯、核心指標、壓測策略和Jmeter實操串起來。無論你是剛接手性能測試的QA還是準備性能測試面試的測試開發(fā)這篇文章都值得當成一份“查漏補缺清單”來用。1. 為什么很多人做性能測試都在“走過場” —— 先搞清測試的層級工作里常見的一種現(xiàn)象是領(lǐng)導(dǎo)說“系統(tǒng)快上線了做一下性能測試”然后測試同學打開Jmeter創(chuàng)建一個線程組100個線程循環(huán)5次跑完看一眼聚合報告平均響應(yīng)時間200ms錯誤率0%發(fā)一封郵件說“性能驗證通過”。這個流程看起來很完整但本質(zhì)上只是把系統(tǒng)“壓了一遍”并沒有回答任何業(yè)務(wù)問題。我在復(fù)盤項目時習慣先問三個問題這次性能測試是為了驗證什么要在什么負載下驗證驗證通過的標準是什么如果這三個問題答不出來那無論跑的腳本多復(fù)雜報告上的數(shù)字多好看對決策都沒有幫助。1.1 性能測試的三個層級驗證、發(fā)現(xiàn)、預(yù)測按目的不同性能測試可以拆成三個層級。第一層是驗證系統(tǒng)“當前是否滿足預(yù)期”。這是最常見的訴求比如新功能上線前確認在預(yù)估的日常峰值下系統(tǒng)能穩(wěn)定運行錯誤率控制在允許范圍之內(nèi)。這一層的關(guān)鍵詞是“達標”指標有明確的驗收線適合用固定的業(yè)務(wù)模型去壓。第二層是發(fā)現(xiàn)系統(tǒng)“在什么條件下會出問題”。這層不再追求“過不過”而是追求“找到拐點”。比如TPS從200漲到300時響應(yīng)時間突然從150ms飆到2s這個拐點在哪里是什么資源先耗盡連接池還是數(shù)據(jù)庫連接線程棧還是消息隊列積壓。這一層對測試設(shè)計的要求更高需要你有意去構(gòu)造邊界、超配甚至破壞性場景。第三層是預(yù)測系統(tǒng)“未來能不能扛得住”。這層通常配合容量規(guī)劃和擴縮容來做比如雙11之前業(yè)務(wù)預(yù)估流量翻3倍那就要在壓測環(huán)境里模擬3倍的流量看系統(tǒng)需要擴容多少臺機器數(shù)據(jù)庫是否需要讀寫分離。這一層的產(chǎn)出不是一份“報告”而是一套“模型和預(yù)算”每臺機器的水位上限是多少加一臺機器能帶來多少TPS。很多團隊所謂的性能測試只停留在第一層甚至第一層都做得不嚴謹——沒有明確的業(yè)務(wù)模型沒有驗收閾值也沒有環(huán)境基線。這樣的結(jié)果對“能不能上線”沒有參考價值對“未來會不會出問題”更沒有預(yù)判能力。所以動手寫腳本之前先確定你自己正在做哪一個層級這決定了后面所有策略的選型。1.2 性能測試與功能測試的本質(zhì)區(qū)別功能測試驗證的是“對錯”性能測試驗證的是“快慢和穩(wěn)定”但這兩者在方法論上有很大的不同。功能測試的用例輸入輸出是確定的執(zhí)行一次就能得到明確結(jié)果性能測試是帶條件的統(tǒng)計實驗需要在特定并發(fā)、特定數(shù)據(jù)量、特定持續(xù)時間的組合下才能得出有效結(jié)論。功能測試失敗了可以直接提單性能測試“失敗”則是一個漸進過程——可能是響應(yīng)時間沒有達到SLO可能是錯誤率超過閾值也可能是資源利用率已經(jīng)90%但TPS還在原地踏步。這種區(qū)別決定了性能測試必須先把“邊界條件”定義清楚。同樣一個接口數(shù)據(jù)庫有1萬條數(shù)據(jù)和有1億條數(shù)據(jù)壓出來的結(jié)果完全不一樣同樣是200并發(fā)持續(xù)跑5分鐘和持續(xù)跑1小時對內(nèi)存泄漏的暴露能力也完全不同。所以性能測試里有一句老話“沒有邊界條件的數(shù)字都是無效數(shù)字?！?這部分內(nèi)容后面講Jmeter參數(shù)設(shè)計時還會反復(fù)提到。2. 先把這些指標吃透響應(yīng)時間、TPS、并發(fā)與資源水位性能測試看起來是在跟工具打交道實際上是在跟數(shù)字打交道。很多人剛開始接觸性能測試時被一堆術(shù)語搞得頭暈其實核心指標就那么幾個但它們之間的推導(dǎo)關(guān)系才是真正的重點。2.1 響應(yīng)時間與TPS一枚硬幣的兩面響應(yīng)時間Response TimeRT是一個請求從發(fā)出到收到響應(yīng)所經(jīng)歷的時間通常看平均值和百分位值。平均值很容易被極端值拉高或稀釋所以生產(chǎn)環(huán)境更看重TP95、TP99甚至TP999。比如某個接口平均響應(yīng)時間是200ms但TP99是1.2s說明有1%的請求體驗非常差這種“大部分請求良好、少量請求緩慢”的分布是典型的尾部延遲問題排查時需要關(guān)注GC停頓、線程排隊、網(wǎng)絡(luò)抖動等因素。TPSTransactions Per Second每秒事務(wù)數(shù)衡量的是系統(tǒng)每秒能處理多少業(yè)務(wù)事務(wù)。響應(yīng)時間和TPS本質(zhì)上是一體兩面響應(yīng)時間決定單筆業(yè)務(wù)要占住系統(tǒng)資源多久TPS決定單位時間內(nèi)系統(tǒng)能釋放多少處理能力。如果一個請求平均耗時500ms單線程每秒最多處理2個請求想要每秒處理100個請求至少需要50個線程同時處理。這里先引入一個小公式系統(tǒng)并發(fā)處理能力并發(fā)線程數(shù)≈ TPS × 平均響應(yīng)時間。這也是業(yè)內(nèi)常說的Little定律的一種工程化表達在一個穩(wěn)定的系統(tǒng)中正在處理的請求數(shù)等于是每秒新到的請求數(shù)乘以每個請求在系統(tǒng)里的停留時間。舉例來說如果目標是TPS500平均響應(yīng)時間0.2s那系統(tǒng)就需要能同時容納約500×0.2100個請求在處理中。這個數(shù)字直接決定你應(yīng)該把線程組壓到多少并發(fā)以及系統(tǒng)中的線程池、連接池配置是否夠用。2.2 在線用戶數(shù)、并發(fā)用戶數(shù)與Jmeter線程數(shù)的關(guān)系這是面試里高頻出現(xiàn)、也是新手最容易混淆的一組概念。在線用戶數(shù)Online Users是所有登錄了系統(tǒng)、停留在頁面上的人數(shù)他們不一定在發(fā)請求。并發(fā)用戶數(shù)Concurrent Users是在同一時刻真正對服務(wù)器發(fā)起請求的用戶數(shù)。一般在線用戶數(shù)遠大于并發(fā)用戶數(shù)。比如一個電商網(wǎng)站有10萬人在線但真正同時下單、瀏覽商品、觸發(fā)接口的可能只有幾千人。那怎么估算并發(fā)用戶數(shù)一個簡單經(jīng)驗是并發(fā)用戶數(shù) ≈ 在線用戶數(shù) × 業(yè)務(wù)操作頻率 × 單次操作平均耗時。比如某系統(tǒng)高峰期在線用戶10000人平均每人每60秒觸發(fā)一次操作單次操作平均耗時1秒那并發(fā)用戶數(shù) ≈ 10000 × (1/60) × 1 ≈ 167。這里用到的其實是前面說過的排隊論一分鐘觸發(fā)一次、每次處理1秒相當于每分鐘需要占用10000×110000秒的處理時間均攤到60秒里每秒需要約167個并發(fā)單元。Jmeter里的“線程數(shù)”在絕大多數(shù)壓測腳本里就對應(yīng)并發(fā)用戶數(shù)即同一時刻施加到服務(wù)器上的壓力單元數(shù)。需要留意的是Jmeter每個線程是獨立發(fā)送請求的線程組里設(shè)置了200個線程就意味著Jmeter會創(chuàng)建200個線程同時往服務(wù)器打請求所以這里的數(shù)字不應(yīng)該是“在線用戶數(shù)”而應(yīng)該是你估算出來的“并發(fā)用戶數(shù)”。2.3 資源利用率CPU、內(nèi)存、磁盤與網(wǎng)絡(luò)的水位判斷接口層指標只告訴你系統(tǒng)“快不快”資源水位才告訴你系統(tǒng)“撐不撐得住”。壓測過程中必須同步監(jiān)控應(yīng)用服務(wù)器、數(shù)據(jù)庫、緩存、消息隊列等組件的資源指標否則你永遠不知道瓶頸在哪一層。CPU如果CPU使用率長期在90%以上說明計算資源接近飽和。但要區(qū)分CPU是消耗在用戶態(tài)業(yè)務(wù)計算還是內(nèi)核態(tài)系統(tǒng)調(diào)用、鎖競爭還要看是單核打滿還是整體均勻。單核打滿往往暗示代碼里有單點瓶頸比如某個熱點數(shù)據(jù)導(dǎo)致鎖競爭激烈。內(nèi)存主要關(guān)注堆內(nèi)存使用情況、GC頻率和耗時、是否有內(nèi)存泄漏導(dǎo)致的應(yīng)用重啟。JVM類應(yīng)用壓測時建議同時拉取堆轉(zhuǎn)儲和GC日志長時間穩(wěn)定性測試里出現(xiàn)內(nèi)存持續(xù)漲、GC時間越來越長基本可以判斷有對象沒有回收干凈。磁盤和網(wǎng)絡(luò)磁盤關(guān)注IO等待時間和隊列長度網(wǎng)絡(luò)關(guān)注帶寬利用率和連接數(shù)。這兩個指標常常被忽略但很多TPS上不去的場景最后查下來要么是磁盤IO排隊太長要么是網(wǎng)絡(luò)出口帶寬被打滿前端的優(yōu)化做得再好也無濟于事。下表是我在壓測時常用的指標關(guān)注清單基本是每個項目都會打開監(jiān)控面板逐項確認的。監(jiān)控對象關(guān)鍵指標常見閾值參考含義應(yīng)用服務(wù)器CPU使用率、load averageCPU使用率70%~80%超過閾值說明接近計算瓶頸應(yīng)用服務(wù)器內(nèi)存JVM堆內(nèi)存、GC時間GC暫停50ms堆占用無持續(xù)上漲判斷是否有內(nèi)存泄漏線程池活躍線程數(shù)、隊列長度活躍線程池大小80%線程耗盡會導(dǎo)致請求排隊數(shù)據(jù)庫連接數(shù)、慢查詢數(shù)、IOPS慢查詢總查詢5%數(shù)據(jù)庫往往是瓶頸重災(zāi)區(qū)網(wǎng)絡(luò)帶寬利用率、TCP重傳率帶寬70%重傳率0.1%帶寬或網(wǎng)絡(luò)抖動影響穩(wěn)定性中間件消息積壓數(shù)、消費延遲積壓數(shù)穩(wěn)定不增長消費能力是否跟得上生產(chǎn)3. 策略的底層邏輯不同階段壓不同場景目標和方法完全不同“策略”這個詞聽起來很空但它直接決定了你要寫什么樣的腳本、跑多長時間、關(guān)注哪些指標。我習慣把壓測策略分成五個基礎(chǔ)類型實際執(zhí)行時往往是組合使用的。3.1 基準測試先把單接口的“底數(shù)”摸出來基準測試Benchmark Testing是所有后續(xù)工作的起點。它用極小的并發(fā)比如1個線程或少數(shù)幾個線程對單個接口進行多次請求拿到該接口在無壓力競爭下的平均響應(yīng)時間、TPS和錯誤率。這個“底數(shù)”就像馬拉松運動員的個人最好成績后面做多少并發(fā)都是在跟這個基線對比看壓力上升后性能衰減了多少。基準測試也是有學問的不能隨便跑一遍就完事。第一要把網(wǎng)絡(luò)上的干擾抹掉客戶端和服務(wù)端最好在同機房或同網(wǎng)絡(luò)環(huán)境下避免公網(wǎng)抖動影響數(shù)據(jù)。第二要多次取中位數(shù)比如跑5輪每輪跑1000次請求去掉異常波動后再取結(jié)果。第三要記錄環(huán)境信息包括被測接口部署在什么規(guī)格的機器上、數(shù)據(jù)庫版本、JVM參數(shù)等否則這個“底數(shù)”換一個環(huán)境就完全不可比了。3.2 負載測試與壓力測試一個找“日常穩(wěn)不穩(wěn)”一個找“極限在哪里”負載測試Load Testing是在預(yù)估的業(yè)務(wù)負載附近進行測試驗證系統(tǒng)在日常流量、峰值流量下是否能達到預(yù)期性能指標。負載測試的負載曲線通常比較平滑比如從50并發(fā)逐步上升到200并發(fā)每梯度維持5分鐘再上升觀察不同負載梯度下的TPS和響應(yīng)時間變化。壓力測試Stress Testing則是持續(xù)增加負載直到系統(tǒng)出現(xiàn)性能惡化、報錯或資源耗盡找出系統(tǒng)能承受的最大壓力點。兩者最核心的區(qū)別負載測試關(guān)注“達到目標是否穩(wěn)定”壓力測試關(guān)注“超過多少就撐不住”。在實際操作中我非常推薦先跑壓力測試再跑負載測試。原因是壓力測試能告訴你系統(tǒng)到底有幾斤幾兩你才知道設(shè)定的“負載目標”合不合理。如果系統(tǒng)在300并發(fā)時TPS就到頂了你把負載目標定成500并發(fā)本身就是違背客觀規(guī)律的。先探測到極限再在極限的70%-80%附近設(shè)定日常負載目標這種“用事實定目標”的方式比拍腦袋定目標科學得多。3.3 穩(wěn)定性測試長時間浸泡發(fā)現(xiàn)“慢病”很多系統(tǒng)短時間壓測毫無問題一旦持續(xù)運行數(shù)小時就出現(xiàn)性能衰退響應(yīng)時間緩慢上升內(nèi)存持續(xù)增長連接數(shù)越積越多。這種問題靠幾分鐘的負載測試根本發(fā)現(xiàn)不了所以穩(wěn)定性測試Soak Testing也叫耐久測試必不可少。穩(wěn)定性測試的做法是用接近生產(chǎn)峰值的負載通常取峰值TPS的70%-80%持續(xù)運行8小時、24小時甚至72小時過程中持續(xù)監(jiān)控指標曲線。重點關(guān)注兩類信號一是指標是否有“爬坡”趨勢比如平均響應(yīng)時間每隔兩小時漲一點那很可能是內(nèi)存泄漏或緩存失效策略有問題二是有沒有周期性波動比如每小時整點GC一次導(dǎo)致TPS驟降那要看定時任務(wù)是否跟業(yè)務(wù)高峰重疊。我在做穩(wěn)定性測試時有一個慣例每半小時記錄一次當前JVM堆內(nèi)存、Full GC次數(shù)和響應(yīng)時間P99并畫成時間序列曲線。只要這三個指標中有任何一個呈現(xiàn)單調(diào)遞增趨勢就立即停止測試、抓取堆轉(zhuǎn)儲和線程快照。因為這類問題拖得越久越難定位在線程和內(nèi)存都快耗盡時抓到的現(xiàn)場反而最有價值。3.4 容量測試為擴容找到可復(fù)用的數(shù)學模型容量測試Capacity Testing和壓力測試容易混淆但目的完全不同。壓力測試是為了找到系統(tǒng)“現(xiàn)在能扛多少”容量測試是為了回答“未來扛不住的時候加多少資源才夠”。容量測試最常見的做法是在固定資源下測出一組“并發(fā)數(shù)-TPS-資源利用率”的對應(yīng)數(shù)據(jù)比如4臺應(yīng)用服務(wù)器在200并發(fā)時TPS為1000CPU為80%。然后橫向增加服務(wù)器數(shù)量再測同樣的并發(fā)和TPS數(shù)據(jù)。通過多組數(shù)據(jù)的對比你能得到“每增加一臺服務(wù)器大約帶來多少TPS增量”的邊際效應(yīng)。這個數(shù)字配合業(yè)務(wù)增長預(yù)估才能得出有依據(jù)的擴容規(guī)劃。這里要特別提醒容量測試的結(jié)論只對“測試當時的環(huán)境模型”有效。如果你的壓測模型用的是緩存命中率90%的黃金數(shù)據(jù)那擴容評估結(jié)果會整體偏樂觀生產(chǎn)環(huán)境一旦緩存命中率下降結(jié)論立刻失效。所以容量測試對數(shù)據(jù)分布的要求極高后面會有專門篇幅講數(shù)據(jù)造數(shù)。3.5 場景組裝不要只壓單接口要壓“業(yè)務(wù)模型”前面幾種策略講的都是“怎么壓”但還有一個常被忽略的問題“壓什么”。很多團隊性能測試只挑一兩個核心接口壓這在鏈路簡單的系統(tǒng)里勉強可行但在業(yè)務(wù)復(fù)雜、服務(wù)依賴多的系統(tǒng)里遠遠不夠。正確的做法是構(gòu)造一個業(yè)務(wù)模型也就是一組模仿真實用戶行為的請求組合。比如電商場景里瀏覽商品、加入購物車、提交訂單、支付這四個動作的調(diào)用比例和并發(fā)權(quán)重是不一樣的。實際壓測時要用不同權(quán)重、不同并發(fā)、不同思考時間把這些接口混合在一起來壓才能模擬出真實流量對系統(tǒng)造成的壓力分布。業(yè)務(wù)模型的準確性直接決定壓測結(jié)果的可信度。如果沒有線上監(jiān)控數(shù)據(jù)可以從業(yè)務(wù)日志中統(tǒng)計各接口的調(diào)用量占比然后按比例折算進腳本。有了線上數(shù)據(jù)之后再用流量錄制回放工具校準模型。這是我做性能測試項目時最看重的環(huán)節(jié)腳本寫得再花哨模型不準一切都是白壓。4. Jmeter實操從零搭出一個“能回答問題”的壓測任務(wù)工具層面Jmeter是目前團隊使用門檻最低、生態(tài)最成熟的選擇。下面我按自己的實操路徑講一遍怎么從零搭出一個能真正回答業(yè)務(wù)問題的Jmeter壓測任務(wù)。注意我這里不是簡單列菜單而是把每一步背后的用意講清楚。4.1 腳本結(jié)構(gòu)線程組、取樣器與監(jiān)聽器的分工Jmeter腳本最基礎(chǔ)的三個元素是線程組Thread Group、取樣器Sampler、監(jiān)聽器Listener。線程組定義“壓力怎么施加”多少個線程虛擬用戶、多快啟動Ramp-Up時間、執(zhí)行多久循環(huán)次數(shù)或持續(xù)時間。取樣器定義“壓力打在哪”HTTP請求的協(xié)議、域名、路徑、參數(shù)、請求頭等。監(jiān)聽器定義“結(jié)果怎么收集”聚合報告、查看結(jié)果樹、后端監(jiān)聽器等。搭建腳本有一個我堅持的原則先用1個線程把請求調(diào)通再并發(fā)施壓。具體流程是創(chuàng)建線程組線程數(shù)設(shè)為1循環(huán)次數(shù)設(shè)為1創(chuàng)建一個HTTP請求填好協(xié)議、服務(wù)器、路徑、參數(shù)添加一個“查看結(jié)果樹”監(jiān)聽器跑一次確認響應(yīng)正常。這樣做的好處是先把“腳本正確性”和“業(yè)務(wù)可達性”問題排掉避免后面大并發(fā)跑起來后發(fā)現(xiàn)是腳本參數(shù)寫錯了白白浪費時間和資源。調(diào)通之后把監(jiān)聽器里的“查看結(jié)果樹”禁用掉加上“聚合報告”因為查看結(jié)果樹會保存每個請求的完整響應(yīng)數(shù)據(jù)并發(fā)一高就會把Jmeter自身內(nèi)存吃得非?？煊绊懯憾诵阅?。“聚合報告”只保存統(tǒng)計結(jié)果內(nèi)存開銷小得多。4.2 并發(fā)模型線程數(shù)、Ramp-Up時間與持續(xù)時長的設(shè)定邏輯線程組里最關(guān)鍵的設(shè)置是三個參數(shù)Number of Threads線程數(shù)、Ramp-Up Period啟動時間、Loop Count循環(huán)次數(shù)或者持續(xù)時間。線程數(shù)就對應(yīng)你前面估算的并發(fā)用戶數(shù)。比如業(yè)務(wù)模型算出峰值并發(fā)是200那線程數(shù)就設(shè)200。Ramp-Up Period是這200個線程在多長時間內(nèi)全部啟動完畢設(shè)定它主要是為了模擬真實用戶逐漸進場的過程避免一上來就200并發(fā)瞬間把服務(wù)打懵。Ramp-Up的合理取值一般是“線程數(shù)/每秒增長數(shù)”。如果你預(yù)期每秒增長20個并發(fā)200個線程的Ramp-Up就是10秒。實際操作中我更推薦勾選“調(diào)度器”Scheduler用“持續(xù)時間”而不是“循環(huán)次數(shù)”來控制測試長度。原因在于循環(huán)次數(shù)模式下每個線程執(zhí)行完指定次數(shù)的循環(huán)就結(jié)束了在高并發(fā)長時間測試中部分線程可能已經(jīng)開始結(jié)束導(dǎo)致實際并發(fā)逐步下降數(shù)據(jù)失真而持續(xù)時間模式下線程組會持續(xù)施壓到時間到為止并發(fā)模型更穩(wěn)定。關(guān)于并發(fā)數(shù)值行業(yè)內(nèi)有一個通用檢查邏輯壓測時觀察你設(shè)定的并發(fā)數(shù)是否真的在Jmeter端達到了。在線程組里把“平均活躍線程數(shù)”加進去如果設(shè)置了200并發(fā)但實際活躍只有150那說明有大量線程在等待同一個上游響應(yīng)此時TPS會偏低但瓶頸不一定在被測系統(tǒng)有可能是Jmeter施壓能力不夠也有可能是網(wǎng)絡(luò)連接數(shù)限制。這個細節(jié)很多人壓完都不看我得先提醒一下。4.3 斷言與結(jié)果采集不要只看“返回碼200”“響應(yīng)斷言”Response Assertion是用來判斷請求是否成功的但新手最容易踩的坑是只斷言HTTP狀態(tài)碼是否為200完全不看業(yè)務(wù)返回碼。真實業(yè)務(wù)里接口返回200但業(yè)務(wù)失敗的案例太常見了。比如用戶下單驗證庫存時庫存不足系統(tǒng)返回HTTP 200和一個業(yè)務(wù)碼“5001”如果你只看狀態(tài)碼這個請求會被記為“成功”壓測結(jié)果會嚴重失真。我在所有壓測腳本里都會加斷言響應(yīng)文本必須包含業(yè)務(wù)成功標志比如“status:0”或者“success:true”。這一步?jīng)Q定了錯誤率指標的可靠性。結(jié)果采集方面聚合報告足夠看基本數(shù)據(jù)但它只有最終統(tǒng)計缺少時間維度。想要看到“哪段時間TPS掉了”“哪個并發(fā)點開始響應(yīng)時間暴漲”應(yīng)該使用“后端監(jiān)聽器”Backend Listener把數(shù)據(jù)上報到InfluxDB再用Grafana展示趨勢圖。這樣得到的是一條曲線而不是孤零零的平均值定位問題時價值完全不同。4.4 讓Jmeter跑得更穩(wěn)GUI只用來調(diào)試壓測必須命令行這是操作層面的硬規(guī)矩GUI模式下Jmeter本身會占用大量內(nèi)存繪制曲線圖并發(fā)一高GUI進程反而會先卡死或OOM導(dǎo)致施壓中斷。真實的線上壓測必須用命令行非GUI模式執(zhí)行。命令行執(zhí)行的標準姿勢是jmeter -n -t /path/to/test.jmx -l /path/to/result.jtl -e -o /path/to/html-report -j /path/to/jmeter.log參數(shù)含義-n表示非GUI運行-t指定測試腳本-l指定結(jié)果文件-e和-o是生成HTML報告及輸出目錄。執(zhí)行完成后你會得到一個HTML報告目錄里面包含TPS曲線、響應(yīng)時間分布、錯誤率等圖表。這個報告可以直接打包發(fā)給團隊和上級比截一張GUI聚合報告的圖專業(yè)得多。還有一個容易忽略的問題施壓機自身的文件句柄限制。壓測時Jmeter要建立大量TCP連接Linux默認文件描述符數(shù)量常常不夠啟動壓測之前先用ulimit -n看當前限制建議調(diào)到65535以上。否則壓到一半報“Too many open files”你還會以為是系統(tǒng)出了問題其實是施壓端先倒了。5. 壓測前必須想清楚的三個問題也常被面試官翻牌子性能測試相關(guān)的面試題很多都集中在“邊界條件”和“方法論”上而不是工具操作。因為工具操作半天就能上手方法論卻需要項目和思考的沉淀。下面這三個問題既是做壓測需要提前定清楚的邊界也是面試里的高頻問點。5.1 壓測結(jié)果“達標”的判斷標準是什么很多人被問到“性能測試通過的標準是什么”時只能答出“響應(yīng)時間低于XXms錯誤率低于XX%”。這個答案本身沒錯但不夠完整。一個可執(zhí)行的驗收標準至少要包含四個維度核心業(yè)務(wù)的響應(yīng)時間百分位值比如TP99、系統(tǒng)吞吐量TPS、錯誤率閾值、資源水位上限比如CPU不持續(xù)高于80%。更關(guān)鍵的是這些閾值必須來自業(yè)務(wù)預(yù)期而不是拍腦袋。這里給大家一個可落地的推導(dǎo)方式先看歷史監(jiān)控數(shù)據(jù)中業(yè)務(wù)的真實峰值TPS把壓測的目標TPS定在峰值的1.5到2倍再倒推平均響應(yīng)時間需要多少。比如業(yè)務(wù)峰值是500 TPS目標壓測TPS就是750-1000如果業(yè)務(wù)要求頁面在2秒內(nèi)加載完那接口的TP99至少要控制在1.5秒以內(nèi)留下前端渲染和網(wǎng)絡(luò)傳輸?shù)挠嗔?。這樣定出來的標準上會、匯報時都有據(jù)可依。還有個細節(jié)容易被忽略壓測結(jié)果分為“環(huán)境驗證”和“生產(chǎn)驗證”。測試環(huán)境的結(jié)果只能說明“當前測試環(huán)境下系統(tǒng)的表現(xiàn)“要真正評估生產(chǎn)容量要么在生產(chǎn)環(huán)境做灰度壓測低峰期小流量要么做全鏈路壓測。很多故障是在生產(chǎn)環(huán)境壓測時才暴露的比如網(wǎng)絡(luò)帶寬限制、證書校驗、網(wǎng)關(guān)超時配置等測試環(huán)境壓不出來的問題。任何環(huán)境置換之后原來的數(shù)據(jù)結(jié)論都需要打問號。5.2 測試數(shù)據(jù)和環(huán)境隔離怎么做數(shù)據(jù)是真的會騙人的。性能測試中如果數(shù)據(jù)量不夠數(shù)據(jù)庫索引可能全走內(nèi)存并發(fā)查詢毫秒級返回數(shù)據(jù)量接近生產(chǎn)時索引要讀磁盤慢查詢就暴露了。所以壓測數(shù)據(jù)要達到生產(chǎn)規(guī)模的量級而且數(shù)據(jù)分布要與生產(chǎn)一致。簡單說生產(chǎn)表里商品有各種類目、價格、狀態(tài)測試數(shù)據(jù)也要有類似的分布比例不能讓熱門商品的緩存命中率高達99%否則容量估算會嚴重樂觀。做數(shù)據(jù)準備時建議用生產(chǎn)脫敏數(shù)據(jù)導(dǎo)出一部分再通過存儲過程或腳本翻倍擴充。比如生產(chǎn)庫有100萬條訂單測試庫至少要準備同樣量級的數(shù)據(jù)。同時要注意數(shù)據(jù)的“體感分布”有些新用戶、有些老用戶、有些商品熱銷、有些商品冷門這樣壓出來的索引選擇、緩存命中率才接近真實場景。環(huán)境隔離方面壓測一定要用獨立的數(shù)據(jù)庫或獨立的Schema避免壓測流量污染生產(chǎn)數(shù)據(jù)。尤其是寫操作比較多的壓測必須確認測試環(huán)境的消息隊列、緩存、對象存儲等中間件是獨立的并且下游服務(wù)允許接收壓測產(chǎn)生的垃圾數(shù)據(jù)。我之前遇到過壓測環(huán)境連了共享的Redis壓測結(jié)束忘了清理結(jié)果把緩存里的正式數(shù)據(jù)擠掉了導(dǎo)致線上短暫的緩存穿透這個教訓成本相當高。5.3 性能瓶頸定位的通用排查思路壓測發(fā)現(xiàn)TPS不達標時常見的新手反應(yīng)是立刻去調(diào)Jmeter的并發(fā)數(shù)或者懷疑工具沒配好。但正確思路應(yīng)該是先定位瓶頸發(fā)生在哪一層。我個人常用的排查鏈路是這樣一個順序施壓端的問題先排除再看鏈路中間件最后看數(shù)據(jù)庫和外部依賴。施壓端排查在聚合報告里看“發(fā)送字節(jié)數(shù)”和“接收字節(jié)數(shù)”如果TPS上不去的同時施壓機CPU/內(nèi)存已經(jīng)打滿那就要加施壓機或改分布式壓測而不是被測系統(tǒng)的鍋。中間件排查看網(wǎng)關(guān)、負載均衡、緩存、消息隊列的連接數(shù)和延時。比如Nginx的upstream_response_time變長還是連接被拒Redis的命中率下降還是阻塞命令變多這些都會成為性能瓶頸而且它們往往被應(yīng)用層指標掩蓋。應(yīng)用層排查抓線程狀況、GC日志、壓力高的接口調(diào)用鏈追蹤。一個很經(jīng)典的場景是TPS上不去但CPU很高先看是用戶態(tài)還是內(nèi)核態(tài)高用戶態(tài)高多半是業(yè)務(wù)代碼計算量大可以結(jié)合火焰圖定位熱點方法內(nèi)核態(tài)高多半是系統(tǒng)調(diào)用頻繁、鎖競爭或者上下文切換過猛比如打印日志太頻繁、正則匹配、序列化都可能導(dǎo)致CPU徒增。數(shù)據(jù)庫排查確認連接池是否打滿、慢查詢數(shù)量和最長耗時、磁盤IO是否為瓶頸。數(shù)據(jù)庫的排查順序是連接數(shù) - 慢查詢 - 鎖等待 - IO。這套鏈路看起來步驟多但實際執(zhí)行時根本不用每一步都排查。我的經(jīng)驗是壓測過程中同時開好四個維度的監(jiān)控面板一旦TPS曲線開始拐頭先看CPU和數(shù)據(jù)庫慢查詢兩個面板80%以上的瓶頸都會在這兩個地方現(xiàn)形。6. 實戰(zhàn)中反復(fù)踩過的坑與我現(xiàn)在養(yǎng)成的習慣文章最后這一部分是我真正想分享的“教訓集”。這些東西寫不到官方文檔里但每一條都是真金白銀換來的。6.1 最容易翻車的五個細節(jié)第一壓測數(shù)據(jù)不可持續(xù)。用固定數(shù)據(jù)重復(fù)壓測數(shù)據(jù)庫的緩存會越跑越熱TPS呈現(xiàn)“越壓越快”的假象。我現(xiàn)在做壓測時會在腳本里增加一個“批量造數(shù)”的定時器或者在測試過程中間歇性更新熱點數(shù)據(jù)保證緩存命中率不因反復(fù)壓測而異常升高。第二忽略長連接與短連接差異。生產(chǎn)環(huán)境客戶端一般復(fù)用連接池測試腳本如果每個請求都新建連接服務(wù)器要承擔大量TCP三次握手和四次揮手開銷TPS會被低估。Jmeter里要正確使用HTTP默認請求的“Keep-Alive”選項并且控制好并發(fā)線程與連接數(shù)的對應(yīng)關(guān)系。如果被測系統(tǒng)連接數(shù)有限制壓測時你要觀察連接是否被復(fù)用否則容易把連接數(shù)資源誤判成瓶頸。第三只看平均響應(yīng)時間。平均值是最容易欺騙人的指標一個請求10秒、一個請求0.1秒平均下來才5秒看著還行可是那次10秒的請求用戶已經(jīng)流失了。壓測報告里至少要給TP90、TP95、TP99三檔百分位數(shù)據(jù)并針對標準偏差異常的場景做進一步分析。第四壓測機沒有做分布式或多機聯(lián)合施壓。單臺Jmeter的施壓上限有限線程開太多時施壓機自身的線程調(diào)度和內(nèi)存占用會干擾數(shù)據(jù)。通常單臺Jmeter維持在500-1000并發(fā)以內(nèi)比較穩(wěn)妥超過這個量就采用分布式部署在控制機上把腳本分發(fā)到多臺施壓機并關(guān)閉每臺的GUI模式。第五沒有做數(shù)據(jù)清理和二次驗證。性能測試結(jié)束后如果只跑一次就下了結(jié)論這是最不可信的。正確做法是正式壓測前先跑一遍預(yù)熱讓線程池、緩存、數(shù)據(jù)庫連接池全部進入“穩(wěn)態(tài)”停頓幾分鐘確認基線正常后再跑正式場景跑完一輪之后清理數(shù)據(jù)并重啟相關(guān)服務(wù)或恢復(fù)狀態(tài)再復(fù)跑一遍看兩輪數(shù)據(jù)是否能在合理誤差范圍內(nèi)吻合。只有能復(fù)現(xiàn)的數(shù)據(jù)才值得寫進報告。6.2 去向領(lǐng)導(dǎo)和業(yè)務(wù)方匯報時怎么讓數(shù)字有說服力性能測試報告如果只寫“壓測1000并發(fā)平均響應(yīng)時間150ms”決策者很難直觀判斷問題嚴重程度。我習慣在報告的摘要頁直接擺三個東西一是壓測模型和邊界條件并發(fā)數(shù)、數(shù)據(jù)量、持續(xù)時長、環(huán)境規(guī)格二是與線上真實流量基線的對比比如線上峰值TPS的倍數(shù)關(guān)系三是資源水位與瓶頸點列表。報告里還要明確列出“限制條件”比如“本次壓測未包含某第三方支付網(wǎng)關(guān)的外部依賴”避免未測的環(huán)節(jié)成為上線時甩鍋的理由。這個習慣在多次項目中幫了我和團隊很大的忙因為性能測試本身是開放系統(tǒng)下的有限驗證沒有任何測試能覆蓋線上所有真實行為。說清楚“測到了什么、沒測什么、為什么”比一個自信滿滿但邊界模糊的“通過”結(jié)論要重要得多。6.3 我現(xiàn)在做性能測試項目的固定動作清單雖然每個項目的業(yè)務(wù)不同但我現(xiàn)在的執(zhí)行路徑基本穩(wěn)定了最后分享給大家作為參考第一步收集線上監(jiān)控數(shù)據(jù)拉出各接口調(diào)用量占比、平均耗時、TP99、峰值TPS建模。第二步根據(jù)模型確定策略組合通常先做基準測試和壓力測試找到極限再做負載測試和穩(wěn)定性測試驗證目標。第三步統(tǒng)一壓測環(huán)境數(shù)據(jù)庫恢復(fù)備份數(shù)據(jù)中間件隔離施壓機檢查資源限制和網(wǎng)絡(luò)帶寬。第四步編寫Jmeter腳本先用單線程調(diào)通業(yè)務(wù)鏈路加上業(yè)務(wù)成功斷言配置后端監(jiān)聽器。第五步預(yù)壓一次看實際并發(fā)是否達到預(yù)期施壓端資源是否充裕數(shù)據(jù)曲線是否符合業(yè)務(wù)模型。第六步正式壓測過程中同步監(jiān)控應(yīng)用、數(shù)據(jù)庫、緩存、網(wǎng)絡(luò)的資源指標標記關(guān)鍵拐點。第七步整理報告包含邊界條件、指標曲線、瓶頸定位、優(yōu)化建議和可復(fù)現(xiàn)腳本。第八步壓測結(jié)束后的清理刪除測試數(shù)據(jù)、關(guān)閉壓測任務(wù)、釋放中間件資源避免影響測試環(huán)境后續(xù)使用。這個流程看起來有不少步驟但每一步的背后都對應(yīng)著真實踩過的坑。做性能測試最大的誤區(qū)是對著工具猛調(diào)參而真正的功夫全在“建模、定邊界、看曲線、定位瓶頸”這些看起來不暴力、卻最費腦子的環(huán)節(jié)上。把這些基礎(chǔ)打扎實工具層面的東西自然就成了順手的事。