一次效能壓測及分析調優實踐

【關鍵導讀】
結合一次重保活動的效能壓測需求，詳解了整體的效能測試策略及效能分析思路，並在實施過程中有效利用了NPT效能測試平臺完成了壓測場景設計、執行、業務指標監控、效能指標分析，結合監控找出了效能瓶頸並給出了相應的效能優化解決方案

0.背景說明

A業務有大促活動，對B業務有依賴，要求B業務對於X場景能夠持續穩定支撐1.4w TPS 5min， 如此要對B業務進行效能壓測，完成對應的效能需求。

1.效能測試策略

如下所示，接下來按照這個思路去分析下整個效能測試實踐的流程。

1.1 效能需求指標

容量指標：X場景支撐1.4W TPS 持續5min

1.2 效能模型建立

【業務模型】
涉及的場景包含A-》B-》C-》D共4個介面，按照真實業務分析流量比例為3:1:1:1
【監控模型】
監控物件
– 測試活動中的所有伺服器，測試機、應用伺服器、資料庫伺服器、快取伺服器、依賴服務等資源監控
– 所有被測的應用服務監控，Nginx、tomcat、MySQL等。

監控內容
業務指標：吞吐量、響應時間、失敗率
資源監控：CPU、記憶體、磁碟、網路、IO
日誌資訊：錯誤、異常、關鍵業務日誌
程式監控：CPU、記憶體、程式狀態、執行緒狀態
一個典型的linux 效能監控工具圖：

1.3 效能方案設計

測試環境：線上真實業務叢集
測試資料：場景是從客戶端APP發起呼叫介面，考慮到線上資料樣本不涉及隱私及敏感資料且可以複用，不會對使用者造成資料汙染。故從線上撈取了100萬使用者資料樣本。
壓力策略：
1）先摸高，按照一定的執行緒遞增策略，根據預期目標是否有效能瓶頸
2）峰值容量持續壓測，觀察系統的承受及處理能力

2.效能測試執行及分析

利用NPT效能壓測平臺完成整個效能壓測活動https://www.163yun.com/product/npt?fromyice=M_testerhome_25016

2.1 容量場景：TPS摸高

經過壓測在NPT平臺中壓測後的TPS-RT曲線如下

接下來按照效能分析的典型思路給大家逐一介紹下：

【瓶頸的精準判斷】
很多情況下，在分析系統效能瓶頸的時候，我們總是想找到效能瓶頸的那個“拐點”，但是實際上大部分系統其實是沒有明確的拐點的。在實際操作中需要按照固定遞增幅度增加併發執行緒數，進而對於TPS 的增加控制得更為精準，實際業務中TPS的增加是有一個有清晰的弧度，而不是有一個非常清晰的拐點。
從上圖業務真實TPS-RT曲線中可以做出以下判斷：線上程逐步遞增的過程中，TPS按照固定比例上升與執行緒數呈現線性增長，達到一定的壓力的情況下，TPS的增長幅度在衰減，最後逐步趨於平穩。以此可以判斷出業務在一定的壓力情形下出現了效能瓶頸。為了更加清晰判斷效能瓶頸，接下來分析下效能衰減的過程。
【效能衰減的過程】
所謂的效能衰減可以通過每執行緒每秒請求數在逐漸變少來反應，即使TPS仍在增加，如下針對壓測業務採用3個點，計算每執行緒每秒請求數

取樣點1：每執行緒每秒請求數=9547/270=35.3

取樣點2：每執行緒每秒請求數=13461/450=29.9

取樣點3：每執行緒每秒請求數=13773/495=27.8
由此可以得到如下結論
只要每執行緒每秒的請求數開始變少，就意味著效能瓶頸已經出現了。但是瓶頸出現之後，並不是說伺服器的處理能力（這裡我們用 TPS 來描述）會下降，應該說 TPS 仍然會上升，在效能不斷衰減的過程中，TPS 就會達到上限。
在這個場景的測試過程中，在效能瓶頸出現後，繼續保持遞增的壓力，讓瓶頸更為明顯，可以看如下TPS-RT的曲線，我們會更加清晰的看到壓力還在逐步增加，但TPS已經趨於平穩，而平均RT卻在不斷上升

【響應時間的拆分】
基於效能瓶頸的出現，接下來就需要分析在效能瓶頸出現時，哪個鏈路耗時增加明顯導致請求RT變長。那麼首先需要做的是畫出請求的整個業務鏈路。這裡的策略是：先粗後細，先從較粗的粒度劃分，確認耗時較長的鏈路節點，然後再細分粒度可能到某個方法。我們先來看一個典型的響應時間RT的分佈鏈路

響應時間 = (N1+N2+N3+N4)+(A1+A2+A3)，一般我們優先關注的是A1、A2、A3，對於網路傳輸處理，在這裡優先預設它表現良好
基於業務場景的鏈路：

第三方依賴服務採用了hystrix降級熔斷元件實現了獨立執行緒池隔離呼叫。
1）首先要排除發壓端是否有瓶頸，檢視發壓端伺服器監控，CPU利用率和負載都還不到10%

壓測機指標

2）分析下呼叫第三方依賴服務的平均RT，對比如下
單應用例項 20併發 平均rt 19.25
單應用例項 50併發 平均rt 38.25
由此看來在併發使用者數一直往上增時，呼叫第三方依賴服務RT上漲明顯，進而初步需要排查的是第三方依賴服務在大併發使用者數下的處理能力，併發使用者數增加，處理能力下降，導致RT邊長
這裡優先說下在第一輪效能壓測時發現的問題並調整，同樣是TPS摸高，從下圖可以看出TPS還未達到效能瓶頸時，已經出現失敗請求

經過分析呼叫第三方的執行緒池被打滿拋異常，採用的hystrix實現的業務降級熔斷，配置了獨立的執行緒池，執行緒池配置為核心和最大執行緒數為20，佇列為0
異常日誌：
Task java.util.concurrent.FutureTask@66339c68 rejected from java.util.concurrent.ThreadPoolExecutor@303bf923[Running, pool size = 20, active threads = 20, queued tasks = 0, completed tasks = 2071934]
程式碼實現配置如下，進而優化調整執行緒池，核心執行緒數和最大執行緒數都調整為50

【構建決策分析樹】

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

2.2 峰值穩定性壓測

效能壓測模型及場景設計

【效能分析】
針對precheck壓測恆定壓力1.4W 持續3min後，中間突然TPS陡增，初步分析是因為伺服器埠耗盡了，看了下TCP連線狀態，大量Time_wait，呼叫第三方依賴服務介面監控中可以看到對應時間點開始拋異常

峰值穩定性場景：TPS-RT曲線

TCP狀態監控

錯誤次數監控

連線異常堆疊資訊

看了下伺服器的相關配置，對於埠的回收、複用、超時都未進行優化配置

效能優化解決方案：
1）調整應用伺服器對於埠的回收、複用、超時進行優化配置
2）將B業務作為客戶端呼叫第三方依賴服務的連線改為長連線，避免短連線每次請求都會佔用一個埠
擴充套件延伸
幾種典型的異常波動：
• tps持續下降
• tps頻繁波動
• tps陡升陡降
• tps劇烈下降
在此感謝下一位效能測試專家-高樓的一些關於效能測試方向的總結思考，實踐過程中有借鑑其思路
【關鍵總結】
效能測試是針對系統的效能指標，建立效能測試模型，制定效能測試方案，制定監控策略，在場景條件之下執行效能場景，分析判斷效能瓶頸並調優，最終得出效能結果來評估系統的效能指標是否滿足既定值。