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