性能測試學習總結

 

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

一、性能測試中的指標

所有的技術指標都是在有業務場景的前提下制定的。

技術指標和業務指標之間也要有詳細的換算過程。

舉個例子：

論壇主要有以下幾個功能點：註冊、登錄、發貼、瀏覽貼子、管理員可以單個或者多個的刪除帖子，部分用戶發貼需要經過審覈才能在前臺展現；

1. 我們10萬的活躍用戶，每天線在用戶數約爲1W， 75%的用戶瀏覽帖子(平均5個帖子)並回復（2次），20%的用戶會發貼（1個帖子）；並且以每個月5%的速度在增長；

2. 我們有30個各版塊的管理員，每天80%的管理員負責審覈貼子（平均每天20個），15%的管理員負責冊除不符合要求或者過時的帖子（平均每人刪除3個） ；

3. 用戶發貼的思考時間在5S~60S之間浮動，審覈帖子的思考時間在 5S~20S之間浮動；每天晚上8時至12時是用戶使用高峯期，早上9時 至10時是管理員審貼的高峯；

換算如下

 

 

1.1 業務指標

所有的技術指標都是在有業務場景的前提下制定的

性能指標表示法

 

1.2 技術指標

1.2.1 時間指標

RT-響應時間：

接口/業務響應時間-從發起請求到接收到響應的時間。

1.2.2 容量指標

• 接口容量

接口的容量通常使用TPS/RPS來描述。

• 業務容量

業務量通常由TPS指標來描述，即系統每秒能夠處理的業務量。

1.2.3 資源利用率指標

1.2.3.1 操作系統

CPU

top         #查看CPU佔用進程排名
vmstat   
top -Hp pid   #查看進程中的線程cpu使用率
等

IO

iotop    #查看I/O進程排名
iostat   #查看磁盤的I/O狀態
lsof     # 查看系統或進程打開的文件列表
等

Mem

cat /proc/meminfo   #查看內存使用情況
free   #查看內存使用
等

Disk

df  #查看磁盤使用情況（能看到一些已經刪除的文件計算大小也會算進去）
du  #查看目錄大小
等

NetWork

netstat      #(網絡統計)命令顯示連接信息,路由表信息等
traceroute   #路由跟蹤命令
ifconfig     #查看當前主機的ip地址和網卡信息
ping         #測試網絡的連通性
等

1.2.3.2 JVM

GC

Classes

。。。

jvm相關的命令
https://blog.csdn.net/u012002125/article/details/108449389

二、性能測試中的模型

在性能測試中，模型是對真實業務測試場景的抽象，用來描繪應用系統真實業務模型的樣子。

舉個例子，系統有 10 種業務場景，但並不是每個業務都需要有併發量，可能只有 5 個業務有，那就要把這些有併發的業務統計出來，哪個業務併發多，哪個業務併發少，做壓力時就要控制好這樣的比例。

獲取用戶行爲模式的方法：

• 1、如果系統已經上線運行，則採用系統日誌分析法獲取用戶行爲統計和峯值併發量等重要信息；

• 2、對於一個全新系統來說，通常是參考行業中類似系統的統計信息進行分析和建模。

三、性能測試中的方案

方案規定的內容中有幾個關鍵點，分別是測試環境、測試數據、測試模型、性能指標、壓力策略、准入準出和進度風險。

• 測試環境：

1、測試環境需要儘量做到與線上環境配置保持一致，否則測試沒有實際意義（不能反饋線上問題）

2、在大規模分佈式系統中如果無法做到以生產一致，則需要分析線上環境與測試環境的差異，通過計算得到相關的比值

• 測試數據：

測試數據需要根據用戶行爲模型以及當前系統的數據總量及分佈批量生成

• 測試模型：

測試模型即相關的測試場景

• 性能指標：

響應時間

併發用戶數

吞吐量

• 壓力策略：

測試中用戶的添加策略（如每隔1秒添加20個用戶）

• 准入準出標準：

即系統需要通過功能測試之後才能做壓力測試

壓力測試系統相關的指標達到需求標準後即可完成測試

• 進度風險：

反饋測試過程中發現的潛在系統風險，如壓測環境與線上環境差別較大、某一項系統指標出現異常

四、性能測試中的監控

性能測試中需要有系統監控，系統監控要有分層、分段的能力，既要有全局監控也要有定向監控的能力。

 

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

1、工具操作：包括壓力工具、監控工具、剖析工具、調試工具。

2、數值理解：包括上面工具中所有輸出的數據。

3、趨勢分析、相關性分析、證據鏈分析：就是理解了工具產生的數值之後，還要把它們的邏輯關係想明白。這纔是性能測試分析中最重要的一環。

4、最後纔是調優：有了第 3 步之後，調優的方案策略就有很多種了，具體選擇取決於調優成本和產生的效果

性能分析思路：

1、瓶頸的精準判斷

1.1 TPS曲線

• 當增加壓力tps的遞增比之前要小，響應時間卻在增加的時候，瓶頸可能就出現了。

• 通過TPS曲線可以判斷系統是否存在瓶頸，瓶頸是否和嚴厲有關係，若通過不斷增加壓力 tps都會出現相同的趨勢時，瓶頸就和壓力無關，否則就是有關係。

1.2 響應時間曲線

• ttps曲線纔是用來判斷系統是否有瓶頸的，響應時間只是用來描述業務的快慢。

2、線程遞增的策略

• 壓力的遞增策略必須符合實際業務場景，即使是在秒殺場景中壓力也是遞增的不會一開始就上全部併發線程。

• 在做系統壓力測試中，僅在改變壓力策略（其他的條件比如環境、數據、軟硬件配置等都不變）的情況下，系統的最大 TPS 上限一般來時是固定的。

• 在遞增策略測試過程中，若每次增加壓力tps都會出現抖動的情況，則有可能是以下兩種可能：1、資源的動態分配不合理，如後端線程池、內存、緩存等；2、測試沒有進行數據預熱。

3、性能衰減的過程

• 當每一線程每秒的 TPS 開始變少時（總的tps還在增加），說明性能瓶頸已經出現了

• 當系統瓶頸出現後，系統的處理能力（TPS）並不會馬上下降，TPS依舊會緩慢增加，此時系統性能正在衰減，tps最終達到上限。

4、響應時間的拆分

• 在系統壓力測試過程中，當系統達到了瓶頸，再持續增加壓力，響應時間就一定會上升，直到超時爲止。

• 

   

 

• 拆分響應時間是爲了進一步確認時間主要消耗在哪個模塊。

• 在分佈式應用系統中建議使用鏈路的監控工具來拆分時間。

5、構建分析決策樹

• 構建分析決策樹是對系統架構的梳理，是對系統的梳理，是對問題的梳理，是對查找證據鏈過程的梳理，是分析思路的梳理。

• 分析決策樹起到的是縱觀全局，高屋建瓴的指導作用。

• 

   

 

其中RDBMS 中的 MySQL的決策樹如下：

 

操作系統的分析決策樹如下：

 

• 分析決策樹的目的是爲了找出系統出現系統瓶頸的最終原因。

• 分析決策樹幫助我們在分析系統瓶頸時提供證據鏈查找思路。

• 性能測試的最終目的是發現造成系統瓶頸的問題點，並能通過各種手段進行優化是系統處於最優狀態。

6、場景的比對。

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

• 可以通過增加其中一臺應用服務器或者增加壓力機的方式，通過對比測試結果定位問題。

五、性能測試中的場景

基準性能場景：這裏要做的是單交易的容量，爲混合容量做準備。

容量性能場景：確定系統可處理同時在線的最大用戶數，使系統承受超額的數據容量來發現它是否能夠正確處理。

穩定性性能場景：穩定性測試必然是性能場景的一個分類。在穩定性測試中，顯然最核心的元素是時間（業務模型已經在容量場景中確定了），而時間的設置應該來自於運維週期，而不是來自於老闆、產品和架構等這些人的心理安全感。

異常性能場景：要做異常性能場景，前提就是要有壓力。在壓力流量之下，模擬異常。

六、性能測試中的分析調優

• 性能項目分類

新系統性能測試類：

新的項目經常需要測試出系統的最大容量，系統上線能抗住多少併發訪問，上線前還需要將系統調至最優狀態。

對與已經在線運行的系統：一般都是和舊版本做性能對比，保證新版班性能不會低於歷史版本，對調優要求一般都不大。

七、性能測試中的結果報告

在性能測試報告中應該着重體現一下兩點：

1、性能測試的結果（是否存在瓶頸，如果存在導致存在的瓶頸的問題是什麼）、是否滿足發版需求

2、調優前後的 TPS、響應時間以及資源對比圖。

八、總結

注：部分內容參考極客時間《性能測試實戰30講》專欄

歡迎大家關注我的訂閱號，會定期分享一些關於測試相關的文章，有問題也歡迎一起討論學習！訂閱號每一條留言都會回覆！