在這個圖中,定義了三條曲線、三個區域、兩個點以及三個狀態描述。
三條曲線:吞吐量的曲線(紫色)、使用率 / 使用者數曲線(綠色)、響應時間曲線(深藍色)。三個區域:輕負載區(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 了,而我們之所以接著再加壓力是為了讓指標顯示得更為明顯,以便做出正確的判斷。而調優實際上是控制系統在飽和點之前,這裡有一個水位的問題,控制容量到什麼樣的水位才是效能測試與分析的目標。
總結:
總之,在具體的效能專案中,效能場景是一個非常核心的概念。因為它會包括壓力發起策略、業務模型、監控模型、效能資料(效能中的資料,我一直都不把它稱之為模型,因為在資料層面,測試並沒有做過什麼抽象的動作,只是使用)、軟硬體環境、分析模型等。