參數：
-n requests Number of requests to perform
//在測試會話中所執行的請求個數。默認時，僅執行一個請求
-c concurrency Number of multiple requests to make
//一次產生的請求個數。默認是一次一個。
-t timelimit Seconds to max. wait for responses
//測試所進行的最大秒數。其內部隱含值是-n 50000。它可以使對服務器的測試限制在一個固定的總時間以內。默認時，沒有時間限制。
-p postfile File containing data to POST
//包含了需要POST的數據的文件.
-T content-type Content-type header for POSTing
//POST數據所使用的Content-type頭信息。
-v verbosity How much troubleshooting info to print
//設置顯示信息的詳細程度 - 4或更大值會顯示頭信息， 3或更大值可以顯示響應代碼(404, 200等), 2或更大值可以顯示警告和其他信息。 -V 顯示版本號並退出。
-w Print out results in HTML tables
//以HTML表的格式輸出結果。默認時，它是白色背景的兩列寬度的一張表。
-i Use HEAD instead of GET
// 執行HEAD請求，而不是GET。
-x attributes String to insert as table attributes
//
-y attributes String to insert as tr attributes
//
-z attributes String to insert as td or th attributes
//
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
//-C cookie-name=value 對請求附加一個Cookie:行。 其典型形式是name=value的一個參數對。此參數可以重複。
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
//-P proxy-auth-username:password 對一箇中轉代理提供BASIC認證信任。用戶名和密碼由一個:隔開，並以base64編碼形式發送。無論服務器是否需要(即, 是否發送了401認證需求代碼)，此字符串都會被髮送。
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)
//-attributes 設置 屬性的字符串. 缺陷程序中有各種靜態聲明的固定長度的緩衝區。另外，對命令行參數、服務器的響應頭和其他外部輸入的解析也很簡單，這可能會有不良後果。它沒有完整地實現 HTTP/1.x; 僅接受某些'預想'的響應格式。 strstr(3)的頻繁使用可能會帶來性能問題，即, 你可能是在測試ab而不是服務器的性能。
參數很多,一般我們用 -c 和 -n 參數就可以了. 例如:
./ab -c 1000 -n 1000 http://127.0.0.1/index.php
這個表示同時處理1000個請求並運行1000次index.php文件.
#/usr/local/xiaobai/apache2054/bin/ab -c 1000 -n 1000 http://127.0.0.1/index.html.zh-cn.gb2312
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software: Apache/2.0.54
//平臺apache 版本2.0.54
Server Hostname: 127.0.0.1
//服務器主機名
Server Port: 80
//服務器端口
Document Path: /index.html.zh-cn.gb2312
//測試的頁面文檔
Document Length: 1018 bytes
//文檔大小
Concurrency Level: 1000
//併發數
Time taken for tests: 8.188731 seconds
//整個測試持續的時間
Complete requests: 1000
//完成的請求數量
Failed requests: 0
//失敗的請求數量
Write errors: 0
Total transferred: 1361581 bytes
//整個場景中的網絡傳輸量
HTML transferred: 1055666 bytes
//整個場景中的HTML內容傳輸量
Requests per second: 122.12 [#/sec] (mean)
//大家最關心的指標之一，相當於 LR 中的 每秒事務數 ，後面括號中的 mean 表示這是一個平均值
Time per request: 8188.731 [ms] (mean)
//大家最關心的指標之二，相當於 LR 中的 平均事務響應時間 ，後面括號中的 mean 表示這是一個平均值
Time per request: 8.189 [ms] (mean, across all concurrent requests)
//每個請求實際運行時間的平均值
Transfer rate: 162.30 [Kbytes/sec] received
//平均每秒網絡上的流量，可以幫助排除是否存在網絡流量過大導致響應時間延長的問題
Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 646 1078.7 89 3291
Processing: 165 992 493.1 938 4712
Waiting: 118 934 480.6 882 4554
Total: 813 1638 1338.9 1093 7785
//網絡上消耗的時間的分解，各項數據的具體算法還不是很清楚
Percentage of the requests served within a certain time (ms)
50% 1093
66% 1247
75% 1373
80% 1493
90% 4061
95% 4398
98% 5608
99% 7368
100% 7785 (longest request)
//整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間，其中50％的用戶響應時間小於1093 毫秒，60％ 的用戶響應時間小於1247 毫秒，最大的響應時間小於7785 毫秒
由於對於併發請求，cpu實際上並不是同時處理的，而是按照每個請求獲得的時間片逐個輪轉處理的，所以基本上第一個Time per request時間約等於第二個Time per request時間乘以併發請求數
ab -n 3000 -c 15 'http://127.0.0.1/s.do'
Concurrency Level: 15
Time taken for tests: 380.118 seconds
Complete requests: 3000
Failed requests: 37
(Connect: 0, Receive: 0, Length: 37, Exceptions: 0)
Write errors: 0
Non-2xx responses: 37
Total transferred: 71390473 bytes
HTML transferred: 70481208 bytes
Requests per second: 7.89 [#/sec] (mean)
Time per request: 1900.591 [ms] (mean)
Time per request: 126.706 [ms] (mean, across all concurrent requests)
Transfer rate: 183.41 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 1
Processing: 813 1725 5397.1 1122 50002
Waiting: 813 1725 5397.1 1122 50002
Total: 813 1725 5397.1 1122 50002
Percentage of the requests served within a certain time (ms)
50% 1122
66% 1124
75% 1134
80% 1223
90% 1227
95% 1408
98% 1732
99% 50000
100% 50002 (longest request)
我最近在用 ab ( ApacheBench ) 測試一個網站時發現結果報告中一直會出現 Failed requests，而且出現的次數非常高，我原本以為是壓力測試的結果有大部分是失敗的，但看觀看其他數據卻一點也不覺得有失敗，經過一番研究後才真正理解為何會出現 Failed request 數據。
如下壓力測試的結果：
Server Software: Microsoft-IIS/7.5
Server Hostname: example.com
Server Port: 80
Document Path: /
Document Length: 35137 bytes
Concurrency Level: 1
Time taken for tests: 4.619462 seconds
Complete requests: 100
Failed requests: 99
(Connect: 0, Length: 99, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 100
Total transferred: 3543782 bytes
HTML transferred: 3507782 bytes
Requests per second: 21.65 [#/sec] (mean)
Time per request: 46.195 [ms] (mean)
Time per request: 46.195 [ms] (mean, across all concurrent requests)
Transfer rate: 749.00 [Kbytes/sec] received
先分析上述數據，我取得的第一份 HTML 文件得到的大小 ( Document Length ) 為 35,137 bytes，我總共發出要求共 100 次 ( Complete requests )，總 HTML 數據傳輸量 ( HTML transferred ) 為 3,507,782 bytes 感覺非常合理，實際的傳輸量大約是單一文件的 100 倍，所以我研判這 100 個 Request 的確有正確送出，但為何 Failed requests 會出現有 99 次的錯誤呢？
只要出現 Failed requests 就會多出現一行要求失敗的各原因的數據統計，分別有 Connect, Length, 與 Exception 三種，分別代表的意義為：
Connect 無法送出要求、目標主機連接失敗、要求的過程中連線被中斷
Length 回應的內容長度不一致 ( 以 Content-Length 標頭值為判斷依據 )
Exception 發生無法預期的錯誤
而從上述說明就可以很明顯看出所有的 Failed requests 都落在 Length 這個類別上，原來這是因為受測網站的首頁是動態的內容，當第一次發出 HTTP request 與後續發出的 HTTP request 所得到回應的 HTML 長度都是不同大小的 ( 每次回應的 Content-Length 大小不一致 )，才會引發 Failed requests 的 Length 問題的失敗，因此這類 Length 不一致的失敗在進行「動態網頁」壓力測試時是合理的，可以不予理會。
這裡的 Length 是以 "第 1 次" 取得的 Content-Length 為主，如果第 2 次以後的 HTTP Request 所得到的 HTTP Response Header 得到的 Content-Length 與第 1 次取得的長度不一致，就會得到 Length 的錯誤。