ab是apache自帶的壓力測試工具。ab非常實用，它不僅可以對apache服務器進行網站訪問壓力測試，也可以對其它類型的服務器進行壓力測試。比如nginx、tomcat、IIS等。
下面我們開始介紹有關ab命令的使用：
1、ab的原理
2、ab的安裝
3、ab參數說明
4、ab性能指標
5、ab實際使用
一、ab的原理
ab是apachebench命令的縮寫。
ab的原理：ab命令會創建多個並發訪問線程，模擬多個訪問者同時對某一URL地址進行訪問。它的測試目標是基於URL的，因此，它既可以用來測試apache的負載壓力，也可以測試nginx、lighthttp、tomcat、IIS等其它Web服務器的壓力。
ab命令對發出負載的計算機要求很低，它既不會占用很高CPU，也不會占用很多內存。但卻會給目標服務器造成巨大的負載，其原理類似CC攻擊。自己測試使用也需要注意，否則一次上太多的負載。可能造成目標服務器資源耗完，嚴重時甚至導致死機。
二、ab的安裝
$ yum install httpd-tools
命令執行完成后，就可以直接運行ab。
三、ab參數說明
下面我們對這些參數進行相關說明。如下：
-n：在測試會話中所執行的請求個數。默認時，僅執行一個請求。
-c：一次產生的請求個數。默認是一次一個。
-t：測試所進行的最大秒數。其內部隱含值是-n 50000，它可以使對服務器的測試限制在一個固定的總時間以內。默認時，沒有時間限制。
-p：包含了需要POST的數據的文件。
-P：對一個中轉代理提供BASIC認證信任。用戶名和密碼由一個:隔開，並以base64編碼形式發送。無論服務器是否需要(即是否發送了401認證需求代碼)，此字符串都會被發送。
-T：POST數據所使用的Content-type頭信息。
-v：設置顯示信息的詳細程度-4或更大值會顯示頭信息，3或更大值可以顯示響應代碼(404,200等),2或更大值可以顯示警告和其他信息。
-V：顯示版本號並退出。
-w：以HTML表的格式輸出結果。默認時，它是白色背景的兩列寬度的一張表。
-i：執行HEAD請求，而不是GET。
-x：設置<table>屬性的字符串。
-X：對請求使用代理服務器。
-y：設置<tr>屬性的字符串。
-z：設置<td>屬性的字符串。
-C：對請求附加一個Cookie:行。其典型形式是name=value的一個參數對，此參數可以重復。
-H：對請求附加額外的頭信息。此參數的典型形式是一個有效的頭信息行，其中包含了以冒號分隔的字段和值的對(如,"Accept-Encoding:zip/zop;8bit")。
-A：對服務器提供BASIC認證信任。用戶名和密碼由一個:隔開，並以base64編碼形式發送。無論服務器是否需要(即,是否發送了401認證需求代碼)，此字符串都會被發送。
-h：顯示使用方法。
-d：不顯示"percentage served within XX [ms] table"的消息(為以前的版本提供支持)。
-e：產生一個以逗號分隔的(CSV)文件，其中包含了處理每個相應百分比的請求所需要(從1%到100%)的相應百分比的(以微妙為單位)時間。由於這種格式已經“二進制化”，所以比'gnuplot'格式更有用。
-g：把所有測試結果寫入一個'gnuplot'或者TSV(以Tab分隔的)文件。此文件可以方便地導入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行為標題。
-i：執行HEAD請求，而不是GET。
-k：啟用HTTP KeepAlive功能，即在一個HTTP會話中執行多個請求。默認時，不啟用KeepAlive功能。
-q：如果處理的請求數大於150，ab每處理大約10%或者100個請求時，會在stderr輸出一個進度計數。此-q標記可以抑制這些信息。
四、ab性能指標
在進行性能測試過程中有幾個指標比較重要：
1、吞吐率（Requests per second）
服務器並發處理能力的量化描述，單位是reqs/s，指的是在某個並發用戶數下單位時間內處理的請求數。某個並發用戶數下單位時間內能處理的最大請求數，稱之為最大吞吐率。
記住：吞吐率是基於並發用戶數的。這句話代表了兩個含義：
a、吞吐率和並發用戶數相關
b、不同的並發用戶數下，吞吐率一般是不同的
計算公式：總請求數/處理完成這些請求數所花費的時間，即
Request per second=Complete requests/Time taken for tests
必須要說明的是，這個數值表示當前機器的整體性能，值越大越好。
2、並發連接數（The number of concurrent connections）
並發連接數指的是某個時刻服務器所接受的請求數目，簡單的講，就是一個會話。
3、並發用戶數（Concurrency Level）
要注意區分這個概念和並發連接數之間的區別，一個用戶可能同時會產生多個會話，也即連接數。在HTTP/1.1下，IE7支持兩個並發連接，IE8支持6個並發連接，FireFox3支持4個並發連接，所以相應的，我們的並發用戶數就得除以這個基數。
4、用戶平均請求等待時間（Time per request）
計算公式：處理完成所有請求數所花費的時間/（總請求數/並發用戶數），即：
Time per request=Time taken for tests/（Complete requests/Concurrency Level）
5、服務器平均請求等待時間（Time per request:across all concurrent requests）
計算公式：處理完成所有請求數所花費的時間/總請求數，即：
Time taken for/testsComplete requests
可以看到，它是吞吐率的倒數。
同時，它也等於用戶平均請求等待時間/並發用戶數，即
Time per request/Concurrency Level
五、ab實際使用
1、ab的命令參數比較多，我們經常使用的是-c和-n參數。
我們現在就來測試apache的性能。使用如下命令：
$ ab -n 100 -c 10 http://13.209.21.196:8080/trade-server/test/order/testQueue
-n 100表示請求總數為100
-c 10表示並發用戶數為10
http://13.209.21.196:8080/trade-server/test/order/testQueue表示請求的目標URL
這行表示處理100個請求並每次同時運行10次請求。
通過上圖，測試結果一目了然，ab測試得出吞吐率為：Requests per second: 5655.47[#/sec](mean)。
除此之外還有其他一些信息，需要說明下，如下：
Server Software表示被測試的Web服務器軟件名稱。
Server Hostname表示請求的URL主機名。
Server Port表示被測試的Web服務器軟件的監聽端口。
Document Path表示請求的URL中的根絕對路徑，通過該文件的后綴名，我們一般可以了解該請求的類型。
Document Length表示HTTP響應數據的正文長度。
Concurrency Level表示並發用戶數，這是我們設置的參數之一。
Time taken for tests表示所有這些請求被處理完成所花費的總時間。
Complete requests表示總請求數量，這是我們設置的參數之一。
Failed requests表示失敗的請求數量，這里的失敗是指請求在連接服務器、發送數據等環節發生異常，以及無響應后超時的情況。如果接收到的HTTP響應數據的頭信息中含有2XX以外的狀態碼，則會在測試結果中顯示另一個名為“Non-2xx responses”的統計項，用於統計這部分請求數，這些請求並不算在失敗的請求中。
Total transferred表示所有請求的響應數據長度總和，包括每個HTTP響應數據的頭信息和正文數據的長度。注意這里不包括HTTP請求數據的長度，僅僅為web服務器流向用戶PC的應用層數據總長度。
HTML transferred表示所有請求的響應數據中正文數據的總和，也就是減去了Total transferred中HTTP響應數據中的頭信息的長度。
Requests per second吞吐率，也叫QPS，計算公式：Complete requests/Time taken for tests
Time per request用戶平均請求等待時間，從用戶角度看，完成一個請求所需要的時間。計算公式：Time token for tests/（Complete requests/Concurrency Level）。
Time per requet(across all concurrent request)服務器完成一個請求的時間，計算公式：Time taken for tests/Complete requests，正好是吞吐率的倒數。
也可以這么統計：Time per request/Concurrency Level。
Transfer rate表示網絡傳輸速度，計算公式：Total trnasferred/ Time taken for tests，這個統計很好的說明服務器的處理能力達到極限時，其出口寬帶的需求量。
對於大文件的請求測試，這個值很容易成為系統瓶頸所在。要確定該值是不是瓶頸，需要了解客戶端和被測服務器之間的網絡情況，包括網絡帶寬和網卡速度等信息。
Percentage of requests served within a certain time（ms）
這部分數據用於描述每個請求處理時間的分布情況，比如以上測試，80%的請求處理時間都不超過2ms，這個處理時間是指前面的Time per request，即對於單個用戶而言，平均每個請求的處理時間。
這個表第一行表示有50%的請求都是在2ms內完成的，可以看到這個值是比較接近平均系統響應時間，以此類推。
Connection Times (ms)
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.1 1 1
Processing: 1 1 0.2 1 2
Waiting: 1 1 0.2 1 2
Total: 1 2 0.2 2 2
這幾行組成的表格主要是針對響應時間也就是第一個Time per request進行細分和統計。一個請求的響應時間可以分成網絡鏈接（Connect），系統處理（Processing）和等待（Waiting）三個部分。表中min表示最小值； mean表示平均值；[+/-sd]表示標准差（Standard Deviation） ，也稱均方差（mean square error），這個概念在中學的數學課上學過，表示數據的離散程度，數值越大表示數據越分散，系統響應時間越不穩定。 median表示中位數； max當然就是表示最大值了。
需要注意的是表中的Total並不等於前三行數據相加，因為前三行的數據並不是在同一個請求中采集到的，可能某個請求的網絡延遲最短，但是系統處理時間又是最長的呢。所以Total是從整個請求所需要的時間的角度來統計的。這里可以看到最慢的一個請求花費了2ms(即100% 2 (longest request))。