ab壓力測試

需要清楚的是，ab進行一切測試的本質都是基于HTTP，是以可以說它是對于Web伺服器軟體的黑盒性能測試，它獲得的一切資料和計算結果，都可以通過HTTP來解釋。

另有一些壓力測試軟體，包括LoadRnner、Jmeter等，則是不同程度上包含了伺服器處理之外的時間，比如LoadRunner運作在使用者PC上，可以錄制浏覽器行為，這種測試的結果玩玩側重于站點使用者的角度，有另外一些層面的參考意義。

請看下面的指令行資訊：

請注意我們在啟動ab時，傳入3個指令行參數，它們正是代表了前面提到的前提條件：

-n1000 表示總請求數位1000

-c 表示并發使用者數為10

http://localhost/index.html 表示這些請求的目标URL。

測試結果一目了然，我們看到吞吐率顯示為2204.64reqs/s。同時，在測試結果中還有一些其他内容也值得我們關注，主要包括：

Server Software

表示被測試的Web伺服器軟體名稱，這裡是Apache/2.2.19,它來自于http響應資料的頭資訊，是以如果是我們自己編寫的Web伺服器軟或者修改開源Web伺服器軟體的源代碼，便可以随意改寫這裡的名稱。

vi /usr/local/apache/conf/httpd.conf #隐藏具體版本資訊

ServerSignature Off

ServerTokens Prod

Server Hostname

表示請求的URL中的主機部分名稱，它來自于http請求資料的頭資訊，這裡我們請求的URL是http://localhost/index.html,是以主機名為localhost，說明我們的請求是從Web伺服器端發起的。

Server Port

表示被測試的Web伺服器軟體的監聽端口，為了友善測試，我們後面會對多個不同的Web伺服器軟體使用不同的監聽端口。

Document Path

表示請求的URL中根絕對路徑，它同樣來自于http請求資料的頭資訊，通過它的字尾名，我們一般可以了解該請求的類型。

Document Length

表示http響應資料的正文長度。

Concurrency Level

表示并發使用者數，這是我們設定的參數。

Time taken for tests

表示所有這些請求被處理完成花費的總時間。順便提一下，某些Apache版本如2.2.4附帶的ab，對于這一統計項存在一些計算上的bug，當總請求數較少時，其統計的總時間會無法小于0.1s。

Complete requests

表示總請求數，這是我們設定的相應參數。

Failed requests

表示失敗的請求數，這裡的失敗是指請求的連接配接伺服器、發送資料、接收資料等環節發生異常，以及無響應後逾時的情況。對于逾時時間的設定可以用ab的-t參數。

而如果接受到的http響應資料的頭資訊中含有2xx以外的狀态碼，則會在測試結果顯示另一個名為“Non-2xx responses”的統計項，用于統計這部分請求數，這些請求并不算是失敗的請求。

Total transferred

表示所有請求的響應資料長度總和，包括每個http響應資料的頭資訊和正文資料的長度。注意這裡不包括http請求資料的長度，是以Total

transferred代表了從Web伺服器流向使用者PC的應用層資料總長度。通過使用ab的-v參數即可檢視詳細的http頭資訊。

HTML transferred

表示所有請求的響應資料中正文資料的總和，也就是減去了Total transferred中http響應資料中頭資訊的長度。

Requests per second

這便是我們重點關注的吞吐率，它等于：

Complete requests / Time taken for tests

Time per request

這便是前面提到的使用者平均請求等待時間，它等于:

Time taken for tests / (Complete requests /Concurrency Level)

Time per request?(across all concurrent requests)

這便是前面提到的伺服器平均請求處理時間，它等于：

Time taken for tests / Complete requests

這正是吞吐率的倒數。同時，它也等于：

Time per request / Concurrency Level

Transfer rate

表示這些請求在機關時間内從伺服器擷取的資料長度，它等于：

Total transferred / Time taken for tests

這個統計項可以很好的說明伺服器在處理能力達到限制時，其出口帶寬的需求量。

利用前面介紹的有關帶寬的知識，不難計算出結果。

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

這部分資料用于描述每個請求處理時間的分布情況，比如在以上測試結果中，80%請求的處理時間都不超過1ms，而99%的請求都不超過2ms。注意這裡的處理時間，是指前面的Time per request，即對于單個使用者而言，平均每個請求處理的時間。

繼續壓力測試

下面，我們再來進行一次壓力測試，此時并發使用者數為100，其他條件不變，測試結果如下所示：

和前一次的測試結果相比，可以看出，當并發使用者資料從原來的10變為100後，吞吐率從原來的2204.64增長到了2711.45，伺服器平均請求處理

時間從原來的0.454ms降到了0.369ms，而使用者評價請求等待時間從原來的4.536ms增加到了36.881ms.

可見，随着并發使用者數的變化，吞吐率、使用者平均請求等待時間、伺服器配件請求處理時間都發生了相應的變化。

本文轉自 linuxpp 51CTO部落格，原文連結：http://blog.51cto.com/1439337369/1787985，如需轉載請自行聯系原作者