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

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

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

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

測試場景：模擬10個使用者，對百度首頁發起總共100次請求。

測試命令： ab -n 100 -c 10  https://www.baidu.com/index.html

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

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