在這個月面試了 10 個候選人之后我只能說“會做性能測試”和“懂性能測試”之間隔著一條很深的認知鴻溝。絕大多數(shù)簡歷上寫著“熟練掌握 JMeter有性能測試實戰(zhàn)經(jīng)驗”的候選人都能熟練地告訴我線程數(shù)設(shè)多少、Ramp-Up 怎么配、聚合報告怎么看。但當(dāng)我把這個問題拋出去——TPS、并發(fā)數(shù)、響應(yīng)時間這三者的底層關(guān)系是什么——場面往往會陷入尷尬的沉默。有人照著面試題背答案“TPS 并發(fā)數(shù) / 響應(yīng)時間”。這個公式對嗎對但不全對。它只在極理想的模型下成立。一旦系統(tǒng)出現(xiàn)排隊、資源爭搶、線程阻塞這個公式會把你的測試引向一個深坑。還有一個有意思的現(xiàn)象是最近搜“jmeter 性能測試步驟”的人特別多但很多人在第一步就錯了他們根本不確認系統(tǒng)真實的并發(fā)用戶數(shù)是多少直接設(shè)置線程數(shù) 500、1000 就開始壓。壓出來的 TPS 很漂亮卻是“虛高”的。這篇文章不打算繼續(xù)講 JMeter 的按鈕在哪那些基礎(chǔ)操作屬于入門教程。我真正想做的是把 TPS、并發(fā)數(shù)、響應(yīng)時間三者在底層的關(guān)系徹底講透包括它們怎么互相影響、為什么會出現(xiàn) TPS 虛高、真實業(yè)務(wù)場景中這個關(guān)系會發(fā)生什么變形以及面試中怎么回答才不會被面試官追問到原地“爆炸”。讀完這篇文章你至少能得到三樣?xùn)|西一套能說服面試官的、關(guān)于三者關(guān)系的底層邏輯框架。一個判斷系統(tǒng)真實并發(fā)承載能力的“靠譜”方法。若干直接能用于工作場景的性能測試設(shè)計思路。1. 這篇文章真正要解決的問題先說一個扎心的事實大部分性能測試報告寫出來只是為了應(yīng)付上線檢查而不是為了發(fā)現(xiàn)系統(tǒng)瓶頸。如果你只是想把壓測報告做得“好看”那不需要理解三者的底層關(guān)系——把線程數(shù)拉高把聚合報告里的 TPS 看成一個數(shù)字截圖貼上去完事。但如果你要解決的是以下任何一個問題你就必須從根本上搞明白這三者的關(guān)系線上出現(xiàn)卡頓或超時但你在測試環(huán)境壓不出來。測試環(huán)境怎么壓都穩(wěn)如老狗一到線上就出問題。老板問“我們系統(tǒng)能扛多少并發(fā)”你給不出一個可信的數(shù)字。不是不愿意給是你根本不知道從哪個維度推導(dǎo)。你壓測出來的 TPS 很高但上線后一遇活動流量就掛。你想做容量評估、限流配置、容量規(guī)劃但不知道用哪個指標做依據(jù)。很多人以為性能測試的核心是“會用壓測工具”其實性能測試的核心是建立指標之間的換算關(guān)系。你需要的不是一個孤立的 TPS 數(shù)字而是“在什么并發(fā)數(shù)下、響應(yīng)時間達到多少、TPS 還能不能撐住”的關(guān)聯(lián)模型。這篇文章就是圍繞這個關(guān)聯(lián)模型展開的先從底層定義開始把三個概念從“你腦子里的模糊印象”撥正為“可計算、可推導(dǎo)的工程指標”再拆解三者之間在不同系統(tǒng)狀態(tài)下會經(jīng)歷怎樣的關(guān)系變化接著用真實的場景案例講清楚為什么并發(fā)數(shù)翻倍后 TPS 反而下降最后回到 JMeter 操作層面告訴你一套能落地的壓測設(shè)計方法。不管你是準備性能測試面試還是正在寫壓測方案這篇文章的目標都是讓你從“會用工具”提升到“能講清楚系統(tǒng)表現(xiàn)”。2. 先把三個概念徹底說清楚從生活場景到技術(shù)定義在推導(dǎo)關(guān)系之前必須先確保我們聊的是同一個“并發(fā)數(shù)”。很多人在這一步已經(jīng)跑偏了。面試時我經(jīng)常追問“你的并發(fā)數(shù)是怎么定的”答案五花八門有說線程數(shù)的有說注冊用戶數(shù)的有說同時在線數(shù)的。這些說法都混淆了不同層面的并發(fā)概念。2.1 并發(fā)數(shù)是“同時發(fā)出的請求數(shù)”不是“在線人數(shù)”為了把這個問題說透先講一個生活場景。想象一家銀行網(wǎng)點有 3 個柜臺窗口相當(dāng)于系統(tǒng)有 3 個處理線程大廳里坐著 50 個等待辦理業(yè)務(wù)的客戶。這時候真正的“并發(fā)數(shù)”是多少不是 50。50 個客戶坐在大廳里只能叫“在線人數(shù)”或者“待處理任務(wù)數(shù)”。真正的并發(fā)數(shù)是同一時刻正在窗口辦理業(yè)務(wù)的客戶數(shù)量——也就是最多 3 個。其他 47 個人要么在排隊要么在填單子他們沒有占用柜臺資源。從技術(shù)上理解并發(fā)數(shù)是同一時刻系統(tǒng)正在處理的請求數(shù)量也就是“在途請求數(shù)”。這個“在途”包括請求已經(jīng)在操作系統(tǒng)網(wǎng)絡(luò)隊列里等待、已經(jīng)被應(yīng)用接收、正在執(zhí)行 SQL、正在等待下游依賴返回等所有狀態(tài)。這個區(qū)別非常關(guān)鍵。你做壓測的時候把 JMeter 線程數(shù)設(shè)為 500這 500 個只是“正在嘗試發(fā)起請求的客戶端”它們大多處在等待響應(yīng)階段并不等同于系統(tǒng)“同一時刻正在處理”的請求數(shù)更不是業(yè)務(wù)層面真正的“在線用戶數(shù)”。我用一個稍微嚴謹一點的說法幫助記憶并發(fā)用戶數(shù)在線用戶數(shù)業(yè)務(wù)概念應(yīng)用層有多少用戶同時活躍。并發(fā)請求數(shù)在途請求數(shù)技術(shù)概念系統(tǒng)同時處理的請求量。壓測線程數(shù)施壓數(shù)工具概念你開了多少并發(fā)連接去發(fā)起請求。三者有關(guān)聯(lián)但絕不是一回事。2.2 響應(yīng)時間一個被你錯誤統(tǒng)計的指標響應(yīng)時間Response Time, RT字面理解是“從發(fā)起請求到收到完整響應(yīng)的時間”。但在性能測試中你需要把這條時間鏈路拆開看。一次完整的請求耗時通常包括網(wǎng)絡(luò)傳輸時間客戶端到服務(wù)器的往返時延RTT。排隊時間請求到達服務(wù)器后在連接池、線程池、隊列里等待被處理的時間。處理時間應(yīng)用執(zhí)行業(yè)務(wù)邏輯、讀寫數(shù)據(jù)庫、調(diào)用下游接口的時間。響應(yīng)傳輸時間結(jié)果返回客戶端的時間。這里有一個最常見的坑JMeter 中顯示的響應(yīng)時間默認只包含“從發(fā)出請求到收到響應(yīng)”的時間它包含了網(wǎng)絡(luò)、排隊和處理時間但不包含你在前置處理器、后置處理器中所做操作的時間。更關(guān)鍵的是響應(yīng)時間是一個分布不是一個固定的數(shù)。同一系統(tǒng)在同樣的壓力下1 個請求可能 50ms 返回另 1 個請求可能 800ms 返回。所以你應(yīng)該關(guān)注的是響應(yīng)時間分布平均值A(chǔ)vg容易被極端值拉偏參考意義有限。TP90 / TP95 / TP9990%95%、99%的請求耗時在多少毫秒以內(nèi)。這個比平均值更接近真實體驗。最大值Max常被 GC垃圾回收、網(wǎng)絡(luò)抖動之類因素拉得極高看個趨勢就好別拿來做結(jié)論。在后面的關(guān)系模型里我提到的響應(yīng)時間都默認指“穩(wěn)定狀態(tài)下的平均響應(yīng)時間”。在做性能評估、容量規(guī)劃時建議你把 TP99 作為核心指標。2.3 TPS事務(wù)吞吐量系統(tǒng)的“實際產(chǎn)能”TPSTransactions Per Second是每秒完成的事務(wù)數(shù)。它衡量的不是系統(tǒng)能“接收”多少請求而是系統(tǒng)能“完成”多少業(yè)務(wù)操作。這里有個區(qū)別需要明確TPS 和 QPSQueries Per Second經(jīng)常被混用。嚴格來說QPS偏重“查詢”類請求每秒查詢量。TPS偏重“事務(wù)”類請求它更強調(diào)一個完整業(yè)務(wù)操作通?？赡馨鄠€請求。舉個例子你打開一次訂單列表頁面會同時調(diào) 3 個接口。從 JMeter 的角度如果你給每個接口各創(chuàng)建一個 Sampler一次打開頁面就是 3 個請求如果你把整個操作封裝成一個“邏輯事務(wù)”那一次頁面打開就是 1 個事務(wù)。在做性能壓測時比較規(guī)范的做法是用“事務(wù)”作為計量單位而不是用“請求數(shù)”。因為業(yè)務(wù)方最關(guān)心的往往是“每秒能完成多少訂單”而不是“每秒能處理多少 HTTP 請求”。如果壓測報告上只寫“TPS 500”卻沒有說明這個 TPS 是接口級別的還是業(yè)務(wù)事務(wù)級別的這份報告的參考價值要打一個很大的折扣。2.4 一個簡單的三句話總結(jié)為了后文推導(dǎo)方便先把三個概念的準確描述統(tǒng)一起來并發(fā)數(shù)表示的是“系統(tǒng)同時處理的在途請求數(shù)量”它決定了系統(tǒng)處于什么壓力相位。響應(yīng)時間表示的是“一個請求完成一次完整往返的代價”它反映單個用戶感受到的快慢。TPS 表示的是“系統(tǒng)單位時間內(nèi)真正處理完的事務(wù)總量”它反映的是系統(tǒng)的產(chǎn)能。一句話概括并發(fā)數(shù)是施壓的強度響應(yīng)時間是單筆處理的代價TPS 是系統(tǒng)整體的產(chǎn)出能力。接下來我們就要推導(dǎo)這三者之間到底存在什么樣的數(shù)學(xué)底層關(guān)系。3. 三者關(guān)系的核心模型從 Little 定律到實戰(zhàn)公式3.1 排隊論視角下的核心公式在性能工程的底層理論中有一個幾乎繞不開的定律——Little 定律。它最初來自排隊論后來被廣泛應(yīng)用在計算機系統(tǒng)性能分析中。Little 定律的數(shù)學(xué)表達式很簡潔L λ × W翻譯成性能測試術(shù)語就是并發(fā)數(shù)L TPSλ × 平均響應(yīng)時間W什么意思呢它描述的是一個處于穩(wěn)定狀態(tài)的系統(tǒng)內(nèi)部同時在處理的任務(wù)數(shù)并發(fā)數(shù)等于單位時間新到達并被處理完成的任務(wù)數(shù)TPS乘以每個任務(wù)在系統(tǒng)內(nèi)部停留的時間響應(yīng)時間。這個公式非常重要因為它建立了三個指標之間的硬性換算關(guān)系?；谶@個公式可以導(dǎo)出兩個常用形態(tài)TPS 并發(fā)數(shù) / 平均響應(yīng)時間 平均響應(yīng)時間 并發(fā)數(shù) / TPS3.2 為什么教科書公式在實戰(zhàn)中經(jīng)?！笆А蹦銜诤芏嗝嬖囶}和培訓(xùn)資料里看到上面的推導(dǎo)公式。但如果實際壓測過系統(tǒng)你一定會發(fā)現(xiàn)一個現(xiàn)象并發(fā)數(shù)從 100 提到 300TPS 絕對不是按 3 倍線性增長。原因在于Little 定律有一個隱含假設(shè)——系統(tǒng)處于穩(wěn)定狀態(tài)沒有過載沒有隊列溢出沒有資源競爭激化。說得更直白一點Little 定律假設(shè)系統(tǒng)是一個“理想管道”。但真實系統(tǒng)不是理想管道真實系統(tǒng)有線程池上限處理線程被占滿后新增請求只能排隊。數(shù)據(jù)庫連接池上限連接不夠用應(yīng)用線程阻塞等待。CPU 多核爭搶線程切換開銷變大真正干活的時間比例變小。鎖競爭多個線程同時搶一把鎖串行化的時間變長。內(nèi)存 GC并發(fā)升高后GC 頻率上升Stop-The-World 導(dǎo)致響應(yīng)時間惡化。當(dāng)這些瓶頸開始顯現(xiàn)時關(guān)系模型就變成了這樣并發(fā)數(shù)繼續(xù)上升 → 響應(yīng)時間快速惡化 → TPS 不再上升甚至下降這個拐點就是性能測試中最重要的發(fā)現(xiàn)系統(tǒng)的最佳并發(fā)區(qū)間在哪里。為了讓你看清楚這個變化過程我用一張關(guān)系演變表來描述系統(tǒng)從空閑到被打垮的過程階段并發(fā)數(shù)變化響應(yīng)時間TPS 變化系統(tǒng)狀態(tài)空閑期低并發(fā)穩(wěn)定且小隨并發(fā)線性上升資源空閑產(chǎn)能未被充分使用健康期并發(fā)提升輕微上升總體平穩(wěn)隨并發(fā)近似線性增長資源利用率逐漸提升飽和點到達拐點開始明顯上升增長趨緩達到峰值某個資源開始打滿過載區(qū)繼續(xù)加壓急劇上升不增反降排隊嚴重資源耗盡崩壞區(qū)極端高并發(fā)大量超時大幅下跌線程池拒絕、連接池滿、雪崩風(fēng)險這五個階段至關(guān)重要。所謂“懂性能測試”核心就是能識別出你的系統(tǒng)當(dāng)前處于哪個階段以及拐點在哪里。3.3 用一個具體場景驗證公式假設(shè)有一個系統(tǒng)壓測場景如下平均響應(yīng)時間 200ms0.2 秒并發(fā)數(shù) 50按公式計算TPS 50 / 0.2 250這說明如果每個請求耗時 0.2 秒系統(tǒng)同時能處理 50 個請求那 1 秒內(nèi)能處理完 250 個請求?，F(xiàn)在把并發(fā)數(shù)提升到 100會出現(xiàn)什么情況理想情況如果系統(tǒng)資源充足、沒有競爭響應(yīng)時間仍為 0.2 秒則 TPS 100 / 0.2 500翻倍。常見情況并發(fā)提升后線程切換、鎖競爭、數(shù)據(jù)庫連接等待一起出現(xiàn)平均響應(yīng)時間可能漲到 0.35 秒那么 TPS 100 / 0.35 ≈ 286。雖然并發(fā)翻倍了TPS 只多了 14%。過載情況并發(fā)數(shù)到 200 以后響應(yīng)時間漲到 1.2 秒TPS 200 / 1.2 ≈ 167不但沒漲反而比并發(fā) 100 時更低。這就是為什么很多人在壓測時會看到“TPS 虛高”或“TPS 暴跌”的現(xiàn)象——因為測試沒有建立“由響應(yīng)時間推導(dǎo) TPS”的意識只是機械地增加線程數(shù)看著聚合報告里的數(shù)字上躥下跳卻說不出系統(tǒng)到底哪里出了問題。4. 真實系統(tǒng)里三者關(guān)系會發(fā)生哪些變形4.1 不同接口類型下的關(guān)系差異很多剛接觸性能測試的人會犯一個錯誤把所有接口都用同一套并發(fā)-響應(yīng)時間模型來理解。實際上不同接口類型下三者的關(guān)系表現(xiàn)差異巨大。先看“快接口”。典型的例子是查詢類的接口比如登錄校驗、緩存查詢、狀態(tài)檢查。這類接口響應(yīng)時間很短通常在 5ms 到 50ms 之間。在低并發(fā)階段它們能支撐非常高的 TPS因為每個請求在系統(tǒng)內(nèi)逗留時間極短。但這類接口一旦并發(fā)打高最先出現(xiàn)問題的是網(wǎng)絡(luò)層和線程池響應(yīng)時間可能從 10ms 暴漲到 500ms。再看“慢業(yè)務(wù)”。典型例子是報表導(dǎo)出、批量任務(wù)、大文件上傳、涉及大量復(fù)雜 SQL 的查詢。這類接口響應(yīng)時間可能在 1 秒甚至更長。重點在于慢接口是 TPS 的天敵。同樣是 100 個并發(fā)請求快接口能輕松做到 2000 TPS慢業(yè)務(wù)可能只能做到 50 TPS。不是因為系統(tǒng)能力差異而是因為每個請求占據(jù)處理線程的時間太長。這種差異在容量規(guī)劃時的含義完全不同。壓測一個查詢接口時你可以用“并發(fā)數(shù) 500、TPS 3000”來規(guī)劃但壓測一個導(dǎo)出報表接口時同樣的并發(fā)數(shù) 500 可能直接把系統(tǒng)打掛因為每個請求處理時間太長線程池很快就耗盡了。4.2 有狀態(tài)系統(tǒng)與無狀態(tài)系統(tǒng)的區(qū)別另外一個影響三者關(guān)系的因素是系統(tǒng)的“狀態(tài)性”。無狀態(tài)應(yīng)用比如純 Redis 查詢、靜態(tài)資源服務(wù)、計算型接口不依賴會話數(shù)據(jù)、不持有用戶狀態(tài)。它的并發(fā)模型相對簡單Little 定律的推導(dǎo)會比較貼近現(xiàn)實。資源充足時并發(fā)和 TPS 基本線性關(guān)系。有狀態(tài)應(yīng)用比如在線交易、購物車、WebSocket 長連接、分布式鎖、樂觀鎖更新等。此時系統(tǒng)不僅要處理計算還要處理“狀態(tài)同步”。并發(fā)升高時數(shù)據(jù)一致性、鎖沖突、臟讀重試帶來的額外開銷會急劇增加響應(yīng)時間會非線性上升。從壓測角度看有狀態(tài)系統(tǒng)的性能測試絕不能用無狀態(tài)系統(tǒng)的“線性模型”去預(yù)測結(jié)果。你必須通過階梯加壓的方式找到真實的飽和點。4.3 異步化對三者的關(guān)系顛覆還有一個不可忽視的變量異步化。如果系統(tǒng)大量使用消息隊列、異步回調(diào)、線程池異步處理用戶的“請求-響應(yīng)”鏈路和“業(yè)務(wù)處理鏈路”就解耦了。這種情況下會出現(xiàn)什么對用戶來說響應(yīng)時間變短了因為請求只是被接收后放進了隊列立即返回“受理成功”。對系統(tǒng)來說真正的業(yè)務(wù)處理是在后臺異步進行的TPS 的計量口徑變了。對壓測來說你看到的響應(yīng)時間是“受理時間”而不是“業(yè)務(wù)完成時間”。此時仍套用“TPS 并發(fā)數(shù) / 響應(yīng)時間”就會得出嚴重失真的結(jié)論。一個系統(tǒng)中如果有大量異步處理你必須分別觀察“入口 TPS”和“處理 TPS”以及兩者之間的隊列積壓量。隊列積壓量才是觀察系統(tǒng)壓力的關(guān)鍵指標而不是直接看響應(yīng)時間。所以在回答三者關(guān)系之前先要反問當(dāng)前系統(tǒng)是同步的還是異步的如果是異步系統(tǒng)三者的關(guān)系鏈條要重新梳理。5. 為什么你會看到“TPS 虛高”——并發(fā)數(shù)、響應(yīng)時間與統(tǒng)計口徑的三角關(guān)系“TPS 虛高”是我們搜索熱詞中出現(xiàn)頻率非常高的一個詞。這個詞概括了性能測試實踐中一類常見的錯誤認知壓測報告上的 TPS 很高但真實性存疑。5.1 虛高 TPS 是怎么產(chǎn)生的先說結(jié)論TPS 虛高的本質(zhì)是統(tǒng)計口徑和真實業(yè)務(wù)模型不匹配而不是壓測工具出了問題。常見產(chǎn)生虛高 TPS 的操作有第一種只用低響應(yīng)時間接口做壓測。如果一個系統(tǒng)只有一個查詢接口響應(yīng)時間 10ms那 500 并發(fā)就能壓出 20000 TPS。但這能代表系統(tǒng)整體能力嗎明顯不能。業(yè)務(wù)高峰期的流量是混合的包含慢接口、寫接口、長事務(wù)。壓測場景設(shè)計時如果只挑快接口打得到的 TPS 沒有任何參考價值。第二種忽略事務(wù)定義直接把 HTTP 請求數(shù)當(dāng) TPS。這在 JMeter 中特別常見。默認情況下JMeter 聚合報告里的 Throughput 是按照 Sampler 的執(zhí)行次數(shù)來統(tǒng)計的。一個頁面包含 10 個接口用戶一次完整操作會產(chǎn)生 10 個請求。如果你把這個數(shù)字直接當(dāng)成業(yè)務(wù) TPS報告上的數(shù)字會比真實業(yè)務(wù)吞吐量高出 10 倍。第三種高并發(fā)長時間壓測取峰值 TPS 當(dāng)結(jié)果。很多壓測報告習(xí)慣取“最高那一段的 TPS”作為成果。但是這個最高值通常出現(xiàn)在系統(tǒng)資源尚未穩(wěn)定、緩存未預(yù)熱、垃圾回收尚未開始的時候。你真正應(yīng)該關(guān)注的是系統(tǒng)在“持續(xù)壓力下”的穩(wěn)定 TPS而不是瞬時峰值。第四種忽略錯誤率。如果系統(tǒng)大量返回 500、超時、連接拒絕JMeter 會統(tǒng)計這些“失敗的請求”嗎默認情況下JMeter 不會將斷言失敗或者 HTTP 非 2xx 狀態(tài)碼算作成功事務(wù)但如果你沒有配置斷言或者把錯誤響應(yīng)也當(dāng)作“完成”來統(tǒng)計你的 TPS 就會把失敗請求也計算進去看起來很高實際上是假象。5.2 怎么避免 TPS 虛高從工程經(jīng)驗來看避免 TPS 虛高的核心有四點壓測場景必須包含核心鏈路而不是只挑快接口。事務(wù)定義必須和業(yè)務(wù)操作對齊。打開訂單列表 1 個事務(wù)而不是 3 個 Sampler。報告 TPS 必須關(guān)聯(lián)錯誤率和響應(yīng)時間分布。TPS 再高如果 TP99 已經(jīng)突破 2 秒也不算健康。結(jié)果必須取穩(wěn)定段平均值而不是瞬時峰值。如果你在壓測報告中寫“TPS 峰值 5000”面試官或者老板追問一句“響應(yīng)時間多少錯誤率多少并發(fā)多少什么場景壓了多久”你能清晰回答才算真正對這個數(shù)字負責(zé)。6. 通過壓測實驗反向驗證三者關(guān)系JMeter 階梯加壓實操理論講完了現(xiàn)在進入實操環(huán)節(jié)。既然你是做性能測試的JMeter 是繞不開的工具。這一節(jié)我會給你一套可以直接執(zhí)行的壓測設(shè)計思路用 JMeter 來驗證“并發(fā)數(shù)、響應(yīng)時間、TPS”三者之間的動態(tài)關(guān)系。6.1 環(huán)境準備本小節(jié)以最常用的 JMeter 為例。當(dāng)前 JMeter 的主流版本為 5.x需要 JDK 8 或以上版本建議使用 JDK 11 或 17。不同 JMeter 版本的界面細節(jié)會有差異但核心操作思路一致。如果還沒有安裝 JMeter可以去 Apache JMeter 官網(wǎng)下載解壓版解壓后進入bin目錄Windows 雙擊jmeter.batmacOS/Linux 執(zhí)行./jmeter即可。為了方便演示準備一個簡單的被測服務(wù)。你可以使用任意本地 Web 服務(wù)這里用一個最小的 Spring Boot 項目提供一個模擬業(yè)務(wù)處理接口// 文件路徑src/main/java/com/example/perfdemo/controller/DemoController.java package com.example.perfdemo.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import java.util.concurrent.TimeUnit; RestController public class DemoController { /** * 模擬耗時業(yè)務(wù)接口。 * delayMillis 參數(shù)用于模擬業(yè)務(wù)處理耗時默認 100 毫秒。 */ GetMapping(/demo) public String demo(RequestParam(value delayMillis, defaultValue 100) long delayMillis) throws InterruptedException { // 模擬業(yè)務(wù)處理耗時實際項目中這里是 SQL 查詢、下游調(diào)用、復(fù)雜計算等 TimeUnit.MILLISECONDS.sleep(delayMillis); return success; } }這個接口很簡單每個請求進來模擬處理 100ms然后返回。為什么設(shè)計這個接口因為你只有讓每個請求固定占用一定時間才能清晰觀察到并發(fā)數(shù)增加后線程池、CPU、響應(yīng)時間和 TPS 之間如何互相制約。如果不想寫代碼啟動服務(wù)也可以使用任一 Linux 環(huán)境用 Python 開啟一個臨時 HTTP 服務(wù)再通過time.sleep模擬耗時。核心目標只是“有一個可被壓測的接口”。6.2 JMeter 測試計劃設(shè)計打開 JMeter按下面的步驟建一個最小測試計劃右鍵“測試計劃”添加一個“線程組”。在線程組下添加“Sampler - HTTP 請求”。在 HTTP 請求中配置協(xié)議http服務(wù)器名稱或 IPlocalhost端口號8080方法GET路徑/demo?delayMillis100在線程組下添加“監(jiān)聽器 - 聚合報告”和“監(jiān)聽器 - 響應(yīng)時間圖”。線程組配置這里先不固定因為我們要做階梯加壓。階梯加壓的核心思路是同樣的測試腳本從低并發(fā)開始逐步增加線程數(shù)每一檔保持運行一段時間觀察各項指標的變化趨勢。比如按下面規(guī)模來階段線程數(shù)Ramp-Up 時間持續(xù)時間階段1101 秒30 秒階段2201 秒30 秒階段3502 秒30 秒階段41005 秒60 秒階段520010 秒60 秒階段640020 秒60 秒為什么要設(shè)置“持續(xù)時間”因為性能測試必須看穩(wěn)定狀態(tài)下的表現(xiàn)。啟動后立即出現(xiàn)的數(shù)字可能受線程初始化、緩存預(yù)熱影響。一般建議每個階段的持續(xù)時間不少于 30 秒最好 60 秒以上讓數(shù)據(jù)趨于穩(wěn)定后再記錄。如果你不想手動創(chuàng)建 6 個線程組也可以使用 JMeter 的插件Ultimate Thread Group需要在 JMeter Plugins Manager 中安裝它可以在一張圖表里配置多個階梯階段的線程數(shù)。核心思想不變階梯加壓、逐級遞增。6.3 使用命令行執(zhí)行壓測JMeter 官方建議在壓測時使用命令行模式而不是 GUI 模式因為 GUI 模式本身會占用系統(tǒng)資源影響壓測結(jié)果的準確性。按下面的命令執(zhí)行jmeter -n -t perf-test.jmx -l result.jtl -e -o report參數(shù)說明-n非 GUI 模式運行。-t指定測試計劃文件路徑。-l輸出原始結(jié)果文件JTL 格式。-e測試結(jié)束后生成 HTML 報告。-oHTML 報告輸出目錄目錄必須不存在或為空。執(zhí)行完成后打開report目錄下的index.html即可看到完整的圖表化報告包括 TPS、響應(yīng)時間分布、錯誤率等信息。6.4 預(yù)期結(jié)果與數(shù)據(jù)解讀在我設(shè)計的 Demo 接口下預(yù)期你會看到以下現(xiàn)象低并發(fā)階段10、20平均響應(yīng)時間接近 100ms 左右TPS 隨并發(fā)數(shù)近似線性增長。中等并發(fā)階段50、100響應(yīng)時間可能小幅上升到 120ms 左右TPS 仍在增長但增速放緩。較高并發(fā)階段200、400響應(yīng)時間明顯上升可能出現(xiàn) 300ms 甚至 500ms 以上的值。TPS 要么增長極其緩慢要么開始下降。為什么在這個 Demo 中并發(fā) 200 就出現(xiàn)明顯拐點因為 Spring Boot 默認內(nèi)嵌 Tomcat 的max-threads默認值是 200。當(dāng)并發(fā)請求數(shù)超過 200 時多余的請求會進入 Tomcat 的accept-queue排隊。這樣一來請求的“等待時間”開始大幅增加響應(yīng)時間快速上升TPS 增速放緩甚至下降。這個實驗清晰地展示了一個道理系統(tǒng)的最大并發(fā)承載能力取決于系統(tǒng)內(nèi)部最窄的資源的處理能力。對 Demo 服務(wù)來說最窄的資源就是 Tomcat 的最大工作線程數(shù)。每增加一個線程都在增加處理能力但一旦線程池滿了加并發(fā)只會讓隊列越來越長TPS 不再增長。6.5 通過一個最小 Python 腳本模擬并發(fā)與 TPS 的關(guān)系如果你希望在代碼層面更直觀地理解“并發(fā)數(shù)、響應(yīng)時間、TPS”三者之間的換算可以用一個最小 Python 腳本模擬這個過程。# 文件路徑simulate_concurrency.py import time import threading import requests from concurrent.futures import ThreadPoolExecutor BASE_URL http://localhost:8080/demo?delayMillis100 def send_request(_): start time.time() try: requests.get(BASE_URL, timeout5) except Exception as e: print(f請求異常: {e}) return time.time() - start def run_test(concurrency, total_requests200): start time.time() with ThreadPoolExecutor(max_workersconcurrency) as executor: latencies list(executor.map(send_request, range(total_requests))) total_time time.time() - start avg_rt sum(latencies) / len(latencies) tps total_requests / total_time print(f并發(fā)數(shù){concurrency}, 總請求數(shù){total_requests}, 總耗時{total_time:.2f}s, f平均響應(yīng)時間{avg_rt * 1000:.1f}ms, TPS{tps:.1f}) return tps, avg_rt if __name__ __main__: for concurrency in [10, 20, 50, 100, 200, 400]: run_test(concurrency)運行方式python simulate_concurrency.py需要注意這個腳本的并發(fā)模型是有限線程池它模擬的“并發(fā)數(shù)”是從客戶端視角發(fā)起的并發(fā)連接數(shù)和服務(wù)器端實際并發(fā)處理數(shù)是兩碼事。它只能幫你從宏觀上理解趨勢不能取代 JMeter 這類專業(yè)壓測工具。如果通過這個腳本觀察輸出的 TPS你會發(fā)現(xiàn)一個現(xiàn)象在低并發(fā)時TPS 粗略滿足TPS ≈ 并發(fā)數(shù) / 平均響應(yīng)時間在并發(fā)數(shù)超過系統(tǒng)處理能力后平均響應(yīng)時間上漲TPS 不再同步上漲。7. 常見問題與排查思路并發(fā)數(shù)、TPS、響應(yīng)時間“對不上”怎么辦在實際項目中你會發(fā)現(xiàn)壓測出來的數(shù)據(jù)和公式推導(dǎo)的對不上甚至同一套系統(tǒng)隔一天壓出來的數(shù)據(jù)都不一樣。下面整理了幾個高頻問題。問題現(xiàn)象可能原因排查方式解決方案并發(fā)數(shù)增加TPS 卻幾乎不變系統(tǒng)存在單點瓶頸如數(shù)據(jù)庫連接池、單線程處理邏輯、鎖競爭查看數(shù)據(jù)庫連接池使用率、CPU 使用率、線程阻塞情況加大連接池上限優(yōu)化鎖粒度拆分熱點資源并發(fā)數(shù)增加響應(yīng)時間暴漲TPS 下降系統(tǒng)已經(jīng)過載線程池滿請求在排隊查看 Tomcat 線程池活躍線程數(shù)、隊列長度降低并發(fā)壓力先找拐點優(yōu)化處理耗時引入限流保護TPS 很高但錯誤率同步上升斷言未配置完整失敗請求被計入成功或服務(wù)端大量返回錯誤查看 JTL 日志中的錯誤碼添加響應(yīng)斷言核對壓測結(jié)果統(tǒng)計口徑在 JMeter 中增加斷言過濾錯誤響應(yīng)后再統(tǒng)計 TPS壓測響應(yīng)時間正常但線上響應(yīng)時間很慢壓測數(shù)據(jù)不真實只打了緩存命中場景未覆蓋慢查詢線上數(shù)據(jù)量和并發(fā)模型更復(fù)雜檢查壓測數(shù)據(jù)是否與線上數(shù)據(jù)特征一致檢查慢查詢?nèi)罩臼褂觅N近生產(chǎn)的數(shù)據(jù)量增加混合場景同一套系統(tǒng)兩次壓測結(jié)果差異極大壓測機自身資源不足或 JVM 垃圾回收產(chǎn)生抖動監(jiān)控壓測機 CPU、內(nèi)存使用率查看服務(wù)端 GC 日志壓測機單獨部署避免資源爭搶壓測前預(yù)熱系統(tǒng)偶爾出現(xiàn)個別請求響應(yīng)時間極高網(wǎng)絡(luò)抖動、GC 停頓、線程池滿的瞬間排隊查看 TP99、TP999 而不是只關(guān)注平均響應(yīng)時間分析 GC 日志和網(wǎng)絡(luò)監(jiān)控調(diào)整 JVM 參數(shù)JMeter 聚合報告中的 Throughput 和手算 TPS 不一致事務(wù)定義不一致JMeter 默認按請求統(tǒng)計未按事務(wù)統(tǒng)計檢查是否是“邏輯事務(wù)組”模式確認每個事務(wù)包含幾個 Sampler使用“事務(wù)控制器”包裹完整業(yè)務(wù)流程統(tǒng)一 TPS 統(tǒng)計口徑值得強調(diào)的一點是在排查性能問題時不要只盯著壓測工具的輸出。TPS、響應(yīng)時間、并發(fā)數(shù)只是“現(xiàn)象”底層原因往往在系統(tǒng)資源層CPU 使用率、線程池活躍數(shù)、數(shù)據(jù)庫連接池活躍數(shù)、GC 頻率、網(wǎng)絡(luò)帶寬、磁盤 IO。任何一層的資源耗盡都會表現(xiàn)為“并發(fā)數(shù)上去了、TPS 上不去”。8. 性能測試設(shè)計與工程最佳實踐到這里你已經(jīng)理解了并發(fā)數(shù)、響應(yīng)時間、TPS 之間的底層關(guān)系。接下來需要把這套認知沉淀為工程實踐否則理論永遠是理論。8.1 從業(yè)務(wù)流量反推壓測負載很多人在設(shè)計壓測場景時憑感覺設(shè)置線程數(shù)。正確的做法應(yīng)該是從業(yè)務(wù)流量反推。假設(shè)你的業(yè)務(wù)在高峰時段的日活用戶是 10 萬核心接口的 QPS 預(yù)估是 2000平均響應(yīng)時間要求小于 500ms那壓測配置應(yīng)該這樣推導(dǎo)根據(jù) Little 定律需要并發(fā)數(shù) QPS × 平均響應(yīng)時間 2000 × 0.5 1000。但是 1000 是“業(yè)務(wù)請求并發(fā)”不是“JMeter 線程數(shù)”。因為 JMeter 一個線程可以連續(xù)發(fā)起多個請求實際線程數(shù)還需要考慮單線程的循環(huán)次數(shù)和思考時間Think Time。如果你的壓測腳本沒有設(shè)置思考時間1000 個并發(fā)線程會不間斷地發(fā)起請求這屬于“極端壓力”不是“真實壓力”。真實用戶的操作是有思考間隔的。所以壓測時通常分兩種模式不上思考時間探求系統(tǒng)最大處理能力找到性能拐點。加上思考時間模擬真實用戶行為評估線上容量。兩種模式的目標不同不能混為一談。8.2 階梯加壓是常規(guī)操作不要一上來就直接壓 1000 并發(fā)。更穩(wěn)的做法是先小并發(fā)例如 10跑一遍確認功能正確、無報錯然后按 1-2-5-10-20-50 的倍數(shù)關(guān)系遞增每個梯隊保持至少 30 秒記錄每個梯隊下 TPS、響應(yīng)時間、錯誤率三個指標。這種做法的好處是你不僅能知道系統(tǒng)“掛了”還能找到“從哪個并發(fā)開始變慢”。這個拐點比“壓崩了”這個結(jié)果有價值得多。8.3 場景設(shè)計要覆蓋混合鏈路性能壓測不應(yīng)該只壓一個“最慢接口”或“最快接口”。真實用戶的一個操作往往調(diào)用多個接口包含讀緩存、讀數(shù)據(jù)庫、寫數(shù)據(jù)庫、調(diào)用下游等不同行為。比較合理的場景設(shè)計是按照生產(chǎn)環(huán)境的流量占比設(shè)計不同接口的混合比例。舉例來說查詢訂單接口占比 60%創(chuàng)建訂單接口占比 20%取消訂單接口占比 10%支付回調(diào)接口占比 10%這種混合場景壓出來的結(jié)果才接近線上真實情況。8.4 正則提煉并發(fā)數(shù)設(shè)置與確認針對熱搜詞“jmeter 壓測怎么確認系統(tǒng)的并發(fā)數(shù)”這里給出一個可執(zhí)行的確認路徑第一步從業(yè)務(wù)方獲取核心接口的高峰 QPS 數(shù)據(jù)和平均響應(yīng)時間要求。第二步用 Little 定律計算理論并發(fā)數(shù)并發(fā)數(shù) QPS × 平均響應(yīng)時間。第三步在 JMeter 中用該并發(fā)數(shù)初步執(zhí)行壓測觀察實際響應(yīng)時間是否達標。第四步逐步增加并發(fā)數(shù)直到響應(yīng)時間不再滿足要求此時記錄的并發(fā)數(shù)就是系統(tǒng)當(dāng)前的“極限并發(fā)數(shù)”。第五步加上安全余量通常取極限并發(fā)數(shù)的 70% 左右作為生產(chǎn)環(huán)境的限流閾值或容量規(guī)劃基線。注意如果系統(tǒng)使用異步模型、消息隊列等架構(gòu)這個推導(dǎo)過程還需要額外引入隊列積壓量的監(jiān)控指標而不是只盯響應(yīng)時間。8.5 關(guān)注穩(wěn)定性測試與異常場景除了短時間壓測找拐點還需要做穩(wěn)定性壓測。常見做法是以 70% 到 80% 的極限并發(fā)數(shù)持續(xù)壓測 30 分鐘到 1 小時觀察是否存在內(nèi)存泄漏、連接池泄漏、線程數(shù)持續(xù)增長、GC 時間不斷變長等問題。穩(wěn)定性壓測最容易暴露的問題包括內(nèi)存泄漏導(dǎo)致 Full GC 頻繁響應(yīng)時間周期性惡化。數(shù)據(jù)庫連接池泄漏連接被占滿。日志框架導(dǎo)致 IO 阻塞。定時任務(wù)與峰值流量疊加導(dǎo)致資源競爭。8.6 安全提醒別在生產(chǎn)環(huán)境亂壓壓測是會對系統(tǒng)產(chǎn)生高負載的行為任何時候都不要未經(jīng)授權(quán)直接對生產(chǎn)環(huán)境發(fā)起壓力測試。正確的做法是先在測試環(huán)境驗證壓測腳本和預(yù)期結(jié)果。如果確實需要進行生產(chǎn)環(huán)境的容量驗證需要提前協(xié)調(diào)好運維、研發(fā)、DBA 等相關(guān)人員選定低峰期并在有監(jiān)控告警和回滾預(yù)案的情況下進行。生產(chǎn)壓測前必須確認限流降級策略已經(jīng)就緒避免壓測導(dǎo)致雪崩。一句話壓測不是“大家都在測”就可以隨便做的事授權(quán)、備份、回滾、監(jiān)控缺一不可。9. 回到面試題怎么回答 TPS、并發(fā)數(shù)、響應(yīng)時間的底層關(guān)系把前面的內(nèi)容理清之后現(xiàn)在可以回答標題里那個問題了。如果在面試中我被問到“TPS、并發(fā)數(shù)、響應(yīng)時間三者之間存在什么樣的底層關(guān)系”一個能讓面試官眼前一亮的回答思路是這三者之間的關(guān)系不能用一個孤立的公式來概括而應(yīng)該用系統(tǒng)在不同負載階段的行為變化來描述。在系統(tǒng)還沒達到資源瓶頸時它們基本滿足 Little 定律并發(fā)數(shù) TPS × 平均響應(yīng)時間。也就是說TPS 和平均響應(yīng)時間的乘積必須等于系統(tǒng)的在途并發(fā)數(shù)。這是排隊論中一個守恒關(guān)系。但一旦系統(tǒng)進入過載區(qū)這個公式就會“變形”。因為響應(yīng)時間不再穩(wěn)定而是隨著并發(fā)數(shù)上升而快速惡化此時 TPS 會被響應(yīng)時間拖住甚至下降。所以更準確的表述是并發(fā)數(shù)是輸入它影響響應(yīng)時間和 TPS響應(yīng)時間是被影響項它反映了系統(tǒng)壓力TPS 是輸出它體現(xiàn)系統(tǒng)的真實產(chǎn)能。核心的工程能力在于找到“系統(tǒng)從線性增長階段進入飽和階段的拐點”這個拐點才是容量評估的關(guān)鍵。接著主動給面試官講一個自己實際做過的壓測場景“我之前壓測過一個訂單查詢接口在并發(fā) 100 時 TPS 能到 1200響應(yīng)時間 80ms并發(fā)拉到 300 后響應(yīng)時間漲到 250msTPS 反而降到了 1100。后來定位到是數(shù)據(jù)庫連接池不夠用連接等待時間大量增加。調(diào)整連接池參數(shù)后同樣的并發(fā)下TPS 重新回到了 1800 左右?！边@段回答的好處在于展現(xiàn)了你懂理論公式Little 定律。展現(xiàn)了你知道公式的邊界過載區(qū)會失效。展現(xiàn)了你做過真實測試能說出具體數(shù)字變化。展現(xiàn)了你有排查問題的能力定位到連接池。這個回答的邏輯鏈條比背誦“TPS 并發(fā)數(shù) / 響應(yīng)時間”要完整得多。10. 總結(jié)從“會壓”到“懂性能”回到最初的話題會做性能測試的人很多但能講清楚 TPS、并發(fā)數(shù)、響應(yīng)時間底層關(guān)系的人才是真正能解決線上疑難雜癥的人。這篇文章從頭到尾其實就圍繞一條主線并發(fā)數(shù)是施加給系統(tǒng)的壓力響應(yīng)時間是系統(tǒng)感受到的代價TPS 是系統(tǒng)交出的產(chǎn)能。三者的關(guān)系從理想狀態(tài)的 Little 定律出發(fā)在真實系統(tǒng)中會因為線程池、連接池、鎖競爭、GC、異步化等因素發(fā)生變形。理解這些變形找到系統(tǒng)的拐點才是性能測試的核心價值。如果你正在準備性能測試面試不要只背公式。你可以按照這篇文章第 6 節(jié)的思路自己搭一個 Demo 服務(wù)用 JMeter 跑一遍階梯加壓親手畫出 TPS 和響應(yīng)時間隨并發(fā)數(shù)變化的曲線。當(dāng)你親眼看到并發(fā) 50 時 TPS 穩(wěn)定增長、并發(fā) 200 時響應(yīng)時間開始“起飛”、并發(fā) 400 時錯誤率飆升——你對三者的理解就不再是文字層面而是刻進直覺里的東西。下一步你可以繼續(xù)深入學(xué)習(xí)JMeter 的分布式壓測配置、全鏈路壓測方案、容器化環(huán)境下的性能測試、數(shù)據(jù)庫慢查詢分析與索引優(yōu)化、JVM 調(diào)優(yōu)與 GC 日志分析。這些都是性能測試進階路上繞不開的主題。如果這篇文章對你有幫助建議收藏備用。下次做壓測時把本文第 8 節(jié)的“并發(fā)數(shù)確認路徑”拿出來對著做一遍你會發(fā)現(xiàn)性能測試報告的質(zhì)量會有明顯提升。