中國軟件評測中心將性能測試歸納爲三個方面:應用在客戶端性能的測試、應用在網絡上性能的測試、應用在服務器端性能的測試。歸納起來也就是:客戶端、網絡端、服務端html
客戶端就是壓力機;當進行壓力時須要監控客戶端、網絡端、服務端的數據。數據庫
l 負載測試瀏覽器
l 壓力測試緩存
l 疲勞強度測試服務器
負載測試:主要指的是模擬系統在正常負載壓力場景下,考察系統的性能指標。這裏說的正常負載,主要是指預計系統最大應該支持多大用戶的併發量。經過負載測試,目的是驗證系統是否能知足預期的業務壓力場景。網絡
壓力測試:在不斷增長併發壓力下系統的性能會變得不可接受,出現性能崩潰的狀況,計算出這時的併發值。在加壓策略上,壓力測試會對被測系統逐步加壓,在加壓的過程當中考察系統性能指標的走勢狀況,最終找出系統在出現性能拐點時的併發用戶數,也就是系統支持的最大併發用戶數。多線程
疲勞強度測試:模擬出長時間系統能承受的最大業務負載量。差別在於前二者,疲勞強度測試更關注系統在長時間運行下性能指標的變化狀況。例如,系統在運行一段時間後,是否會出現事務處理失敗、響應時間增加、業務吞吐量下降、CPU/內存資源增加等問題。併發
從維度上劃分,性能指標主要分爲兩大類,分別是業務性能指標和系統資源性能指標分佈式
如下的性能指標是經常使用的指標,隨着對性能要求的提高,須要觀察其餘更詳細的數據,好比:其壓力機和服務器的硬件也會影響性能工具
性能的最總目的:在保證必定的成功率、響應時間的前提下獲得業務須要的最大併發數
併發用戶數:壓力機模擬同時訪問服務器的用戶數。查看該指標目的:獲得服務器最大併發用戶數。
事務成功率:在性能測試周期內,成功的請求數佔所有請求數的百分比。查看該目標目的:服務器正確處理事務能力。
事務吞吐率TPS:每秒服務器處理的事務數;該指標須要根據當前併發用戶數、總響應時間去計算該值。查看該指標目的:服務器處理事務的能力。
事務平均響應時間:平均一條請求(事務)所用的時間。查看該目標目的:宏觀查看服務器是否達到理想的併發數
提示:
平均響應時間與TPS是沒有直接關係,具備宏觀的反比關係,隨着併發數提升並超過服務器處理能力,平均響應時間就會升高,TPS則會降低。
這裏有一個例子幫助理解二者的區別:
https://www.cnblogs.com/baihuitestsoftware/articles/6405078.html
性能測試的主要手段:模擬真實業務的壓力對被測系統進行加壓,並同時監控被測系統資源性能指標,研究被測系統在不用壓力狀況下的表現,找出其潛在的性能瓶頸。
如何對系統進行加壓,又如何對系統的指標進行監控呢?這裏,就須要引入性能測試工具了。
如今市面上有不少工具,無論使用哪一款工具,基本都會包含以下幾個核心的功能:
原理結構以下圖所示:
壓力發生器:來產生無限壓力地方,至關於無數個測試人員
結果採集器:結果記錄人員
負載控制器:對應的是指揮人員
資源監控器:對應的是若干資源監控人員,監控客戶端、網絡端、服務端
結果分析器:對應的是結果統計人員
壓力發生器是性能測試工具最核心的部分,它主要有兩個功能,一是真實模擬用戶操做,二是模擬有效併發。
大多數性能測試工做人員可能都會忽略的是,當前市面上性能測試工具的壓力發生器基本都是存在缺陷的。
模擬真實用戶操做:瀏覽器在加載網頁的時候,是同時併發多個TCP鏈接去請求頁面對應的HTTP資源,包括HTML、JS、圖片、CSS,當前流行的瀏覽器廣泛會併發6-10個鏈接。然而,性能測試工具在模擬單個用戶操做的時候,基本上都是單鏈接串行加載頁面資源。產生的差別在於,假如頁面有100個資源,每一個HTTP請求的響應時間約爲100毫秒,那麼瀏覽器採用6個鏈接並行加載網頁時大概會須要1.7秒(100/6*100毫秒),而測試工具採用單鏈接串行加載就須要10秒(100*100毫秒),二者結果相差十分巨大。這也解釋了爲何有時候咱們經過性能測試工具測試獲得的響應時間挺長,可是手動用瀏覽器加載網頁時感受挺快的緣由。
有效併發:有效併發就是咱們在測試工具中設置了1000虛擬用戶數,實際在服務器端就能產生1000併發壓力。然而現實狀況是,不少時候因爲測試設備自身出現了性能瓶頸,壓力發生器產生的併發壓力遠小於設定值,而且一般測試工具也不會將該問題暴露給測試人員;若是測試人員忽略了這個問題,覺得測試獲得的結果就是在設定併發壓力下的結果,那麼最終分析得出的結論也就跟實際狀況截然不同了。不過,咱們能夠經過保障測試環境不存在瓶頸,使得實際生成的併發壓力盡量地與設定值一致;另外一方面,咱們也能夠經過在測試過程當中監控Web層(例如Nginx)的鏈接數和請求數,查看實際達到服務器端的併發數是否跟咱們的設定值一致,以此來反推壓力發生器的壓力是否有效。
瞭解這些缺陷的意義在於,咱們能夠更清楚測試工具的原理,從而更準確地理解測試結果的真實含義。
目前市場上主要流行的是Loadrunner和jmeter,還有一款知名度很低的Locust等等,就這三種分析下優劣:
\ |
LoadRunner |
Jmeter |
Locust |
受權方式 |
商業收費 |
開源免費 |
開源免費 |
開發語言 |
C/Java |
Java |
Python |
測試腳本形式 |
C/Java |
GUI |
Python |
併發機制 |
進程/線程 |
線程 |
協程 |
單機併發能力 |
低 |
低 |
高 |
分佈式壓力 |
支持 |
支持 |
支持 |
資源監控 |
支持 |
不支持 |
不支持 |
報告與分析 |
完善 |
簡單圖表 |
簡單圖表 |
支持二次開發 |
不支持 |
支持 |
支持 |
經過對比,Locust也不怎麼樣嘛,資源監控也不支持,報告分析能力也這麼弱,那爲啥還要選擇它?
受權方式這個就不說了。雖然LoadRunner是商業軟件,價格極其昂貴,可是國內盜版橫行,別說我的,就算是大型互聯網公司,用正版的也沒幾個。
從功能特性的角度講,LoadRunner是最全面的,用戶羣體也是最多的,相應的學習資料也最爲豐富,不太熟悉性能測試能夠先從LoadRunner熟悉性能測試工具各個模塊的概念和功能,再過渡到其餘工具。LoadRunner只能在Windows平臺使用,而且併發效率比較低,單臺壓力機難以產生較高的併發能力。
Jmeter的併發是基於線程,併發效率存在一樣的問題;另外,Jmeter在腳本編寫和描述是基於GUI操做
Locust:
模擬用戶:採用Python腳本描述,而且HTTP請求是基於Requests庫,該庫功能強大使用簡單;除了HTPP(S)協議,Locust也能夠測試其餘任意協議的系統,只須要採用Python調用對應的庫進行請求買書便可。
併發機制:採用協程(gevent)的機制。採用多線程模擬用戶時,線程數會隨着併發數的增長而增長,而線程之間的切換是須要佔用資源的,IO的阻塞和線程的sleep會不可避免的致使併發效率降低。
協程和線程區別:協程避免了系統資源調度,由此大幅度提升了性能,單臺普通配置的測試機能夠生產數千併發壓力,這是LoadRunner和Jmeter都沒法實現的。
Locust功能單薄,特別是在性能指標監控和測試報告圖表方面比較缺失,可是Locust的代碼結構清晰,核心代碼量也只有幾百行,可擴展性不錯,深刻挖掘性能測試工具原理很是合適
根據上面,選擇Locust工具來進行性能測試,性能測試重要的是監控性能數據,增長到持續集成會比較複雜,暫時先不考慮集成到Jenkins裏
部署時間:1天
參考資料:
四年性能經驗文章:http://debugtalk.com/post/locustplus-talk-about-performance-test/
百度百科【性能測試】:https://baike.baidu.com/item/性能測試