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