1. 程式人生 > >Linux下 安裝ab測試工具以及使用

Linux下 安裝ab測試工具以及使用

安裝

yum -y install httpd-tools

檢視資訊:ab -V

測試

下面我們對這些引數,進行相關說明。如下:

-n在測試會話中所執行的請求個數。預設時,僅執行一個請求。

-c一次產生的請求個數。預設是一次一個。

-t測試所進行的最大秒數。其內部隱含值是-n 50000,它可以使對伺服器的測試限制在一個固定的總時間以內。預設時,沒有時間限制。

-p包含了需要POST的資料的檔案。

-P對一箇中轉代理提供BASIC認證信任。使用者名稱和密碼由一個:隔開,並以base64編碼形式傳送。無論伺服器是否需要(即, 是否傳送了401認證需求程式碼),此字串都會被髮送。

-T POST資料所使用的Content-type頭資訊。

-v設定顯示資訊的詳細程度-4或更大值會顯示頭資訊,3或更大值可以顯示響應程式碼(404,200等),2或更大值可以顯示警告和其他資訊。

-V顯示版本號並退出。

-w以HTML表的格式輸出結果。預設時,它是白色背景的兩列寬度的一張表。

-i執行HEAD請求,而不是GET。

-x設定<table>屬性的字串。

-X對請求使用代理伺服器。

-y設定<tr>屬性的字串。

-z設定<td>屬性的字串。

-C對請求附加一個Cookie:行。其典型形式是name=value的一個引數對,此引數可以重複。

-H對請求附加額外的頭資訊。此引數的典型形式是一個有效的頭資訊行,其中包含了以冒號分隔的欄位和值的對(如,"Accept-Encoding:zip/zop;8bit")。

-A對伺服器提供BASIC認證信任。使用者名稱和密碼由一個:隔開,並以base64編碼形式傳送。無論伺服器是否需要(即,是否傳送了401認證需求程式碼),此字串都會被髮送。

-h顯示使用方法。

-d不顯示"percentage served within XX [ms] table"的訊息(為以前的版本提供支援)。

-e產生一個以逗號分隔的(CSV)檔案,其中包含了處理每個相應百分比的請求所需要(從1%到100%)的相應百分比的(以微妙為單位)時間。由於這種格式已經“二進位制化”,所以比'gnuplot'格式更有用。

-g把所有測試結果寫入一個'gnuplot'或者TSV(以Tab分隔的)檔案。此檔案可以方便地匯入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行為標題。

-i執行HEAD請求,而不是GET。

-k啟用HTTP KeepAlive功能,即在一個HTTP會話中執行多個請求。預設時,不啟用KeepAlive功能。

-q如果處理的請求數大於150,ab每處理大約10%或者100個請求時,會在stderr輸出一個進度計數。此-q標記可以抑制這些資訊。

例如:

ab -n1000 -c100 https://www.imooc.com/     請求1000次,每次併發100;

結果:

Server Software:        bfe/1.0.8.14    //被測試的伺服器所用的軟體資訊,這裡使用的是百度自己開發的反向代理Baidu Front End,類似nginx。

Server Hostname:        www.baidu.com //被測主機名


Server Port:            443 //被測主機的服務埠號,一般http請求的預設埠號是80,https預設使用443埠


SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128  //加密協議




 


Document Path:          /index.html  //請求的具體檔案


Document Length:        227 bytes   //請求的檔案index.html大小


 


Concurrency Level:      10 //併發級別,也就是併發數,請求中-c引數指定的數量


Time taken for tests:   1.093 seconds //本次測試總共花費的時間


Complete requests:      100 //本次測試總共發起的請求數量


Failed requests:        0 //失敗的請求數量。因網路原因或伺服器效能原因,發起的請求並不一定全部成功,通過該數值和Complete requests相除可以計算請求的失敗率,作為測試結果的重要參考。



Total transferred:      103314 bytes  //總共傳輸的資料量,指的是ab從被測伺服器接收到的總資料量,包括index.html的文字內容和請求頭資訊。


HTML transferred:       22700 bytes //從伺服器接收到的index.html檔案的總大小,等於Document Length*Complete requests=227 bytes*100=22700 bytes


Requests per second:    91.50 [#/sec] (mean) //平均(mean)每秒完成的請求數:QPS,這是一個平均值,等於Complete requests/Time taken for tests=100/1.093=91.50


Time per request:       109.287 [ms] (mean) //從使用者角度看,完成一個請求所需要的時間(因使用者數量不止一個,伺服器完成10個請求,平均每個使用者才接收到一個完整的返回,所以該值是下一項數值的10倍。)


Time per request:       10.929 [ms] (mean, across all concurrent requests)// 伺服器完成一個請求的時間。


Transfer rate:          92.32 [Kbytes/sec] received  //網路傳輸速度。對於大檔案的請求測試,這個值很容易成為系統瓶頸所在。要確定該值是不是瓶頸,需要了解客戶端和被測伺服器之間的網路情況,包括網路頻寬和網絡卡速度等資訊。


 


Connection Times (ms)


              min  mean[+/-sd] median   max


Connect:       47   74  12.9     74     106


Processing:     9   32  20.2     32     106


Waiting:        9   29  19.1     27      98


Total:         66  106  20.8    106     195


//這幾行組成的表格主要是針對響應時間也就是第一個Time per request進行細分和統計。一個請求的響應時間可以分成網路連結(Connect),系統處理(Processing)和等待(Waiting)三個部分。表中min表示最小值; mean表示平均值;[+/-sd]表示標準差(Standard Deviation) ,也稱均方差(mean square error),這個概念在中學的數學課上學過,表示資料的離散程度,數值越大表示資料越分散,系統響應時間越不穩定。 median表示中位數; max當然就是表示最大值了。


//需要注意的是表中的Total並不等於前三行資料相加,因為前三行的資料並不是在同一個請求中採集到的,可能某個請求的網路延遲最短,但是系統處理時間又是最長的呢。所以Total是從整個請求所需要的時間的角度來統計的。這裡可以看到最慢的一個請求花費了195ms,這個資料可以在下面的表中得到驗證。



 


Percentage of the requests served within a certain time (ms)


  50%    106


  66%    109


  75%    111


  80%    114


  90%    118


  95%    154


  98%    176


  99%    195


 100%    195 (longest request)


//這個表第一行表示有50%的請求都是在106ms內完成的,可以看到這個值是比較接近平均系統響應時間(第一個Time per request:       109.287 [ms] (mean) )


以此類推,90%的請求是小於等於118ms的。剛才我們看到響應時間最長的那個請求是195ms,那麼顯然所有請求(100%)的時間都是小於等於195毫秒的,也就是表中最後一行的資料肯定是時間最長的那個請求(longest request)。