【效能測試】四、效能分析思路有哪些？
我們知道，效能測試的目的是分析判斷效能瓶頸並調優，最終得出效能結果來評估系統的效能指標是否滿足既定值。
那麼，如何能做好分析，顯然是非常重要的。
通常來說，對於效能分析有這樣一幅階梯圖：
- 工具操作：包括壓力工具、監控工具、剖析工具、除錯工具。
- 數值理解：包括上面工具中所有輸出的資料。
- 趨勢分析、相關性分析、證據鏈分析：就是理解了工具產生的數值之後，還要把它們的邏輯關係想明白。這才是效能測試分析中最重要的一環。
- 調優：這是最後一步，調優的方案策略就有很多種了，具體選擇取決於調優成本和產生的效果。
在做效能分析的時候，需要融合以上的能力。高樓老師歸納了效能分析思路大綱：
- 瓶頸的精準判斷
- 執行緒遞增的策略
- 效能衰減的過程
- 響應時間的拆分
- 構建分析決策樹
- 場景的對比
一、瓶頸的精準判斷
通常，在效能測試過程中，我們會不斷觀察 TPS 和 響應時間的曲線圖，從中分析出效能的拐點。值得注意的是：大部分系統其實是沒有明確的拐點。
TPS 曲線
通常，如果畫一幅示意圖來描述 TPS 的衰減過程，大概會如下所示：
- 隨著使用者數的增加，響應時間也在緩慢增加。
- TPS 前期一直都有增加，但是增加的幅度在變緩，直到變平。
在這樣的趨勢圖中，我們是看不到明確的拐點的。但是可以判斷有瓶頸。
所以，TPS 曲線可以明確告訴我們：
- 是否存在瓶頸：準確來說，所有的系統都有效能瓶頸，只不過看我們在哪個量級做效能測試。
- 瓶頸和壓力是否有關：TPS 隨著壓力的變化而變化，那就是有關係。另一種，不管壓力增不增加，TPS 都會出現曲線趨勢問題，那就是無關。
響應時間 曲線
TPS 用來判斷容量有多大，而響應時間則是用來判斷業務有多快。
看2個對應的圖，分別是執行緒數和響應時間：
很明顯，隨著執行緒的增多，響應時間也在增加。
ok，接著再看一下對應的 TPS 圖：
如果這時候我們只看 TPS 曲線，其實也可能判斷出：存在瓶頸，和壓力有關。到第 40 個執行緒時，TPS 基本上達到上限，為 2500 左右。
所以說，其實 TPS 就可以告訴我們系統有沒有瓶頸了，而響應時間是用來判斷業務有多快的。
但是，響應時間會是效能分析調優的重要分析物件
二、執行緒遞增的策略
遞增與一次性加到最大是有很大區別的。
比如，做了2個場景：
這裡場景1 就是不合理的。
我們要確定設定的效能場景是正確的，執行緒是逐漸遞增的，而不應該一上來就上幾百個執行緒，這樣不符合一般情況下的真實場景。
即便是秒殺場景，真實的生產環境，也會有個資料預熱的過程。在預熱之後，執行緒突增產生的壓力，也是在可處理範圍的。
此外，對於已經 TPS 已經達到上限的情況，再增加更多的執行緒，除了響應時間的增加，沒有其他作用。
這裡高樓老師還給出了做效能場景遞增的經驗值：
- 這個參考遞增幅度不是適用所有系統，根據實際的測試過程來做相應的判斷
- 響應時間少，遞增幅度小。因為響應時間小的話，每個執行緒產生的TPS就高，如果執行緒增加多，整體的壓力增加的就快，不利於產生明顯的效能梯度用來分析。
還要補充一個點：執行緒遞增過程不能斷。
原因是保證在測試過程中資源分配的合理性，減少偏差，便於分析出當前環境中的效能瓶頸點。否則斷開後系統動態資源會重新分配，造成分析偏差。
三、效能衰減的過程
有了瓶頸的判斷能力，也有了執行緒遞增的意識，接下來就要有判斷效能衰減的能力。
這是一個壓力過程中產生的結果圖：
- 線上程達到 24 時，TPS 為 1810.6，也就是每執行緒每秒發出 75.44 個請求。
- 線上程達到 72 時，TPS 為 4375.1，也就是每執行緒每秒發出 60.77 個請求。
- 線上程達到 137 時，TPS 為 5034，也就是每執行緒每秒發出 36.74 個請求。
每執行緒每秒發出的請求數在變少，但是整體 TPS 是在增加的。繼續看下面的分析對比圖：
從圖1中，找到 TPS 的瓶頸位置在5000，執行緒數維度大概在30個（紅線區分）。
然後通過紅線的大致比對可以知道，當每執行緒每秒的請求數降到 55 左右的時候，TPS 就達到上限了，再接著往上增加執行緒已經沒有用了，響應時間開始往上增加。
這就是效能衰減的過程：
- 只要每執行緒每秒的 TPS 開始變少，就意味著效能瓶頸已經出現了。
- 但是瓶頸出現之後，並不是說伺服器的處理能力下降。
- TPS 仍然會上升，在效能不斷衰減的過程中，TPS 就會達到上限。
延伸問題：衰減到最大 TPS 時是否停止場景？
這個還是取決於我們的場景目標：
- 如果我們只是為了得到最大 TPS，那確實可以停止。
- 如果為了讓瓶頸更為明顯，就不需要停止場景，只要不報錯，就接著往上壓，
四、響應時間的拆分
當我們選擇繼續施壓來擴大瓶頸，後面的響應時間就會變長，直到超時。
由於在壓力工具上看到的響應時間，都是經過了後端的每一個系統的，所以我們就需要拆分響應時間，分析出在哪個階段變長了。
但是，由於應用的架構不同，拆分的方法也不同。
單應用
對單應用來說，思路大概是這樣：
- 檢視 Nginx 上的時間。
- 檢視 Tomcat 上的時間。
- 看前端瀏覽器的時間消耗，這裡建議使用 Content Download 的時間來描述。
微服務
這種再單個拆就很痛苦了，首先要知道每個系統消耗了多長時間，需要鏈路監控工具來拆分時間。
不管用什麼工具和手段去拆分時間，我們的最終目的就是：得到每個環節消耗了多長時間。
五、構建分析決策樹
當我們拆分到了某個環節之後，我們就會知道時間消耗在了哪個節點上，接下來就需要：構建分析決策樹，找到問題的根本原因。
如圖所示，從壓力工具中，只需要知道 TPS、響應時間和錯誤率三條曲線，就可以明確判斷瓶頸是否存在。再通過分段分層策略，結合監控平臺、日誌平臺，或者其他的實時分析平臺，知道架構中的哪個環節有問題，然後再根據更細化的架構圖一一拆解下去。比如，定位到資料庫有問題，那麼就要針對資料庫進行進一步的決策樹拆解。
這個環節是最重要也是最難的一環。
所以，隨著效能分析經驗的累加，我們需要整理並總結每次遇到的效能問題以及相對應的解決方法，逐步構建自己的分析決策樹。
同時我們還要不斷擴充自己的知識庫：系統架構、作業系統、資料庫、快取、路由等等，並將這些知識與經驗結合起來。重新梳理，由大到小，由巨集觀到細節，去畫出自己的分析決策樹。
再總結一下決策樹：它是對架構的梳理，是對系統的梳理，是對問題的梳理，是對查詢證據鏈過程的梳理，是對分析思路的梳理。它起的是縱觀全域性，高屋建瓴的指導作用。
六、場景的比對
當你覺得系統中哪個環節不行的時候，作為小白又沒能力分析它，你可以直接做該環節的增加，然後比對增加後的效果。
舉例，現在有個架構：
對應的測試結果是這樣的：
從 TPS 曲線中，我們可以明顯看到系統是有瓶頸的，但是並不知道在哪裡。
好在系統架構簡單，那麼我就先嚐試在某環節上加上一臺伺服器，比如：
對增加後的進行測試，結果發現沒變。
繼續增加其他節點：
這時候，TPS跟著上去了。
這就是場景比對。但是，侷限也很大：只適用架構並不複雜的系統。
七、總結
快速瞭解了分析中的各個主要環節要做的事情和注意的點。而這裡的每一個環節，又有非常多的細分，特別是構建分析決策樹這一塊，它需要太多的架構知識、系統知識、資料庫知識等等。
對於我這種小白來說，是打開了思路，後續要做的就是實踐的積累和知識的補充。
本文參考：
高樓老師 效能測試實戰30講