Linux平臺下可視化壓測軟件visual-wrk

visual-wrk是一款基於wrk開源項目二次開發的Linux下可視化壓測軟件。 git地址（https://github.com/NavInfo2/visual-wrk.git）

朋友，若是你須要一款Linux下安裝簡便、易於使用的壓測工具；或是須要超高併發卻苦於沒有服務器集羣；或是須要將壓力測試集成至Jenkins並獲得一份豐富的可視化報表；又或是須要隨機、按比例混合測試案例的壓測工具，那麼visual-wrk將是你的不二之選！！！

1. 爲何基於wrk作二次開發？

在公司的測試環境中，考慮該壓測軟件將與Linux上的Jenkins持續集成工具聯動使用；另外考慮到公司的技術棧以C/C++爲主，所以咱們須要一款Linux下安裝方便操做簡單、高併發、高擴展性、使用C/C++編寫的開源命令行壓測工具。

如下是對部分壓測軟件的功能比較：

壓測軟件	併發量	https	POST	報告完善度	可擴展性	併發架構
http_load	中	Y	N	中	中	select
webbench	高	Y	N	中	中	fork
ab	高	Y	Y	中	中	epoll
siege	低	Y	Y	中	中	multi thread
wrk	高	Y	Y	中	高	epoll + multi thread
Jmeter	低	Y	Y	高	高	multi thread
LoadRunner	高	Y	Y	高	高	multi thread

Jmeter：併發架構是多線程模擬用戶請求，併發量受多線程切換的影響，在併發上百後達到瓶頸，不太適合高併發請求場景。

LoadRunner：利用Controller控制Generator負載生成器產生負載(每臺最高大約提供幾百的併發請求)，併發架構爲多線程，若是模擬高併發情形則須要多臺Generator，不適宜簡單的內部使用。

ab：操做簡便易用，報表豐富；基於epoll的併發架構，併發量很是高；可是可擴展性低，不適合併發請求不一樣的url；啓動後爲單線程，cpu利用不夠充分。

siege：併發架構爲多線程，併發量過大時，線程間切換會影響併發性能。

其餘：不少極簡軟件，https協議或post請求都不支持的就不說起了。

wrk：基於epoll的併發架構，併發量很是高；可支持多線程，充分利用了CPU；支持lua的腳本擴展（能夠衍生出多種測試方案）；惟一的不足是提供的測試結果不是很豐富。

綜合比較來看，wrk壓力測試工具具有高併發、高擴展等特色，最終咱們選定了它做爲咱們二次開發的原型軟件，並將開發重點偏向於壓測方案的改進以及性能的可視化展現。

2. visual-wrk的改進點

1. 下降多線程加載測試配置致使的偏差延時。
2. 支持批量URL的隨機壓測。
3. 支持不一樣權重比的URL文件混合壓測。
4. 豐富測試結果，生成可視化報表，並支持在Jenkins HTML report瀏覽。
5. 支持在測試報告中展現被測機器的性能變化（需安在被測機器上安裝性能採集模塊）。

3. 下載與安裝

git clone git@github.com:NavInfo2/visual-wrk.git
cd visual-wrk/
make
make install

4. 命令行參數

Usage: wrk <options> <url>                            
  Options:                                            
    -c, --connections <N>  Connections to keep open //併發個數
    -d, --duration    <T>  Duration of test         //測試時長
    -i, --interval    <T>  Request sampling interval//RPS的採樣間隔
    -t, --threads     <N>  Number of threads to use //開啓線程數，默認每增長500個併發，增長1個線程，直到線程數與機器核數一致
                                                      
    -s, --script      <S>  Load Lua script file     //指定lua腳本，當軟件不知足用戶使用條件，用戶能夠自定義lua腳本作些特殊處理（默認不使用）
    -j, --json        <S>  Load json data for script//包含http(PATH,METHOD,BODY等類型)的json數據，由lua腳本加載處理後提供給visual-wrk壓測主程序使用
    -H, --header      <H>  Add header to request    //爲request url增長特殊的header
        --latency          Print latency statistics //統計事物時延
    -v, --version          Print version details    //打印軟件版本
                                                      
  Numeric arguments may include a SI unit (1k, 1M, 1G)
  Time arguments may include a time unit (2s, 2m, 2h)

5. 使用方法

支持的測試方法包括單一url壓測、單文件隨機壓測以及多文件權重壓測。 支持的HTTP方法爲GET或POST。 支持的測試數據格式爲字符串或base64。

• 對 http://127.0.0.1:8080/index.html 單一url進行壓測 單一url壓測：wrk -t4 -c400 -d30s http://127.0.0.1:8080/index.html --latency

• 對data.json中的所有url進行批量的隨機壓測 單文件隨機壓測：wrk -t4 -c400 -d30s -j data.json --latency

• 對mixed_test.json中多個文件以按權重比比例隨機壓測 多文件權重壓測：wrk -t4 -c400 -d30s -j data/mixed_test.json --latency

測試完畢後，測試報告位於測試目錄下的report/log.html中

注:

• 單文件隨機壓測的文件格式

  {
  	    "request":                 
  	    [
  	        {
  	            "path": "url path",
  	            "method": "GET or POST"
  				"bodyType": "base64"
  				"body": "body content"
  	        }                
  	    ]
  	} 
  
  	path字段：填充url的path
  	method字段：填充POST或GET，其餘方法暫未支持
  	body字段：method字段填充POST時，該字段爲POST的內容；當填充GET時，不須要該字段
  	bodyType字段：當body內容爲base64格式的數據時，須要增長該字段，並填充base64

• 多文件權重壓測的文件格式

  {
          "mixed_test":              
  	    [
  	        {
  	            "label":"get",     
  	            "file": "data/method_get.json", 
  	            "weight": "1"      
  	        }
  	     ]
  	}
  	label字段：自定義惟一標籤名
  	file字段：測試文件路徑（以data的上一級目錄爲基準）
  	weight字段：每一個文件的測試權重比
  
  	當json文件爲混合壓測文件時，請以「mixed_」開頭重命名文件

  具體格式內容案例可參見如下文件

  GET請求的文件：data/method_get.json
  	POST請求的文件：data/method_post_base64.json
  	基於Base64的POST請求的文件：data/method_post.json
  	混合壓測的文件：data/mixed_test.json

6. 壓測報告介紹

報告分爲三個模塊：測試參數、測試結果、服務信息。

1) 測試參數模塊

上圖內容：

• 測試文件爲route100_500km.json，用戶能夠點擊進入查看該測試文件
• URL的地址爲https://navicore.mapbar.com，使用了https協議，主機爲navicore.mapbar.com，path存在json文件中
• 這次壓測併發量爲60，持續測試5分鐘

2) 測試結果模塊

上圖內容：

• 在5分鐘內發起了7508次請求，接收了858.80MB的數據
• 在傳輸層發生了一次鏈接錯誤，4次read錯誤(read錯誤多是在讀取數據時超時致使的)
• 完成了7058次請求
• 非2xx或3xx的請求響應個數爲5個
• 平均RPS爲每秒25.03個
• 平均數據傳輸速率爲每秒2.86MB
• 發現了5次404的HTTP請求錯誤碼

上圖內容：

• 完成HTTP事務時延分佈：50%在2.31秒之內，100%的請求在3.59秒之內

上圖繪製了測試期間，每秒完成的請求個數與response code爲200的個數

上圖繪製了時延分佈的柱狀圖

上表是對測試結果整理，stdev爲標準差，+/-stdev爲包含一個正負標準差的分佈比例

3) 服務器信息模塊（需在服務器安裝信息採集模塊）

該模塊收集了被測服務器的硬件信息

信息採集模塊安裝及使用方法，可參見(https://blog.csdn.net/t1005460759/article/details/88175107)

上圖展現了被測端的服務器系統信息、CPU硬件信息及硬盤使用率

上圖展現了被測端的各個CPU使用率折線圖

上圖展現了被測端的內存使用率折線圖

上圖展現了被測端的IO讀寫次數以及IO讀寫大小的折線圖