性能測試流程

 

1、文檔目的

• 幫助你們瞭解性能測試流程
• 提升性能測試意識，識別、排查性能隱患
• 完善公司性能測試流程

2、性能測試簡介

1、概念

模擬併發用戶訪問系統，根據監控的指標來評估系統的性能。

2、目的

• 驗證上線功能點是否知足性能指標
• 找出服務器的承壓能力，做爲優化和擴展的評估資料
• 減小宕機風險，提升用戶體驗

3、分類

類別	含義
壓力測試	模擬大量用戶向服務器產生負載，使服務器資源處於極限狀態並長時間運行
容量測試	必定用戶數，測試數據在不一樣數量級的狀況下，系統承受的最佳容量
負載測試	測試服務器在知足用戶要求的範圍內，能承載的最大用戶數

如上表格是根據不一樣的測試目的來劃分性能測試，我認爲更簡單的歸納應該是：前端性能和後端性能

前端性能：主要表如今頁面加載，通常會經過優化加載方式，減小數據傳輸量來進行。

後端性能：主要涉及到接口的處理邏輯優化、服務器參數配置、硬件資源消耗等。

3、性能需求

1、需求來源

性能需求通常是在需求評審會議上由產品、架構師、開發一塊兒討論決定的，能夠從如下兩個點來展開：

• 新系統
• 產品、架構師在前期需求調研時，預估出可能形成大併發的點（大量用戶同時請求，大量計算型任務、頻繁操做數據庫等場景）；
• 舊系統
• 根據生產環境日誌（ELK），統計出高頻訪問接口（動態資源），以此肯定對應的業務場景
• 線上曾經出現過性能問題的點，可做爲參考
• 大型活動，例如搶紅包，直播，秒殺活動等
• 主觀感覺，功能測試時請求時間較長的點

2、併發量

• 名詞解釋

TPS：服務器每秒處理的事務數，在大多數狀況下和QPS能夠等同；

併發數（VU）：系統同時處理的請求/事務數

響應時間（RT）：等於網絡傳輸時間+應用服務器處理時間+數據庫服務器處理時間，通常取90%時間

思考時間（TT）：從業務角度來看，用戶在進行操做時，每次請求之間的時間間隔

• 計算公式

常常會遇到「設置多大併發用戶數合適」的問題，在沒有任何思考時間（TT）的狀況下，這裏有個公式：

VU（併發壓測用戶數） = TPS（每秒執行事務數） × RT（響應時間）

TPS計算方法（兩種）：

一、ELK中kibana組件能夠實時統計出線上接口訪問狀況，選取三個月內訪問量最大的一天，而後縮小時間範圍，精確到半小時之內，進而計算出每秒最大峯值訪問量

二、 以半年或者三個月爲區間，提取某一天中接口的峯值訪問量，根據現網網卡的流量，分析一天中用戶的活躍時間段，而後採用二八原則（即80%的訪問是在20%的時間內完成），隨後計算出每秒的訪問量，即TPS

舉例：

假設理財社區半年內瀏覽帖子的日訪問量峯值是500萬（從日誌中提取）；

現網網卡流量來看，天天社區活躍時間區間爲早上八點到晚上十點（08:00-22:00），共計14小時。

根據二八原則，400萬（500*80%）的訪問量是在2.8小時（14*0.2）內完成的，轉化成秒，

即TPS = 4000000/（2.8*3600) = 396

假設用戶每次打開帖子的響應時間是2秒，那麼此時併發數爲792

注：實際測試過程當中，爲了模擬更多用戶，會在腳本中加大思考時間，這樣獲得的併發用戶數就會變大，也更加仿真。

第一種方法更爲精確（推薦使用），第二種可能會有必定偏差。

3、接口文檔

在肯定了具體的業務場景後，開發人員須要提供該業務的接口文檔，以便測試人員預估腳本的開發難度，準備測試數據等；

4、性能指標

• 響應時間，理想狀況，單個接口響應時間低於1秒，最多不能超過3秒
• TPS是否達到預期值
• 事務成功率不能低於98%
• 服務器資源利用率

指標	閾值	備註
CPU	<70%	太高會致使系統服務不穩定
內存使用率	<70%	同上
磁盤使用率	<70%	同上
網絡帶寬	<70%	太高會致使網絡延遲，響應時間變長

5、系統架構

後端性能測試是基於接口來進行，瞭解系統架構，有利於咱們知道接口的處理邏輯、數據流向，大概知道哪些地方可能會有瓶頸，所以也會在相應的地方添加監控。

graph TD

    A[客戶端]-->B[HTTP服務器]

    B -->C[應用服務器]

    C -->D[緩存]

    D -->E[數據庫]

6、測試計劃

性能測試是一個團隊協做完成的項目，須要各個部門配合，所以在測試前充分溝通、作好排期很是重要。

任務	具體內容	責任人	開始時間	完成時間	目前進展	備註
測試方案
測試環境
測試數據
腳本開發
執行測試
分析調優
測試報告

7、測試方案

根據具體的需求分爲單場景和混合場景，單場景主要是測試某個接口的性能極限，混合場景主要是更加仿真，盡最大可能模擬真實環境。

1、單場景

對單個業務場景進行基準測試，採用壓力逐步遞增的方式，找到性能拐點。

舉例：

場景	併發數	加壓時間（分）	平均時間（秒）	90%時間（秒）	TPS
瀏覽帖子	10	10	1	1.5	10
瀏覽帖子	20	10
瀏覽帖子	30

2、混合場景

對全部業務場景進行階梯式壓力發起，獲得最佳處理能力（須要保持背景壓力和實時業務壓力不變）。

舉例：

場景	併發數	加壓時間（分）	平均時間（秒）	90%時間（秒）	TPS
瀏覽帖子	10	10	1	1.5	10
發帖	20	10
回覆帖子	20

舉例：一個系統除了瀏覽帖子這個場景外，還有其餘的訪問壓力（發帖，回帖），在逐步對瀏覽帖子這個場景施壓的時候，須要把其餘的壓力加上

3、穩定性測試

以混合場景，平常交易量的壓力對系統進行長時間（24小時以上）的穩定性測試，考察系統長期穩定運行狀況。

8、評審

測試計劃、測試指標、測試方案須要拿出來讓各個部門共同討論決定，若是經過則能夠進行下一步。

9、被測環境

1、環境要求

• 獨立

一、排除其餘應用干擾，防止資源競爭；最好是實體機，如果虛擬機須要保證壓測時，帶寬足夠，其餘虛擬機最好停用。

 

二、壓測不能在生產上進行。

 

三、創建擋板，如如有涉及到外圍系統，可根據實際狀況，考慮屏蔽或者使用mock接口來模擬

• 和生產環境架構、軟件版本保持一致

一、現實狀況中，測試環境很難和線上配置保持一致，此時應當保持測試環境的架構和生產上同樣，再按照環境配置的比例大體估算出性能差別。配置比例通常以機器數量、CPU核數、內存數做爲衡量指標；

 

 參考公式:n =公倍數（（生產環境web服務器/測試環境web服務器），（生產環境app服務器/測試環境app服務器））*（生產服務器內存/測試服務器內存）

 

二、服務器軟件版本和生產環境保持一致（nginx,tomcat,jdk,redis,mysql等）

• 壓測時限制條件去掉

一、爲了模擬大併發，咱們的請求所有都是從一臺機器上發送的，可能爲了防止DDos攻擊，對訪問的IP的次數和頻率都有限制，此時應該從代碼層將限制去掉

二、短信、圖形驗證碼校驗須要屏蔽，（目前短信驗證經過工具沒法繞過，簡單的圖形驗證能夠經過OCR技術識別，複雜的可藉助於深度學習）

2、部署環境

須要開發、運維、DBA協助來進行，部署最新的代碼（功能測試經過後的），並加上相應監控項。

3、環境清單

須要從運維那裏拿到生產環境和測試環境的配置信息。

舉例：

IP	機器用途	操做系統	軟件版本	機房	配置
192.168.1.100	數據庫	centos	mysql5.6	北京	CPU: E5-2620 2.0GHz 6核 *2 \	內存：8*24G \	硬盤：8*300G
192.168.1.101	...	...	...	...
...
...
...

9、壓力發起環境

1、壓力發起方式

• 使用工具來發送大量HTTP請求，如Jmeter，Loadrunner，Locust
• 依賴第三方的jar包或者庫，用Java或者Python編寫代碼
• 實時拷貝線上流量，藉助於TCPCopy、gor等，將線上流量導入到被測環境中

2、機器配置

• 一臺機器的帶寬、最大文件句柄數都有系統級限制，爲了能發起更大壓力，測試過程當中可能須要多臺機器組建集羣來同時施加壓力

壓測開始時中先使用一臺機器，如若壓測機cpu和內存被佔滿、或者TPS上不去，則再考慮搭建集羣，如今咱們廣泛用的配置是8核16G， windows2008操做系統。

• 機器應當儘可能和被測環境在同一網段內，這樣才能避免因網絡延遲致使併發壓力上不去的情況。

3、搭建環境

• 配置jdk
• 安裝jmeter及其插件
• 調整jvm參數
• 部署集羣

10、測試帳號和數據

1、測試帳號

壓測過程就是模擬大量用戶訪問系統的行爲，所以必然涉及到用戶登陸的問題，那麼就須要足夠的測試帳號。

避免只使用一個帳號來模擬多用戶，一個用戶發送屢次請求和多個用戶發送一次請求，由於緩存的緣由，對系統壓力是不同的。

2、服務器帳號

在瞭解系統架構後，爲了監控服務器的各項指標，須要找運維同事申請服務器帳號（操做系統、數據庫、redis等），如若由於權限問題不能給到帳號，則須要運維同事幫忙看監控。

3、數據

• 測試數據

測試數據應當儘可能模擬用戶的真實操做

舉例：用戶在論壇發帖，假設發帖的字數平均在100字左右，可是腳本中發送的卻只有10個字，那麼在數據傳輸過程當中，對帶寬以及數據庫存儲空間的消耗是不同的。

腳本模擬的是多個用戶的操做，所以對於有些參數不是惟一的，就不該該寫死，而須要動態傳入不一樣的值

舉例：模擬用戶瀏覽帖子的接口（http://bbs.feidee.com/thread-718207-1-1.html），718207是帖子ID，

由於每一個用戶看的帖可能不同，且社區帖子有不少個，那麼此處每次請求的參數應該是不一樣的帖子ID，可提早在數據庫中將帖子ID導出到本地文件中，而後每次請求時依次讀取。

• 數據庫數據

數據庫中應該用足夠的數據，避免「空庫測性能」，可依據生產環境中的數據存量按照必定的縮小比例來決定數據量。

11、測試腳本

分析完壓測需求後，拿到對應的壓測接口文檔，根據對應的Url、參數，經過工具來模擬大量用戶發送請求；本文中以jmeter舉例；

• 搭建jmeter運行環境
• 部署分佈式壓測集羣
• 設置併發線程、腳本運行時間
• 使用jmeter發送http請求
• 添加監聽器（聚合報告、TPS）
• 調試接口
• 腳本試運行。

注：接口調試成功後，能夠設置多個線程，運行時間設置爲5分鐘，打開查看結果樹，運行腳本，看是否有報錯。沒有的話則壓測腳本編寫完成。

12、服務端監控項

在實際壓測過程當中，因測試人員沒有權限的問題，不少監控項是須要運維、DBA同事來協助，所以這個環節須要大量的溝通工做。

1、服務器硬件資源

一、使用監控系統:Zabbix，Cacti，NMON, jmeter-Agent，監控cpu，內存，IO，網絡等使用狀況

二、使用命令行，top,iostat ,vmstat，sar

前端nginx做爲高性能的反向代理服務器，通常不多有瓶頸，故此處不加監控

2、應用

一、tomcat鏈接池配置

二、jvm堆內存使用狀況，fullGC次數以及時間

三、部署jvisualvm或者jprofiler

3、數據庫

一、慢sql

二、緩存命中率

三、全表掃描數

四、鏈接數

4、緩存

一、內存使用率

二、命令處理數

三、慢命令

四、鏈接數

十3、執行測試

運行測試腳本， 實時觀察聚合報告，如若出現大量錯誤，須要當即中止，並分析緣由，從新調試；
特殊狀況下，有些壓測時間須要在凌晨進行，那麼能夠藉助於jmeter的調度器定時啓動腳本；

十4、結果分析、調優

將測試結果與用戶預期指標進行對比，若是達到則測試經過；若是達不到，則須要提交bug，並進一步分析緣由，待開發修復後，從新執行測試，直到符合指標爲止。

1、接口響應時間

從jmeter的聚合報告中看平均時間和90%響應時間

2、 TPS

一、jmeter聚合報告中的吞吐量

 

二、jmeter插件：Transactions per Second 看TPS的走勢

3、服務端資源利用率

從Zabbix監控上看服務器的資源利用率（包括應用、數據庫、緩存）

4、事務成功率

從聚合報告上看各個接口的錯誤率，不能超過2%

5、分析步驟

• 若是響應時間過長，那麼能夠按照下面的思路逐步分析：

一、查看tomcat和nginx日誌，若有報錯，分析錯誤緣由

 

二、網絡緣由，用sar命令或者Zabbix監控查看網絡出口、入口流量，排查是不是網絡延遲

 

三、查看數據庫慢sql日誌，看是否有耗時較長的sql

 

四、查看redis慢命令以及命令處理數，看是否有耗時較長的命令

 

五、查看jvm使用狀況，看是否有fullGC狀況

 

六、查看tomcat與nginx、redis、mysql的鏈接數是否設置足夠

 

七、使用jvisualvm、jprofiler的熱點分析（或者線程dump），找出耗時最長的代碼

 

八、各個服務器硬件資源是否達到瓶頸

• 若是TPS上不去：

一、壓測機的資源消耗狀況

 

二、查看壓測環境jmeter堆內存設置、最大文件句柄數

 

三、聚合報告中帶寬消耗是否達到瓶頸

 

四、考慮搭建集羣

6、常見性能問題

一、數據庫過多調用

二、數據庫資源泄露

三、鏈接池過小

四、sql未加索引、鎖表

五、寫log影響IO性能

六、jvm參數設置不合理

七、服務端未啓用長鏈接

十5、性能測試流程

 

十6、測試報告

1、測試結論

根據結果分析的結論，得出這次壓測是否知足用戶預期指標。

性能測試採用的測試策略是：在測試環境用腳本模擬用戶的操做，進而向服務器發起壓力，預估是否有性能問題。即便各個測試環節都正確，也和正式環境上用戶行爲有必定偏差，所以不少狀況下，測試結果只能做爲參考，不能徹底做爲依據。

2、輸出報告

將以上性能測試的全流程（包括壓測結果、相應服務器截圖、發現的性能bug、遇到的問題）整理好文檔後，用郵件的方式發送給相對應開發、產品、運維、DBA、測試，並抄送上級領導。