Apache下分析ab性能測試結果

一直以來我都是用Loadrunner去做性能測試。Loadrunner實際上是一個很重的性能測試工具。他的功能很全面,是一把很好的牛刀。

如果我們隻是需要對一個頁面做簡單的性能測試,使用Loadruner這把牛刀就不是一個很好的選擇瞭。

所以就找瞭把小刀--ab來試試。這把小刀真的是輕巧又鋒利,在這裡就記錄一下對ab測試過程中的一些自己的理解,供大傢參考。

我們就拿百度首頁來祭刀吧。首先你得有一把刀,也就是安裝好Apache,網上教程一大堆就不復述瞭,本文使用MacBook自帶的ab命令進行測試。

測試場景:模擬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=227bytes*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)。

通過以上說明相信大傢都能明白這些數據的意義瞭。如有錯誤還請留言指正。

到此這篇關於Apache下分析ab性能測試結果的文章就介紹到這瞭。希望對大傢的學習有所幫助,也希望大傢多多支持WalkonNet。

推薦閱讀: