前面我們說了性能要有場景，也說了性能場景要有基准性能場景、容量性能場景、穩定性性能場景、異常性能場景。在我有限的十幾年性能生涯中，從來沒有見過有一個性能場景可以超出這幾個分類。下面我將對前面說到的概念進行一一對應。
學習性能的人，一定看吐過一張圖，現在讓你再吐一次。如下：
在這個圖中，定義了三條曲線、三個區域、兩個點以及三個狀態描述。
- 三條曲線：吞吐量的曲線（紫色）、使用率/用戶數曲線（綠色）、響應時間曲線（深藍色）。
- 三個區域：輕負載區（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上不去，資源用不上。所以這個圖默認了一個前提，只要線程能用得上，資源就會蹭蹭往上漲。
這張圖呢，本來只是一個示意，用以說明一些關系。但是后來在性能行業中，有很多沒有完全理解此圖的人將它做為很有道理的“典范”給一些人講，從而引起了越來越多的誤解。
此圖最早的出處是2005年Quest Software的一個PSO Consultant寫的一個白皮書《Performance Testing Methodology》。在18頁論述了這張圖，原文摘錄一段如下：
You can see that as user load increases, response time increases slowly and resource utilization increases almost linearly. This is because the more work you are asking your application to do, the more resources it needs. Once the resource utilization is close to 100 percent, however, an interesting thing happens – response degrades with an exponential curve. This point in the capacity assessment is referred to as the saturation point. The saturation point is the point where all performance criteria are abandoned and utter panic ensues. Your goal in performing a capacity assessment is to ensure that you know where this point is and that you will never reach it. You will tune the system or add additional hardware well before this load occurs.
按照這段描述，這個人只是隨着感覺在描述一種現象，除此無它。比如說，The saturation point is the point where all performance criteria are abandoned and utter panic ensues.在我的工作經驗中，其實在saturation point之前，性能指標就已經可以顯示出問題了，並且已經非常panic了，而我們之所以接着再加壓力是為了讓指標顯示得更為明顯，以便做出正確的判斷。而調優實際上是控制系統在飽和點之前，這里有一個水位的問題，控制容量到什么樣的水位才是性能測試與分析的目標。
我們簡化出另一個圖形，以說明更直接一點的關系。如下所示：
上圖中藍線表示TPS，黃色表示響應時間。
在TPS增加的過程中，響應時間一開始會處在較低的狀態，也就是在A點之前。接着響應時間開始有些增加，直到業務可以承受的時間點B，這時TPS仍然有增長的空間。再接着增加壓力，達到C點時，達到最大TPS。我們再接着增加壓力，響應時間接着增加，但TPS會有下降（請注意，這里並不是必然的，有些系統在隊列上處理得很好，會保持穩定的TPS，然后多出來的請求都被友好拒絕）。
最后，響應時間過長，達到了超時的程度。
在我的工作中，這樣的邏輯關系更符合真實的場景。我不希望在這個關系中描述資源的情況，因為會讓人感覺太亂了。
為什么要把上面描述得如此精細？這是有些人將第一張圖中的Light load對應為性能測試，Heavy Load對應為負載測試，Buckle Zone對應為壓力測試……還有很多的對應關系。
事實上，這是不合理的。
下面我將用場景的定義來替換這些混亂的概念。
為什么我要如此划分？因為在具體場景的操作層面，只有場景中的配置才是具體可操作的。而通常大家認為的性能測試、負載測試、壓力測試在操作的層面，只有壓力工具中線程數的區別，其他的都在資源分析的層面，而分析在很多人的眼中，都不算測試。
拿配置測試和遞增測試舉例吧。
在性能中，我們有非常多的配置，像JVM參數、OS參數、DB參數、網絡參數、容器參數等等。如果我們把測試這些配置參數，稱為”配置測試“，我覺得未免過於狹隘了。因為對於配置參數來說，這只是做一個簡單的變更，而性能場景其實沒有任何變化呀。配置更改前后，會用同樣的性能場景來判斷效果，最多再增加一些前端的壓力，實際的場景並沒有任何變化，所以，我覺得它不配做為一個單獨的分類。
再比如遞增測試，在性能中，基准性能場景也好，容量性能場景也好，哪個是不需要遞增的呢？我知道現在市場上經常有測試工程師，直接就上了幾百幾千線程做壓力（請你不要告訴我這是個正常的場景，鑒於我的精神有限，承受不了這樣的壓力）。除了秒殺場景，同時上所有線程的場景，我還沒有見到過。在一般的性能場景中，遞增都是必不可少的過程。同時，遞增的過程，也要是連續的，而不是100線程、200線程、300線程這樣斷開執行場景，這樣是不合理的。關於這一點，我們將在很多地方着重強調。所以我覺得遞增也不配做一個單獨的分類。
其他的概念，就不一一批駁了。其實在性能測試中，在實際的項目實施中，我們並不需要這么多概念，這些雜七雜八的概念也並沒有對性能測試領域的發展起到什么推進作用。要說雲計算、AI、大數據這些概念，它們本身在引導着一個方向。
而性能測試中被定為“測試”，本身就處在軟件生存周期的弱勢環節，當前的市場發展也並不好。還被這些概念沖亂了本來應該有的邏輯的思路，實在是得不償失。
總結
總之，在具體的性能項目中，性能場景是一個非常核心的概念。因為它會包括壓力發起策略、業務模型、監控模型、性能數據（性能中的數據，我一直都不把它稱之為模型，因為在數據層面，測試並沒有做過什么抽象的動作，只是使用）、軟硬件環境、分析模型等。