【關鍵導讀】結合一次重保活動的性能壓測需求，詳解了整體的性能測試策略及性能分析思路，并在實施過程中有效利用了網易易測的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性能壓測平臺完成整個性能壓測活動

易測NPT_性能壓測_一站式測試解決方案-網易數帆?www.163yun.com

2.1 容量場景：TPS摸高

性能壓測模型及場景設計

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

容量場景：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業務作為客戶端調用第三方依賴服務的連接改為長連接，避免短連接每次請求都會占用一個端口

3. 一站式性能測試解決方案

網易易測團隊通過調研各種類型的性能測試工具和多年的技術沉淀及總結，結合大數據技術開發出性能測試平臺。平臺提供一站式的性能測試服務，全面提升被測系統的性能和測試效率。

易測NPT_性能壓測_一站式測試解決方案-網易數帆?www.163yun.com

平臺主要功能架構如下

網易性能測試平臺具備強大的中臺管理能力，支持多樣化的性能場景構建，同時支持所有的測試腳本和數據的上傳、下發均通過平臺進行，做到了測試用例的集中化管理，降低了性能測試人員的溝通成本，極大程度的提升了分布式壓測前期準備效率；強化后的壓測引擎具備瞬間高并發能力，能夠快速的獲取被測系統的性能指標，發現性能瓶頸；數據處理中心提供實時的、多維度性能測試報告，性能測試問題提前發現，提前解決，縮短了性能優化周期；測試管理為多產品、多子系統和多人協作提供了途徑，測試任務的復用減少了測試腳本編寫的次數，提高了性能測試效率。

在網易集團內部全覆蓋互聯網業務，如網易云音樂、網易嚴選、網易新聞等；平臺完美支撐了業務需求的六大典型場景

六大典型場景

平臺提供了多樣化性能場景構建，百萬TPS發壓，實時性能數據采集及指標智能分析等能力，并配置了網易一線性能測試專家提供在線支持

百萬TPS發壓能力支持

【關鍵總結】性能測試是針對系統的性能指標，建立性能測試模型，制定性能測試方案，制定監控策略，在場景條件之下執行性能場景，分析判斷性能瓶頸并調優，最終得出性能結果來評估系統的性能指標是否滿足既定值。

總結

以上是生活随笔為你收集整理的tcp压测工具_【解决方案】性能压测及分析调优实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。