性能測試流程
一、文檔目的
- 幫助大家了解性能測試流程
- 提高性能測試意識,識別、排查性能隱患
- 完善公司性能測試流程
二、性能測試簡介
1、概念
模擬並發用戶訪問系統,根據監控的指標來評估系統的性能。
2、目的
- 驗證上線功能點是否滿足性能指標
- 找出服務器的承壓能力,作為優化和擴展的評估資料
- 減少宕機風險,提高用戶體驗
3、分類
類別 |
含義 |
壓力測試 |
模擬大量用戶向服務器產生負載,使服務器資源處於極限狀態並長時間運行 |
容量測試 |
一定用戶數,測試數據在不同數量級的情況下,系統承受的最佳容量 |
負載測試 |
測試服務器在滿足用戶要求的範圍內,能承載的最大用戶數 |
如上表格是根據不同的測試目的來劃分性能測試,我認為更簡單的概括應該是:前端性能和後端性能
前端性能:主要表現在頁面加載,一般會通過優化加載方式,減少數據傳輸量來進行。
後端性能:主要涉及到接口的處理邏輯優化、服務器參數配置、硬件資源消耗等。
三、性能需求
1、需求來源
性能需求一般是在需求評審會議上由產品、架構師、開發一起討論決定的,可以從以下兩個點來展開:
- 新系統
- 產品、架構師在前期需求調研時,預估出可能造成大並發的點(大量用戶同時請求,大量計算型任務、頻繁操作數據庫等場景);
- 舊系統
- 根據生產環境日誌(ELK),統計出高頻訪問接口(動態資源),以此確定對應的業務場景
- 線上曾經出現過性能問題的點,可作為參考
- 大型活動,例如搶紅包,直播,秒殺活動等
- 主觀感受,功能測試時請求時間較長的點
2、並發量
- 名詞解釋
TPS:服務器每秒處理的事務數,在大多數情況下和QPS可以等同;
並發數(VU):系統同時處理的請求/事務數
響應時間(RT):等於網絡傳輸時間+應用服務器處理時間+數據庫服務器處理時間,一般取90%時間
思考時間(TT):從業務角度來看,用戶在進行操作時,每次請求之間的時間間隔
- 計算公式
經常會遇到“設置多大並發用戶數合適”的問題,在沒有任何思考時間(TT)的情況下,這裏有個公式:
VU(並發壓測用戶數) = TPS(每秒執行事務數) × RT(響應時間)
TPS計算方法(兩種):
1、ELK中kibana組件可以實時統計出線上接口訪問情況,選取三個月內訪問量最大的一天,然後縮小時間範圍,精確到半小時以內,進而計算出每秒最大峰值訪問量
2、 以半年或者三個月為區間,提取某一天中接口的峰值訪問量,根據現網網卡的流量,分析一天中用戶的活躍時間段,然後采用二八原則(即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、接口文檔
在確定了具體的業務場景後,開發人員需要提供該業務的接口文檔,以便測試人員預估腳本的開發難度,準備測試數據等;
四、性能指標
- 響應時間,理想情況,單個接口響應時間低於1秒,最多不能超過3秒
- TPS是否達到預期值
- 事務成功率不能低於98%
- 服務器資源利用率
指標 |
閾值 |
備註 |
CPU |
<70% |
過高會導致系統服務不穩定 |
內存使用率 |
<70% |
同上 |
磁盤使用率 |
<70% |
同上 |
網絡帶寬 |
<70% |
過高會導致網絡延遲,響應時間變長 |
五、系統架構
後端性能測試是基於接口來進行,了解系統架構,有利於我們知道接口的處理邏輯、數據流向,大概知道哪些地方可能會有瓶頸,因此也會在相應的地方添加監控。
graph TD
A[客戶端]-->B[HTTP服務器]
B -->C[應用服務器]
C -->D[緩存]
D -->E[數據庫]
六、測試計劃
性能測試是一個團隊協作完成的項目,需要各個部門配合,因此在測試前充分溝通、做好排期非常重要。
任務 |
具體內容 |
責任人 |
開始時間 |
完成時間 |
目前進展 |
備註 |
測試方案 |
||||||
測試環境 |
||||||
測試數據 |
||||||
腳本開發 |
||||||
執行測試 |
||||||
分析調優 |
||||||
測試報告 |
七、測試方案
根據具體的需求分為單場景和混合場景,單場景主要是測試某個接口的性能極限,混合場景主要是更加仿真,盡最大可能模擬真實環境。
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小時以上)的穩定性測試,考察系統長期穩定運行情況。
八、評審
測試計劃、測試指標、測試方案需要拿出來讓各個部門共同討論決定,如果通過則可以進行下一步。
九、被測環境
1、環境要求
- 獨立
1、排除其他應用幹擾,防止資源競爭;最好是實體機,若是虛擬機需要保證壓測時,帶寬足夠,其他虛擬機最好停用。
2、壓測不能在生產上進行。
3、建立擋板,如若有涉及到外圍系統,可根據實際情況,考慮屏蔽或者使用mock接口來模擬
- 和生產環境架構、軟件版本保持一致
1、現實情況中,測試環境很難和線上配置保持一致,此時應當保持測試環境的架構和生產上一樣,再按照環境配置的比例大致估算出性能差異。配置比例一般以機器數量、CPU核數、內存數作為衡量指標;
參考公式:n =公倍數((生產環境web服務器/測試環境web服務器),(生產環境app服務器/測試環境app服務器))*(生產服務器內存/測試服務器內存)
2、服務器軟件版本和生產環境保持一致(nginx,tomcat,jdk,redis,mysql等)
- 壓測時限制條件去掉
1、為了模擬大並發,我們的請求全部都是從一臺機器上發送的,可能為了防止DDos攻擊,對訪問的IP的次數和頻率都有限制,此時應該從代碼層將限制去掉
2、短信、圖形驗證碼校驗需要屏蔽,(目前短信驗證通過工具無法繞過,簡單的圖形驗證可以通過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 |
... |
... |
... |
... |
|||
... |
|||||||
... |
|||||||
... |
九、壓力發起環境
1、壓力發起方式
- 使用工具來發送大量HTTP請求,如Jmeter,Loadrunner,Locust
- 依賴第三方的jar包或者庫,用Java或者Python編寫代碼
- 實時拷貝線上流量,借助於TCPCopy、gor等,將線上流量導入到被測環境中
2、機器配置
- 一臺機器的帶寬、最大文件句柄數都有系統級限制,為了能發起更大壓力,測試過程中可能需要多臺機器組建集群來同時施加壓力
壓測開始時中先使用一臺機器,如若壓測機cpu和內存被占滿、或者TPS上不去,則再考慮搭建集群,現在我們普遍用的配置是8核16G, windows2008操作系統。
- 機器應當盡量和被測環境在同一網段內,這樣才能避免因網絡延遲導致並發壓力上不去的狀況。
3、搭建環境
- 配置jdk
- 安裝jmeter及其插件
- 調整jvm參數
- 部署集群
十、測試賬號和數據
1、測試賬號
壓測過程就是模擬大量用戶訪問系統的行為,因此必然涉及到用戶登錄的問題,那麽就需要足夠的測試賬號。
避免只使用一個賬號來模擬多用戶,一個用戶發送多次請求和多個用戶發送一次請求,因為緩存的原因,對系統壓力是不一樣的。
2、服務器賬號
在了解系統架構後,為了監控服務器的各項指標,需要找運維同事申請服務器賬號(操作系統、數據庫、redis等),如若因為權限問題不能給到賬號,則需要運維同事幫忙看監控。
3、數據
- 測試數據
測試數據應當盡量模擬用戶的真實操作
舉例:用戶在論壇發帖,假設發帖的字數平均在100字左右,但是腳本中發送的卻只有10個字,那麽在數據傳輸過程中,對帶寬以及數據庫存儲空間的消耗是不一樣的。
腳本模擬的是多個用戶的操作,因此對於有些參數不是唯一的,就不應該寫死,而需要動態傳入不同的值
舉例:模擬用戶瀏覽帖子的接口(http://bbs.feidee.com/thread-718207-1-1.html),718207是帖子ID,
因為每個用戶看的帖可能不一樣,且社區帖子有很多個,那麽此處每次請求的參數應該是不同的帖子ID,可提前在數據庫中將帖子ID導出到本地文件中,然後每次請求時依次讀取。
- 數據庫數據
數據庫中應該用足夠的數據,避免“空庫測性能”,可依據生產環境中的數據存量按照一定的縮小比例來決定數據量。
十一、測試腳本
分析完壓測需求後,拿到對應的壓測接口文檔,根據對應的Url、參數,通過工具來模擬大量用戶發送請求;本文中以jmeter舉例;
- 搭建jmeter運行環境
- 部署分布式壓測集群
- 設置並發線程、腳本運行時間
- 使用jmeter發送http請求
- 添加監聽器(聚合報告、TPS)
- 調試接口
- 腳本試運行。
註:接口調試成功後,可以設置多個線程,運行時間設置為5分鐘,打開查看結果樹,運行腳本,看是否有報錯。沒有的話則壓測腳本編寫完成。
十二、服務端監控項
在實際壓測過程中,因測試人員沒有權限的問題,很多監控項是需要運維、DBA同事來協助,因此這個環節需要大量的溝通工作。
1、服務器硬件資源
1、使用監控系統:Zabbix,Cacti,NMON, jmeter-Agent,監控cpu,內存,IO,網絡等使用情況
2、使用命令行,top,iostat ,vmstat,sar
前端nginx作為高性能的反向代理服務器,一般很少有瓶頸,故此處不加監控
2、應用
1、tomcat連接池配置
2、jvm堆內存使用情況,fullGC次數以及時間
3、部署jvisualvm或者jprofiler
3、數據庫
1、慢sql
2、緩存命中率
3、全表掃描數
4、連接數
4、緩存
1、內存使用率
2、命令處理數
3、慢命令
4、連接數
十三、執行測試
運行測試腳本, 實時觀察聚合報告,如若出現大量錯誤,需要立即停止,並分析原因,重新調試;
特殊情況下,有些壓測時間需要在淩晨進行,那麽可以借助於jmeter的調度器定時啟動腳本;
十四、結果分析、調優
將測試結果與用戶預期指標進行對比,如果達到則測試通過;如果達不到,則需要提交bug,並進一步分析原因,待開發修復後,重新執行測試,直到符合指標為止。
1、接口響應時間
從jmeter的聚合報告中看平均時間和90%響應時間
2、 TPS
1、jmeter聚合報告中的吞吐量
2、jmeter插件:Transactions per Second 看TPS的走勢
3、服務端資源利用率
從Zabbix監控上看服務器的資源利用率(包括應用、數據庫、緩存)
4、事務成功率
從聚合報告上看各個接口的錯誤率,不能超過2%
5、分析步驟
- 如果響應時間過長,那麽可以按照下面的思路逐步分析:
1、查看tomcat和nginx日誌,如有報錯,分析錯誤原因
2、網絡原因,用sar命令或者Zabbix監控查看網絡出口、入口流量,排查是否是網絡延遲
3、查看數據庫慢sql日誌,看是否有耗時較長的sql
4、查看redis慢命令以及命令處理數,看是否有耗時較長的命令
5、查看jvm使用情況,看是否有fullGC情況
6、查看tomcat與nginx、redis、mysql的連接數是否設置足夠
7、使用jvisualvm、jprofiler的熱點分析(或者線程dump),找出耗時最長的代碼
8、各個服務器硬件資源是否達到瓶頸
- 如果TPS上不去:
1、壓測機的資源消耗情況
2、查看壓測環境jmeter堆內存設置、最大文件句柄數
3、聚合報告中帶寬消耗是否達到瓶頸
4、考慮搭建集群
6、常見性能問題
1、數據庫過多調用
2、數據庫資源泄露
3、連接池太小
4、sql未加索引、鎖表
5、寫log影響IO性能
6、jvm參數設置不合理
7、服務端未啟用長連接
十五、性能測試流程
十六、測試報告
1、測試結論
根據結果分析的結論,得出此次壓測是否滿足用戶預期指標。
性能測試采用的測試策略是:在測試環境用腳本模擬用戶的操作,進而向服務器發起壓力,預估是否有性能問題。即使各個測試環節都正確,也和正式環境上用戶行為有一定誤差,因此很多情況下,測試結果只能作為參考,不能完全作為依據。
2、輸出報告
將以上性能測試的全流程(包括壓測結果、相應服務器截圖、發現的性能bug、遇到的問題)整理好文檔後,用郵件的方式發送給相對應開發、產品、運維、DBA、測試,並抄送上級領導。
性能測試流程