apache性能測試工具ab使用詳解

網站性能壓力測試是服務器網站性能調優過程當中必不可缺乏的一環。只有讓服務器處在高壓狀況下，才能真正體現出軟件、硬件等各類設置不當所暴露出的問題。

性能測試工具目前最多見的有如下幾種：ab、http_load、webbench、siege。今天咱們專門來介紹ab。

ab是apache自帶的壓力測試工具。ab很是實用，它不只能夠對apache服務器進行網站訪問壓力測試，也能夠對或其它類型的服務器進行壓力測試。好比nginx、tomcat、IIS等。

下面咱們開始介紹有關ab命令的使用：

一、ab的原理

二、ab的安裝

三、ab參數說明

四、ab性能指標

五、ab實際使用

六、測試nginx性能

1、ab的原理

ab是apachebench命令的縮寫。

ab的原理：ab命令會建立多個併發訪問線程，模擬多個訪問者同時對某一URL地址進行訪問。它的測試目標是基於URL的，所以，它既能夠用來測試apache的負載壓力，也能夠測試nginx、lighthttp、tomcat、IIS等其它Web服務器的壓力。

ab命令對發出負載的計算機要求很低，它既不會佔用很高CPU，也不會佔用不少內存。但卻會給目標服務器形成巨大的負載，其原理相似CC攻擊。本身測試使用也須要注意，不然一次上太多的負載。可能形成目標服務器資源耗完，嚴重時甚至致使死機。

2、ab的安裝

ab的安裝很是簡單，若是是源碼安裝apache的話，那就更簡單了。apache安裝完畢後ab命令存放在apache安裝目錄的bin目錄下。以下：

/usr/local/apache2/bin

若是apache 是經過yum的RPM包方式安裝的話，ab命令默認存放在/usr/bin目錄下。以下：

which ab

注意：若是不想安裝apache可是又想使用ab命令的話，咱們能夠直接安裝apache的工具包httpd-tools。以下：

yum -y install httpd-tools

查看ab是否安裝成功，能夠切換到上述目錄下，使用ab –V命令進行檢測。以下：

ab -V

若是ab安裝成功，經過ab –V命令則會顯示ab的相迎版本，如上圖示。

注意以上是在linux平臺下進行安裝的，若是是windows平臺下，咱們也能夠下載對應的apache版本進行安裝。

目前apache最新版2.4.10，apache官網已經沒有windows下載的版本。可是咱們能夠下載apache官網提供的集成軟件包，以下：

3、ab參數說明

有關ab命令的使用，咱們能夠經過幫助命令進行查看。以下：

ab --help

下面咱們對這些參數，進行相關說明。以下：

-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標記能夠抑制這些信息。

4、ab性能指標

在進行性能測試過程當中有幾個指標比較重要：

一、吞吐率（Requests per second）

服務器併發處理能力的量化描述，單位是reqs/s，指的是在某個併發用戶數下單位時間內處理的請求數。某個併發用戶數下單位時間內能處理的最大請求數，稱之爲最大吞吐率。

記住：吞吐率是基於併發用戶數的。這句話表明了兩個含義：

a、吞吐率和併發用戶數相關

b、不一樣的併發用戶數下，吞吐率通常是不一樣的

計算公式：總請求數/處理完成這些請求數所花費的時間，即

Request per second=Complete requests/Time taken for tests

必需要說明的是，這個數值表示當前機器的總體性能，值越大越好。

二、併發鏈接數（The number of concurrent connections）

併發鏈接數指的是某個時刻服務器所接受的請求數目，簡單的講，就是一個會話。

三、併發用戶數（Concurrency Level）

要注意區分這個概念和併發鏈接數之間的區別，一個用戶可能同時會產生多個會話，也即鏈接數。在HTTP/1.1下，IE7支持兩個併發鏈接，IE8支持6個併發鏈接，FireFox3支持4個併發鏈接，因此相應的，咱們的併發用戶數就得除以這個基數。

四、用戶平均請求等待時間（Time per request）

計算公式：處理完成全部請求數所花費的時間/（總請求數/併發用戶數），即：

Time per request=Time taken for tests/（Complete requests/Concurrency Level）

五、服務器平均請求等待時間（Time per request:across all concurrent requests）

計算公式：處理完成全部請求數所花費的時間/總請求數，即：

Time taken for/testsComplete requests

能夠看到，它是吞吐率的倒數。

同時，它也等於用戶平均請求等待時間/併發用戶數，即

Time per request/Concurrency Level

5、ApacheBench用法詳解：

在Linux系統，通常安裝好Apache後能夠直接執行；
# ab -n 4000 -c 1000 http://www.ha97.com/

若是是Win系統下，打開cmd命令行窗口，cd到apache安裝目錄的bin目錄下；

-n後面的4000表明總共發出4000個請求；-c後面的1000表示採用1000個併發（模擬1000我的同時訪問），後面的網址表示測試的目標URL。

結果分析：

This is ApacheBench, Version 2.3
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.80.157 (be patient)
Completed 400 requests
Completed 800 requests
Completed 1200 requests
Completed 1600 requests
Completed 2000 requests
Completed 2400 requests
Completed 2800 requests
Completed 3200 requests
Completed 3600 requests
Completed 4000 requests
Finished 4000 requests

Server Software: Apache/2.2.15
Server Hostname: 192.168.80.157
Server Port: 80

Document Path: /phpinfo.php
#測試的頁面
Document Length: 50797 bytes
#頁面大小

Concurrency Level: 1000
#測試的併發數
Time taken for tests: 11.846 seconds
#整個測試持續的時間
Complete requests: 4000
#完成的請求數量
Failed requests: 0
#失敗的請求數量
Write errors: 0
Total transferred: 204586997 bytes
#整個過程當中的網絡傳輸量
HTML transferred: 203479961 bytes
#整個過程當中的HTML內容傳輸量
Requests per second: 337.67 [#/sec] (mean)
#最重要的指標之一，至關於LR中的每秒事務數，後面括號中的mean表示這是一個平均值
Time per request: 2961.449 [ms] (mean)
#最重要的指標之二，至關於LR中的平均事務響應時間，後面括號中的mean表示這是一個平均值
Time per request: 2.961 [ms] (mean, across all concurrent requests)
#每一個鏈接請求實際運行時間的平均值
Transfer rate: 16866.07 [Kbytes/sec] received
#平均每秒網絡上的流量，能夠幫助排除是否存在網絡流量過大致使響應時間延長的問題
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 483 1773.5 11 9052
Processing: 2 556 1459.1 255 11763
Waiting: 1 515 1459.8 220 11756
Total: 139 1039 2296.6 275 11843
#網絡上消耗的時間的分解，各項數據的具體算法還不是很清楚

Percentage of the requests served within a certain time (ms)
50% 275
66% 298
75% 328
80% 373
90% 3260
95% 9075
98% 9267
99% 11713
100% 11843 (longest request)
#整個場景中全部請求的響應狀況。在場景中每一個請求都有一個響應時間，其中50％的用戶響應時間小於275毫秒，66％的用戶響應時間小於298毫秒，最大的響應時間小於11843毫秒。對於併發請求，cpu實際上並非同時處理的，而是按照每一個請求得到的時間片逐個輪轉處理的，因此基本上第一個Time per request時間約等於第二個Time per request時間乘以併發請求數。

總結：在遠程對web服務器進行壓力測試，每每效果不理想（由於網絡延時過大），建議使用內網的另外一臺或者多臺服務器經過內網進行測試，這樣得出的數據，準確度會高不少。若是隻有單獨的一臺服務器，能夠直接本地測試，比遠程測試效果要準確。