Apache Bench (ab test)
安裝方法
https://www.cnblogs.com/jave1ove/p/5486427.html
使用方法
https://jingyan.baidu.com/article/e3c78d647a57833c4c85f502.html
結果分析
https://www.cnblogs.com/gumuzi/p/5617232.html
測試場景:模擬10個使用者,對百度首頁發起總共100次請求。
測試命令: ab -n 100 -c 10 https://www.baidu.com/index.html
本文主要針對ab的測試報告進行解析,有關ab的使用方法改天再新開貼交流。
測試報告:
下面來逐行解釋我的理解,以下注釋部分有查閱網上資料,但所寫內容均為自己理解之後手打內容,希望加入自己的理解之後能讓讀者更容易理解。
bogon:~ tang$ ab -n 100 -c 10 https://www.baidu.com/index.html
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
//以上為apache的版本資訊,與本次測試無關
Benchmarking www.baidu.com (be patient).....done
//以上內容顯示測試完成度,本次測試發起請求數量較少,完成較快,無中間過程顯示。在請求數量很多時會分行顯示當前完成數量。
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)。
ApacheBench與Loadrunner壓測結果的差異
https://blog.csdn.net/weixin_42209781/article/details/80927057?utm_source=copy
最近專案過程中碰到這類的問題,AB的壓測結果非常好看,而LR的壓測結果就不是那麼理想。
後來通過查詢相關資料,以及找相關技術人員諮詢。整理過程和結論:
AB為單請求,只適合技術人員簡單的做做測試,不適合壓實際應用場景。
AB壓測指令碼:# ab -n 4000 -c 1000 http://www.xxx.com/
-n後面的4000代表總共發出4000個請求;-c後面的1000表示採用1000個併發(模擬1000個人同時訪問),後面的網址表示測試的目標URL。
如果頁面內含有php、圖片,需再請求:
ab -n 4000 -c 1000 http://xxx.com/ab.php
ab -n 4000 -c 1000 http://xxx.com/ab.gif
ApacheBench與Loadrunner差異:
一個請求發給伺服器,伺服器接到請求後接受請求了,HTTP響應的內容分為三個部分:協議-狀態碼(200)-描述、響應頭、響應正文。伺服器先給客戶端返回一個成功狀態碼200,然後再發送給客戶端需要的東西,比如js、css、圖片等,而AB計只算接收到狀態碼的時間,後面具體的響應資訊或圖片等檔案的傳輸時間等就沒有計算了,而LR是模擬了現實場景中一個使用者的完整操作,響應時間涵蓋:協議-狀態碼-描述、響應頭、響應正文完整的內容。