伺服器負載太大而影響程式效率是很常見的，Apache伺服器自帶有一個叫ab(ApacheBench)的工具，在bin目錄下。ab專門用於HTTP Server的benchmark testing，可以同時模擬多個併發請求，使用這個輕巧的工具我們可以對伺服器進行負載測試。

今天在公司也用它作一些測試，現在整理了下它的一些東西分享下。

首先我們要得到Apache伺服器的目錄下bin的路徑，我電腦中的路徑是D:\wamp\bin\apache\Apache2.2.21\bin，開啟cmd，轉到這個目錄下，在其中輸入：ab -n 10 -c 10 https://www.jb51.net/ 這條指令，這條指令的意思是：ab -n 全部請求數 -c 併發數 測試URL。這裡值得注意的是，如果你的測試URL是一個網站的網址，請記得在其後加上/，否則會無法工作。

http

ab -n 10 -c 10 http://www.jb51.net/ 

https

abs -n 10 -c 10 https://www.jb51.net/ 

預設 get

ab -c 10 -n 10 http://www.test.api.com/?gid=2

post

ab -n 100  -c 10 -p 'post.txt' -T 'application/x-www-form-urlencoded' 'http://test.api.com/ttk/auth/info/'

注：post.txt 是一個檔案可指定目錄和檔名裡面的格式是：

cid=4&status=1

輸入引數相應解釋

-n 測試會話中所執行的請求個數,預設僅執行一個請求
 
-c 一次產生的請求個數,即同一時間發出多少個請求,預設為一次一個
-t 測試所進行的最大秒數,預設為無時間限制....其內部隱含值是[-n 50000],它可以使對伺服器的測試限制在一個固定的總時間以內
-p 包含了需要POST的資料的檔案
-T POST資料所使用的Content-type頭資訊
-v 設定顯示資訊的詳細程度
-w 以HTML表格的形式輸出結果,預設是白色背景的兩列寬度的一張表
-i 以HTML表格的形式輸出結果,預設是白色背景的兩列寬度的一張表
-x 設定<table>屬性的字串,此屬性被填入<table 這裡>
-y 設定<tr>屬性的字串
 
-z 設定<td>屬性的字串
-C 對請求附加一個Cookie行，其典型形式是name=value的引數對,此引數可以重複
-H 對請求附加額外的頭資訊,此引數的典型形式是一個有效的頭資訊行,其中包含了以冒號分隔的欄位和值的對(如"Accept-Encoding: zip/zop;8bit")
-A HTTP驗證,用冒號:分隔傳遞使用者名稱及密碼
-P 無論伺服器是否需要(即是否傳送了401認證需求程式碼),此字串都會被髮送
-X 對請求使用代理伺服器
-V 顯示版本號並退出
-k 啟用HTTP KeepAlive功能,即在一個HTTP會話中執行多個請求,預設為不啟用KeepAlive功能
-d 不顯示"percentage served within XX [ms] table"的訊息(為以前的版本提供支援)
-S 不顯示中值和標準背離值,且均值和中值為標準背離值的1到2倍時,也不顯示警告或出錯資訊,預設會顯示最小值/均值/最大值等(為以前的版本提供支援)
-g 把所有測試結果寫入一個'gnuplot'或者TSV(以Tab分隔的)檔案
-e 產生一個以逗號分隔的(CSV)檔案,其中包含了處理每個相應百分比的請求所需要(從1%到100%)的相應百分比的(以微妙為單位)時間
-h 顯示使用方法
-k 傳送keep-alive指令到伺服器端

以下是我執行的結果：

This is ApacheBench, Version 2.3 <$Revision: 655654 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.jb51.net (be patient)…..done

Server Software:        Microsoft-IIS/6.0  //Microsoft-IIS伺服器版本6.0

Server Hostname:        www.jb51.net  //伺服器主機名

Server Port:            80  //伺服器埠
Document Path:          /  //測試的頁面文件

Document Length:        32639 bytes  //文件大小
Concurrency Level:      10  //併發數

Time taken for tests:   13.548 seconds  //整個測試持續的時間

Complete requests:      10  //完成的請求數量

Failed requests:        0  //失敗的請求數量

Write errors:           0

Total transferred:      331070 bytes  //整個場景中的網路傳輸量

HTML transferred:       326390 bytes  //整個場景中的HTML內容傳輸量

Requests per second:    0.74 [#/sec] (mean)  //每秒事務數 ，後面括號中的 mean 表示這是一個平均值

Time per request:       13547.775 [ms] (mean)  //平均事務響應時間 ，後面括號中的 mean 表示這是一個平均值

Time per request:       1354.777 [ms] (mean, across all concurrent requests)  //每個請求實際執行時間的平均值

Transfer rate:          23.86 [Kbytes/sec] received  //平均每秒網路上的流量，可以幫助排除是否存在網路流量過大導致響應時間延長的問題
Connection Times (ms)  //網路上消耗的時間的分解

              min  mean[+/-sd] median   max

Connect:        1    2   0.8      2       3

Processing:  2163 3981 3420.2   2957   13540

Waiting:     1305 3204 3595.3   2096   13169

Total:       2164 3983 3420.0   2959   13541

//以下是整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間，其中50％的使用者響應時間小於2959毫秒，66％ 的使用者響應時間小於3074毫秒，最大的響應時間小於13541 毫秒。由於對於併發請求，cpu實際上並不是同時處理的，而是按照每個請求獲得的時間片逐個輪轉處理的，所以基本上第一個Time per request時間約等於第二個Time per request時間乘以併發請求數。

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

  50%   2959

  66%   3074

  75%   3974

  80%   4008

  90%  13541

  95%  13541

  98%  13541

  99%  13541

 100%  13541 (longest request)

下面來逐行解釋我的理解，以下注釋部分有查閱網上資料，但所寫內容均為自己理解之後手打內容，希望加入自己的理解之後能讓讀者更容易理解。

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）。