（五）性能分析思路

一.性能測試分析的能力階梯視圖

二.性能分析思路大綱

• 瓶頸的精準判斷
• 線程遞增的策略
• 性能衰減的過程
• 響應時間的拆分
• 構建分析決策樹
• 場景的比對

1.瓶頸的精準判斷

• 響應時間是用來判斷業務有多快的，而 TPS 纔是用來判斷容量有多大的。

• TPS曲線

  • TPS衰減圖：
    

    • 隨着用戶數的增加，響應時間也在緩慢增加。
    • TPS 前期一直都有增加，但是增加的幅度在變緩，直到變平。

  • TPS曲線可以告訴我們：

    • 有沒有瓶頸：其實準確說所有的系統都有性能瓶頸，只看我們在哪個量級在做性能測試了。
    • 瓶頸和壓力有沒有關係：TPS 隨着壓力的變化而變化，那就是有關係。不管壓力增不增加，TPS 都會出現曲線趨勢問題，那就是無關。

• 響應時間

  • 響應時間圖
    

  • 對應線程圖
    

  • 對應TPS圖
    

    • 通過上圖三個圖我們可以看出，到第40個線程時，TPS基本上達到上限，爲2500左右，響應時間隨着線程數的增加而增加了，系統的瓶頸也出現了。

2.線程遞增的策略

• 對一個系統來說，如果僅在改變壓力策略（其他的條件比如環境、數據、軟硬件配置等都不變）的情況下，系統的最大 TPS 上限是固定的。
• 對於場景中線程（有些工具中叫虛擬用戶）遞增的策略，我們要做到以下幾點：
  • 場景中的線程遞增一定是連續的，並且在遞增的過程中也是有梯度的。
  • 場景中的線程遞增一定要和 TPS 的遞增有比例關係，而不是突然達到最上限。
  • 對於秒殺類的場景，我們前期一定是做好了系統預熱的工作的，在預熱之後，線程突增產生的壓力，也是在可處理範圍的。這時，我們可以設計線程突增的場景來看系統瞬間的處理能力。如果不能模擬出秒殺的陡增，就是不合理的場景。

3.性能衰減的過程

• 壓力產生結果圖
  

• 通過計算可以得到統計圖
  

  • 通過對比知道， 當每線程每秒的請求數降到 55 左右的時候，TPS 就達到上限了，大概在 5000 左右，再接着往上增加線程已經沒有用了，響應時間開始往上增加了。這就是性能衰減的過程（在上圖中，在紅線前面，性能在上升的過程中有幾次抖動，這個抖動到後面變大了，也變頻繁了，如果這是必然出現的抖動，那也是配置問題。）。
  • 通過上述栗子可以得出： 只要每線程每秒的 TPS 開始變少，就意味着性能瓶頸已經出現了。但是瓶頸出現之後，並不是說服務器的處理能力（這裏我們用 TPS 來描述）會下降，應該說 TPS 仍然會上升，在性能不斷衰減的過程中，TPS 就會達到上限。

4.響應時間拆分

• 響應時間通常是一個分析的起點， 在壓力工具上看到的響應時間，都是經過了後端的每一個系統的。那麼，當響應時間變長，我們就要知道，它在哪個階段時間變長了。
• 比如架構如圖所示，拆分時間應該是比較清楚的：
  

5.構建分析決策樹

• 分析決策樹， 是對架構的梳理，是對系統的梳理，是對問題的梳理，是對查找證據鏈過程的梳理，是對分析思路的梳理。它起的是縱觀全局，高屋建瓴的指導作用。

• 分析決策圖
  

  • 從壓力工具中，只需要知道 TPS、響應時間和錯誤率三條曲線，就可以明確判斷瓶頸是否存在。再通過分段分層策略，結合監控平臺、日誌平臺，或者其他的實時分析平臺，知道架構中的哪個環節有問題，然後再根據更細化的架構圖一一拆解下去。

• 數據庫分析決策樹，對 RDBMS 中的 MySQL，可以畫一個如下的決策樹
  

• 操作系統分析決策樹
  

6.場景的對比

• 當你覺得系統中哪個環節不行的時候， 又沒能力分析它，你可以直接做該環節的增加。