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 上不去，資源用不上。所以這個圖默認了一個前提，只要執行緒能用得上，資源就會蹭蹭往上漲。
在我的工作經驗中，其實在 saturation point 之前，性能指標就已經可以顯示出問題了，並且已經非常 panic 了，而我們之所以接著再加壓力是為了讓指標顯示得更為明顯，以便做出正確的判斷。而調優實際上是控制系統在飽和點之前，這裡有一個水位的問題，控制容量到什麼樣的水位才是性能測試與分析的目標。
總結：
總之，在具體的性能項目中，性能場景是一個非常核心的概念。因為它會包括壓力發起策略、業務模型、監控模型、性能數據（性能中的數據，我一直都不把它稱之為模型，因為在數據層面，測試並沒有做過什麼抽象的動作，只是使用）、軟硬體環境、分析模型等。
