1.性能測試的概念
性能測試針對系統的性能指標，建立性能測試模型，制定性能測試方案，制定監控策略，在場景條件下執行性能場景，分析判斷性能瓶頸並且調優，最終得出性能結果來評估系統的性能指標是否滿足既定值。
針對這個性能測試概念的解讀，如下：
性能測試需要有指標：
對應"有指標"這個定義來說，理論上合理的，並且應該有的指標是：時間指標，容量指標，資源利用率指標。
但是這些指標還可以再進行細分.......
性能測試需要有模型：
模型是什么？它是真實場景的抽象。比如說，我們有 100 種業務，但不是每個業務都需要有並發量，可能只有 50 個業務有，那就要把這些有並發的業務統計出來，哪個業務並發多，哪個業務並發少，做壓力時就要控制好這樣的比例。
其實就是我們需要挑選出來需要並發的業務，還要區分這些業務各自的並發是多少，有不同的並發比例。這些數據最好都是從生產環境獲取。
性能測試要有方案：
一個方案中包含着：測試環境、測試數據、測試模型、性能指標、壓力策略、准入准出和進度風險這些關鍵點。
性能測試中要有監控：
這個部分的監控，要有分層、分段的能力，要有全局監控、定向監控的能力
性能測試要有預定的條件：
這里的條件包括軟硬件環境、測試數據、測試執行策略、壓力補償等內容 ，在場景執行之前，這些條件應該是確定的。
關於動態擴展，也是有確定的策略的，比如說CPU 使用率達到 80% 或 I/O 響應時間達到 10ms 時，就做動態擴展。
性能測試中要有場景：
對性能場景中的“場景”比較正宗的描述是：在既定的環境（包括動態擴展等策略）、既定的數據（包括場景執行中的數據變化）、既定的執行策略、既定的監控之下，執行性能腳本，同時觀察系統各層級的性能狀態參數變化，並實時判斷分析場景是否符合預期。這才是真正的場景全貌。
性能場景也要有分類
- 基准性能場景：這里要做的是單交易的容量，為混合容量做准備（不要跟我說上幾個線程跑三五遍腳本叫基准測試，那只是場景執行之前的預執行，用來確定有沒有基本的腳本和場景設計問題，不能稱之為一個分類）。
- 容量性能場景：這一環節必然是最核心的性能執行部分。根據業務復雜度的不同，這部分的場景會設計出很多個
- 穩定性性能場景：穩定性測試必然是性能場景的一個分類。只是現在在實際的項目中，穩定性測試基本沒和生產一致過。在穩定性測試中，顯然最核心的元素是時間（業務模型已經在容量場景中確定了），而時間的設置應該來自於運維周期，而不是來自於老板、產品和架構等這些人的心理安全感
- 異常性能場景：要做異常性能場景，前提就是要有壓力。在壓力流量之下，模擬異常。這個異常的定義是很寬泛的
性能測試中要有分析調優：
就要不要進行調優做了如下划分
- 新系統性能測試類：這樣的項目一般都會要求測試出系統的最大容量，不然上線心里沒底。
- 舊系統新版本性能測試類：這樣的項目一般都是和舊版本對比，只要性能不下降就可以根據歷史數據推算容量，對調優要求一般都不大。
- 新系統性能測試優化類：這類的系統不僅要測試出最大容量，還要求調優到最好
對性能團隊的職責定位有如下幾種。
- 性能驗證：針對給定的指標，只做性能驗證。第三方測試機構基本上都是這樣做的。
- 性能測試：針對給定的系統，做全面的性能測試，可以得到系統最大容量，但不涉及到調優。
- 性能測試 + 分析調優：針對給定的系統，做全面的性能測試，同時將系統調優到最優狀態。
當只能做性能驗證的團隊遇到舊系統新版本性能測試類和新系統性能測試優化類項目，那就會很吃力，這樣的團隊只能做新系統性能測試類項目。
當做性能測試的團隊，遇到需要新系統性能測試優化類項目，照樣很吃力。這樣的團隊能做前兩種項目。
只有第三個團隊才能做第三種項目。
性能測試肯定要有結果報告：
性能結果如何來定義呢？有了前面監控的定義，有了場景執行的過程，產生的數據就要整理到結果報告中了。
這個文檔工作也是很重要的，是體現性能團隊是否專業的一個重要方面。並不是整理一個 Word，美化一下格式就可以了。
測試報告是需要匯報或者歸檔的。
總結：
在性能測試的概念中，性能指標、性能模型、性能場景、性能監控、性能實施、性能報告，這些既是概念中的關鍵詞，也可以說是性能測試的方法和流程。
2.TPS和響應時間之間是什么關系？
首先，性能要有場景， 性能場景要有基准性能場景、容量性能場景、穩定性性能場景、異常性能場景
然后來看一張圖，分析這張圖：
在這個圖中，定義了三條曲線、三個區域、兩個點以及三個狀態描述。
- 三條曲線：吞吐量的曲線（紫色）、利用率（綠色）、響應時間曲線（深藍色）。
- 三個區域：輕負載區（Light Load）、重負載區（Heavy Load）、塌陷區（Buckle Zone）。
- 兩個點：最優並發用戶數（The Optimum Number of Concurrent Users）、最大並發用戶數（The Maximum Number of Concurrent Users）。
- 三個狀態描述：資源飽和（Resource Saturated）、吞吐下降（Throughput Falling）、用戶受影響（End Users Effected）。
首先，很多時候，重負載區的資源飽和，和 TPS 達到最大值之間都不是在同樣的並發用戶數之下的。比如說，當 CPU 資源使用率達到 100% 之后，隨着壓力的增加，隊列慢慢變長，響應時間增加，但是由於用戶數增加的幅度大於響應時間增加的幅度之前，TPS 仍然會增加，也就是說資源使用率達到飽和之后還有一段時間 TPS 才會達到上限。
大部分情況下，響應時間的曲線都不會像圖中畫得這樣陡峭，並且也不一定是在塌陷區突然上升，更可能的是在重負載區突然上升。
另外，吞吐量曲線不一定會出現下降的情況，在有些控制較好的系統中會維持水平。
有經驗的性能測試人員，都會更關心服務端能處理的請求數即 TPS，而不是壓力工具中的線程數
這張圖沒有考慮到鎖或線程等配置不合理的場景，而這類場景又比較常見。也就是我們說的，TPS 上不去，資源用不上。所以這個圖默認了一個前提，只要線程能用得上，資源就會蹭蹭往上漲。
上圖中藍線表示 TPS，黃色表示響應時間
在 TPS 增加的過程中，響應時間一開始會處在較低的狀態，也就是在 A 點之前。接着響應時間開始有些增加，直到業務可以承受的時間點 B，這時 TPS 仍然有增長的空間。再接着增加壓力，達到 C 點時，達到最大 TPS。我們再接着增加壓力，響應時間接着增加，但 TPS 會有下降（請注意，這里並不是必然的，有些系統在隊列上處理得很好，會保持穩定的 TPS，然后多出來的請求都被友好拒絕）。最后，響應時間過長，達到了超時的程度。
用場景的定義來替換這些混亂的概念
通常大家認為的性能測試、負載測試、壓力測試在操作的層面，只有壓力工具中線程數的區別
在性能中，我們有非常多的配置，像 JVM 參數、OS 參數、DB 參數、網絡參數、容器參數等等
在一般的性能場景中，遞增都是必不可少的過程。同時，遞增的過程，也要是連續的，而不是 100 線程、200 線程、300 線程這樣斷開執行場景，這樣是不合理的。
總之，在具體的性能項目中，性能場景是一個非常核心的概念。因為它會包括壓力發起策略、業務模型、監控模型、性能數據（性能中的數據，我一直都不把它稱之為模型，因為在數據層面，測試並沒有做過什么抽象的動作，只是使用）、軟硬件環境、分析模型等
3.怎么理解TPS、QPS、RT、吞吐量這些性能指標？
通常我們都從兩個層面定義性能場景的需求指標：業務指標和技術指標。
這兩個層面需要有映射關系，技術指標不能脫離業務指標。
這張示意圖以便你理解業務指標和性能指標之間的關系
這個示意顯然不夠詳細，但也能說明關系了。所有的技術指標都是在有業務場景的前提下制定的，而技術指標和業務指標之間也要有詳細的換算過程。這樣一來，技術指標就不會是一塊飛地。同時，在回答了技術指標是否滿足的同時，也能回答是否可以滿足業務指標。
有了這樣的關聯關系，下面我們看一下性能測試行業常用的性能指標表示法。
QPS 一開始是用來描述 MySQL 中 SQL 每秒執行數 Query Per Second，所有的 SQL 都被稱為 Query
QPS 和 TPS 到底是什么關系呢？
RPS 指的是每秒請求數。這個概念字面意思倒是容易理解，但是有個容易誤解的地方就是，它指的到底是哪個層面的 Request？如果說 HTTP Request，那么和 Hits Per Second 又有什么關系呢？
HPS，這也是個在字面意思上容易理解的概念。只是 Hit 是什么？有人將它和 HTTP Request 等價，有人將它和用戶點擊次數等價。
我們都知道 TPS 是性能領域中一個關鍵的性能指標概念，它用來描述每秒事務數。我們也知道 TPS 在不同的行業、不同的業務中定義的粒度都是不同的。所以不管你在哪里用 TPS，一定要有一個前提，就是所有相關的人都要知道你的 T 是如何定義的。
通常情況下，我們會根據場景的目的來定義 TPS 的粒度。如果是接口層性能測試，T 可以直接定義為接口級；如果業務級性能測試，T 可以直接定義為每個業務步驟和完整的業務流。
用一個示意圖來說明一下。
如果我們要單獨測試接口 1、2、3，那 T 就是接口級的；如果我們要從用戶的角度來下一個訂單，那 1、2、3 應該在一個 T 中，這就是業務級的了
當然，這時我們還要分析系統是如何設計的。通常情況下，積分我們都會異步，而庫存不能異步哇。所以這個業務，你可以看成只有 1、2 兩個接口，但是在做這樣的業務級壓力時，3 接口也是必須要監控分析的。
所以，性能中 TPS 中 T 的定義取決於場景的目標和 T 的作用。一般我們都會這樣來定事務。
接口級腳本：
——事務 start（接口 1）
接口 1 腳本
——事務 end（接口 1）
——事務 start（接口 2）
接口 2 腳本
——事務 end（接口 2）
——事務 start（接口 3）
接口 3 腳本
——事務 end（接口 3）
業務級接口層腳本（就是用接口拼接出一個完整的業務流）：
——事務 start（業務 A）
接口 1 腳本 - 接口 2（同步調用）
接口 1 腳本 - 接口 3（異步調用）
——事務 end（業務 A）
用戶級腳本
——事務 start（業務 A）
點擊 0 - 接口 1 腳本 - 接口 2（同步調用）
點擊 0 - 接口 1 腳本 - 接口 3（異步調用）
——事務 end（業務 A）
你要創建什么級別的事務，完全取決於測試的目的是什么，在性能測試過程中，TPS 之所以重要，是因為它可以反應出一個系統的處理能力。
首先是 QPS，如果它描述的是數據庫中的 Query Per Second，從上面的示意圖中來看，其實描述的是服務后面接的數據庫中 SQL 的每秒執行條數。如果描述的是前端的每秒查詢數，那就不包括插入、更新、刪除操作了。顯然這樣的指標用來描述系統整體的性能是不夠全面的。所以不建議用 QPS 來描述系統整體的性能，以免產生誤解。
RPS（Request per second），每秒請求數。看似簡單的理解，但是對於請求數來說，要看是在哪個層面看到的請求，因為請求這個詞，實在是太泛了。
HPS（Hits Per Second），每秒點擊數。Hit 一般在性能測試中，都用來描述 HTTP Request。當它描述 HTTP Request 時，如果 RPS 也在描述 HTTP Request，那這兩個概念就完全一樣了。
- 用一個概念統一起來。我覺得直接用 TPS 就行了，其他的都在各層面加上限制條件來描述。比如說，接口調用 1000 Calls/s，這樣不會引起混淆。
- 在團隊中定義清楚術語的使用層級。
- 如果沒有定義使用層級，那只能在說某個概念的時候，加上相應的背景條件。
響應時間 RT
在性能中，還有一個重要的概念就是響應時間（Response Time）。這個比較容易理解。我們接着用這張示意圖說明：
RT = T2-T1。計算方式非常直接簡單。但是，我們要知道，這個時間包括了后面一連串的鏈路。
性能測試工具都會記錄響應時間，但是，都不會給出后端鏈路到底哪里慢。經常有人問問題就直接說，我的響應時間很慢。問題在哪呢？在這種情況下，只能回答：不知道。因為我們要先畫架構圖，看請求鏈路，再一層層找下去。比如：
所有服務的進出口上都做記錄，然后計算結果就行了。在做網關、總線這樣的系統時，基本上都會考慮這個功能。而現在，隨着技術的發展，鏈路監控工具和一些 Metrics 的使用，讓這個需求變得簡單了不少。比如說這樣的展示：
它很直觀地顯示了，在一個請求鏈路上，每個節點消耗的時間和請求的持續時間。
為什么要性能測試團隊來主導 協調其他團隊的人一起來分析瓶頸點
舉例來說，DB 的 CPU 使用率達到 90% 以上，DBA 會覺得沒有問題，因為都是業務的 SQL，並不是 DB 本身有問題。開發覺得 SQL 執行時間慢是因為 DB 有問題，而不是自己寫的有問題，因為業務邏輯並沒有錯，有問題的點應該是 DB 上索引不合理、配置不合理。你看，同樣的問題，每個人的看法都有區別。當然也不能排除有些人就是想推諉責任。這時怎么辦呢？如果你可以把執行計划拿出來，告訴大家，這里應該創建索引，而那里應該修改業務條件，這時就具體了。
（重點）壓力工具中的線程數和用戶數與 TPS
但是做性能的都會知道，並發線程數在沒有模擬真實用戶操作的情況下，和真實的用戶操作差別非常遠。
現在很多人都沒有明白壓力工具中的線程數和用戶以及 TPS 之間是怎樣的關系。同樣，我們先畫一個示意圖來說明一下。
這里先說明一個前提，上面的一個框中有四個箭頭，每個都代表着相同的事務。
在說這個圖之前，我們要先說明“並發”這個概念是靠什么數據來承載的。
在上面的內容中，我們說了好多的指標，但並發是需要具體的指標來承載的。你可以說，我的並發是 1000TPS，或者 1000RPS，或者 1000HPS，這都隨便你去定義。但是在一個具體的項目中，當你說到並發 1000 這樣沒有單位的詞時，一定要讓大家都能理解這是什么。
在上面這張示意圖中，其實壓力工具是 4 個並發線程，由於每個線程都可以在一秒內完成 4 個事務，所以總的 TPS 是 16。這非常容易理解吧。而在大部分非技術人的腦子里，這樣的場景就是並發數是 4，而不是 16。
那么用戶數怎么來定義呢？涉及到用戶就會比較麻煩一點。因為用戶有了業務含義，所以有些人認為一個系統如果有 1 萬個用戶在線，那就應該測試 1 萬的並發線程，這種邏輯實在是不技術。通常，我們會對在線的用戶做並發度的分析，在很多業務中，並發度都會低於 5%，甚至低於 1%。
拿 5% 來計算，就是 10000 用戶 x5%=500(用戶級 TPS)，注意哦，這里是 TPS，而不是並發線程數。如果這時響應時間是 100ms，那顯然並發線程數是 500TPS/(1000ms/100ms)=50(並發線程)。
通過這樣簡單的計算邏輯，我們就可以看出來用戶數、線程數和 TPS 之間的關系了。
但是！響應時間肯定不會一直都是 100ms 的嘛。所以通常情況下，上面的這個比例都不會固定，而是隨着並發線程數的增加，會出現趨勢上的關系。
所以，在性能分析中，我一直在強調着一個詞：趨勢！
業務模型應該如何得到呢？這里有兩種方式是比較合理的：
- 根據生產環境的統計信息做業務比例的統計，然后設定到壓力工具中。有很多不能在線上直接做壓力測試的系統，都通過這種方式獲取業務模型。
- 直接在生產環境中做流量復制的方式或壓力工具直接對生產環境發起壓力的方式做壓力測試。這種方式被很多人稱為全鏈路壓測。其實在生產中做壓力測試的方式，最重要的工作不是技術，而是組織協調能力。相信參與過的人都能體會這句話的重量。
那么響應時間如何設計比較合理呢？這里有兩種思路推薦給你。
- 同行業的對比數據。
- 找到使用系統的樣本用戶（越多越好），對他們做統計，將結果拿出來，就是最有效的響應時間的制定標准。
總結:
今天的這一篇和前兩篇文章是一個體系，我利用這三篇文章對當前的性能測試市場上的一些關鍵概念進行一些拆解。
性能測試策略、性能測試場景、性能測試指標，這些關鍵的概念在性能測試中深深地影響着很多人。我們簡化它的邏輯，只需要記住幾個關鍵字就可以，其他的都不必使用。
- 性能測試概念中：性能指標、性能模型、性能場景、性能監控、性能實施、性能報告。
- 性能場景中：基准場景、容量場景、穩定性場景、異常場景。
- 性能指標中：TPS、RT。 （記住 T 的定義是根據不同的目標來的）
4.JMeter和LoadRunner：要知道工具僅僅只是工具
JMeter、LoadRunner 的基本功能基本就做了兩件事情，做腳本和發壓力
在性能場景學習期這個階段，你關心的將不再是工具的使用操作，而是如何做一個合理的性能測試。你可以學會調整業務比例，並設計到壓力工具中；你可以學會參數化數據的提取邏輯；你可以學會場景中要觀察哪些數據。按照這個思路，再做幾個項目，就會慢慢摸着一些門道。
學會使用工具了，也有了場景設計的經驗，通過監控工具也拿到了一堆大大小小的數據。可是，數據也太多了，還在不斷的變化。我又怎么判斷性能瓶頸在哪里呢？
我們應該知道我們針對一個性能壓測結果，我需要看什么數據，我想要看什么數據，而不是“把數據都給我看看”。
公司性能團隊成長的三個階段階段
性能團隊初建
這時的團隊，可以執行場景，可以拿出數據，但工作出的結果並不理想。團隊整體的價值就體現在每天跟着版本跑來跑去，一輪輪地測試下去，一個版本短則一兩個星期，長則一個月。沒有時間去考慮測試結果對整個軟件生命周期的價值，在各種瑣碎的項目中疲於奔命。做腳本，拿出 TPS 和響應時間，做版本基線比對，出數據羅列式的性能測試報告。
性能團隊初成熟
到了這個階段，團隊已經可以應付版本的更迭帶來的性能工作壓力，團隊合作良好，稍有余力，開始考慮團隊價值所在，在公司的組織結構中應該承擔什么樣的職責。在產品的流水線上終於可以占有一席之地了。這樣很好，只是從實際的技術細節上來說，仍然沒有擺脫第一階段中瑣碎的工作，沒有把性能的價值體現出來，只是一個報告提供機器。這時就需要考慮平台上是不是可以加個 SLA 來限制一下？在各個流程的關卡上，是不是可以做些性能標准？是不是該考慮下准入准出規則了？是的，這時一個團隊開始慢慢走向成熟，站住腳之后要開始爭取尊重了。
性能團隊已成熟
直觀上說，主要體現在一下幾個方面。
1. 通過你的測試和分析優化之后，性能提升了多少？
一個成熟的團隊應該回答的是：提升了 10 倍，我們調優了什么。這樣的回答有理有據，底氣十足。
2. 通過你的測試和分析優化之后，節省了多少成本？
這個問題就沒有那么好回答了，因為你要知道整體的容量規划，線上的真實運營性能。如果之前的版本用了 200 台機器，而通過我們的測試分析優化之后，只用到了 100 台機器，那成本就很明顯了。
對個人以及團隊來說，工具應該如何選擇
比較常見的工具做下比對
所以在壓測工具中同時收集監控計數器，就是不符合真實場景的。這樣壓測平台就有出現的必要了，我們可以看到出現了五花八門的壓測平台，也會有后端監控數據的曲線，乍看起來，就兩個字：全面！可是，同樣也沒有告訴你瓶頸在哪里。
壓測工具也好，壓測平台也好，都沒有一個工具可以直接告訴你瓶頸在哪里，能告訴你的只是數據是什么。分析只有靠自己，在這個過程中，我們也會用到很多的分析剖析工具，用這些工具的人也都會知道，工具也只提供數據，不會告訴你瓶頸點在哪里。
如果選擇合適自己的工具？
所以我們用工具，一定要知道幾點：
- 工具能做什么？
- 工具不能做什么？
- 我們用工具的目標是什么？
- 當工具達不到目標時，我們怎么辦？
對企業，舉例來說：
如果是一個需要支持萬級、億級 TPS 的電商網站，本身就是雲基礎架構，那么可能最簡單的就是直接買這家的雲壓測工具就好了。這樣做的優點是不用再買機器做壓力了。壓力發起，主要就是靠壓力機的量堆出來大並發
但缺點也很明顯，一是不能長期使用，長期用，費用就高了。二是數據也只能自己保存比對，如果測試和版本跨度大，還是要自己比對，無法自動比對。最后一個缺點就是 壓力機不受控了。
所以如果有這樣需求的企業，也基本上可以自己開發一套雲壓測工具了，從使用周期和長遠的成本上來看，自已開發，都是最划算的。
如果是一個需要支持每秒 100TPS 的企業內部業務系統，就完全沒必要買什么雲服務了，自己找一台 4C8G 的機器，可能就壓得夠了。
5.你知道並發用戶數應該怎么算嗎？
在不同的測試目標中設置不同的事務，也就是 TPS 中的 T 要根據實際的業務產生變化。那么問題又來了，TPS 和並發數是什么關系呢？ 在並發中誰來承載”並發“這個概念呢？
我們先說一下所謂的“絕對並發”和“相對並發”這兩個概念。
- 絕對並發指的是同一時刻的並發數；
- 相對並發指的是一個時間段內發生的事情。
什么是並發？
我們假設上圖中的這些小人是嚴格按照這個邏輯到達系統的，那顯然，系統的絕對並發用戶數是 4。如果描述 1 秒內的並發用戶數，那就是 16。是不是顯而易見？但是，在實際的系統中，用戶通常是這樣分配的：
也就是說，這些用戶會分布在系統中不同的服務、網絡等對象中。這時候”絕對並發“這個概念就難描述了，你說的是哪部分的絕對並發呢？
所以“絕對並發”這個概念，不管是用來描述硬件細化的層面，還是用來描述業務邏輯的層面，都是沒什么意義的。
我們只要描述並發就好了，不用有“相對”和“絕對”的概念，這樣可以簡化溝通，也不會出錯。
那么如何來描述上面的並發用戶數呢？在這里我建議用 TPS 來承載“並發”這個概念。並發數是 16TPS，就是 1 秒內整個系統處理了 16 個事務。這樣描述就夠了，別糾結。
在線用戶數、並發用戶數怎么計算?
在線用戶數和並發用戶數應該如何算呢？下面我們接着來看示意圖：
如上圖所示，總共有 32 個用戶進入了系統，但是綠色的用戶並沒有任何動作，那么顯然，在線用戶數是 32 個，並發用戶數是 16 個，這時的並發度就是 50%。
但在一個系統中，通常都是下面這個樣子的。
為了能 hold 住更多的用戶，我們通常都會把一些數據放到 Redis 這樣的緩存服務器中。所以在線用戶數怎么算呢，如果僅從上面這種簡單的圖來看的話，其實就是緩存服務器能有多大，能 hold 住多少用戶需要的數據。
最多再加上在超時路上的用戶數。如下所示：
所以我們要是想知道在線的最大的用戶數是多少，對於一個設計邏輯清晰的系統來說，不用測試就可以知道，直接拿緩存的內存來算就可以了。
假設一個用戶進入系統之后，需要用 10k 內存來維護一個用戶的信息，那么 10G 的內存就能 hold 住 1,048,576 個用戶的數據，這就是最大在線用戶數了。在實際的項目中，我們還會將超時放在一起來考慮。
但並發用戶數不同，他們需要在系統中執行某個動作。我們要測試的重中之重，就是統計這些正在執行動作的並發用戶數。
當我們統計生產環境中的在線用戶數時，並發用戶數也是要同時統計的。這里會涉及到一個概念：並發度。
要想計算並發用戶和在線用戶數之間的關系，都需要有並發度。
那么該如何計算或者估算並發度呢？
1. 統計某時段的當前在線用戶數；
2. 統計同一時段的操作某個功能的用戶數；
3. 把所有功能操作的用戶數都統計出來；
4. 將統計出來的用戶數除以在線用戶數就知道並發度了。
服務端線程的工作情況圖在哪看？
java的可以用jvisuamvm之類的工具看
做性能的人都知道，我們有時會接到一個需求，那就是一定要測試出來系統最大在線用戶數是多少。這個需求怎么做呢？
很多人都是通過加思考時間（有的壓力工具中叫等待時間，Sleep 時間）來保持用戶與系統之間的 session 不斷，但實際上的並發度非常非常低。
那就是壓力工具中的線程或用戶數到底是不是用來描述性能表現的？我們通過一個示意圖來說明：
通過這個圖，我們可以看到一個簡單的計算邏輯：
- 如果有 10000 個在線用戶數，同時並發度是 1%，那顯然並發用戶數就是 100。
- 如果每個線程的 20TPS，顯然只需要 5 個線程就夠了（請注意，這里說的線程指的是壓力機的線程數）。
- 這時對 Server 來說，它處理的就是 100TPS，平均響應時間是 50ms。50ms 就是根據 1000ms/20TPS 得來的（請注意，這里說的平均響應時間會在一個區間內浮動，但只要 TPS 不變，這個平均響應時間就不會變）。
- 如果我們有兩個 Server 線程（不是壓力機線程）來處理，那么一個線程就是 50TPS，這個很直接吧。
- 請大家注意，這里我有一個轉換的細節，那就是並發用戶數到壓力機的並發線程數。這一步，我們通常怎么做呢？就是基准測試的第一步。關於這一點，我們在后續的場景中交待。
而我們通常說的“並發”這個詞，依賴 TPS 來承載的時候，指的都是 Server 端的處理能力，並不是壓力工具上的並發線程數。在上面的例子中，我們說的並發就是指服務器上 100TPS 的處理能力，而不是指 5 個壓力機的並發線程數。
上面說了這么多，我們現在來看一個實例。
這個例子很簡單，就是：
JMeter（1 個線程） - Nginx - Tomcat - MySQL
通過上面的邏輯，我們先來看看 JMeter 的處理情況：
summary + 5922 in 00:00:30 = 197.4/s Avg: 4 Min: 0 Max: 26 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0 summary = 35463 in 00:03:05 = 192.0/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%) summary + 5922 in 00:00:30 = 197.5/s Avg: 4 Min: 0 Max: 24 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0 summary = 41385 in 00:03:35 = 192.8/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%) summary + 5808 in 00:00:30 = 193.6/s Avg: 5 Min: 0 Max: 25 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0 summary = 47193 in 00:04:05 = 192.9/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%)
我們可以看到，JMeter 的平均響應時間基本都在 5ms，因為只有一個壓力機線程，所以它的 TPS 應該接近 1000ms/5ms=200TPS。從測試結果上來看，也確實是接近的。有人說為什么會少一點？因為這里算的是平均數，並且這個數據是 30s 刷新一次，用 30 秒的時間內完成的事務數除以 30s 得到的，但是如果事務還沒有完成，就不會計算在內了；同時，如果在這段時間內有一兩個時間長的事務，也會拉低 TPS。
那么對於服務端呢，我們來看看服務端線程的工作情況。
可以看到在服務端，我開了 5 個線程，但是服務端並沒有一直干活，只有一個在干活的，其他的都處於空閑狀態。這是一種很合理的狀態。但是你需要注意的是，這種合理的狀態並不一定是對的性能狀態。
- 並發用戶數（TPS）是 193.6TPS。如果並發度為 5%，在線用戶數就是 193.6/5%=3872。
- 響應時間是 5ms。
- 壓力機並發線程數是 1。這一條，我們通常也不對非專業人士描述，只要性能測試工程師自己知道就可以了。
下面我們換一下場景，在壓力機上啟動 10 個線程。結果如下：
summary + 11742 in 00:00:30 = 391.3/s Avg: 25 Min: 0 Max: 335 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0 summary = 55761 in 00:02:24 = 386.6/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%) summary + 11924 in 00:00:30 = 397.5/s Avg: 25 Min: 0 Max: 80 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0 summary = 67685 in 00:02:54 = 388.5/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%) summary + 11884 in 00:00:30 = 396.2/s Avg: 25 Min: 0 Max: 240 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0 summary = 79569 in 00:03:24 = 389.6/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%)
平均響應時間在 25ms，我們來計算一處，(1000ms/25ms)*10=400TPS，而最新刷出來的一條是 396.2，是不是非常合理？
再回來看看服務端的線程：
同樣是 5 個線程，現在就忙了很多。
- 並發用戶數（TPS）是 396.2TPS。如果並發度為 5%，在線用戶數就是 396.2/5%=7924。
- 響應時間是 25ms。
- 壓力機並發線程數是 10。這一條，我們通常也不對非專業人士描述，只要性能測試工程師自己知道就可以了。
如果要有公式的話，這個計算公式將非常簡單：
下面公司代表個人理解：
理論TPS計算：
TPS=在線用戶數*並發度
實際TPS計算：
TPS=1000ms/響應時間(單位ms)∗壓力機線程數
對於壓力工具來說，只要不報錯，我們就關心 TPS 和響應時間就可以了，因為 TPS 反應出來的是和服務器對應的處理能力，至少壓力線程數是多少，並不關鍵。
但是通常服務端都是有業務邏輯的，既然有業務邏輯，顯然不會比壓力機快。應該說，服務端需要更多的線程來處理壓力機線程發過來的請求。所以我們用幾台壓力機就可以壓幾十台服務端的性能了。
總結
通過示意圖和示例，我描述了在線用戶數、並發用戶數、TPS（這里我們假設了一個用戶只對應一個事務）、響應時間之間的關系。有幾點需要強調：
- 通常所說的並發都是指服務端的並發，而不是指壓力機上的並發線程數，因為服務端的並發才是服務器的處理能力。
- 性能中常說的並發，是用 TPS 這樣的概念來承載具體數值的。
- 壓力工具中的線程數、響應時間和 TPS 之間是有對應關系的。