ab的全稱是ApacheBench，是Apache附帶的一個小工具，專門用於HTTP Server的benchmark testing，可以同時模擬多個併發請求。
在這個例子的一開始，我執行了這樣一個命令ab -n 10 -c 10http://www.google.com/。這個命令的意思是啓動ab，向www.google.com發送10個請求(-n 10) ，並每次發送10個請求(-c 10) ——也就是說一次都發過去了。
apache ab做重複壓力測試不錯，但是每次只能測試一個鏈接
\apahce\bin>ab.exe -n 10 -c 10 http://www.google.com/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking www.google.com (be patient).....done
Server Software: gws
Server Hostname: www.google.com
Server Port: 80
Document Path: /
Document Length: 4941 bytes
Concurrency Level: 10
Time taken for tests: 5.218750 seconds//**整個測試持續的時間**
Complete requests: 10//**完成的請求數量**
Failed requests: 9//**失敗的請求數量**
(Connect: 0, Length: 9, Exceptions: 0)
Write errors: 0
Total transferred: 52730 bytes**整個場景中的網絡傳輸量**
HTML transferred: 49540 bytes**整個場景中的HTML內容傳輸量**
Requests per second: 1.92 [#/sec] (mean) **大家最關心的指標之一，相當於LR中的每秒事務數，後面括號中的mean表示這是一個平均值**
Time per request: 5218.750 [ms] (mean) *大家最關心的指標之二，相當於LR中的平均事務響應時間，後面括號中的mean表示這是一個平均值**
Time per request: 521.875 [ms] (mean, across all concurrent requests)
Transfer rate: 9.77 [Kbytes/sec] received*平均每秒網絡上的流量，可以幫助排除是否存在網絡流量過大導致響應時間延長的問題**
Connection Times (ms)
min mean[+/-sd] median max
Connect: 187 488 257.6 437 921
Processing: 312 1673 1204.4 1547 3985
Waiting: 296 1668 1206.3 1546 3984
Total: 593 2162 1432.6 1890 4906
**下面的內容爲整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間，其中50％的用戶響應時間小於**毫秒，60％的用戶響應時間小於**毫秒，最大的響應時間小於 **毫秒**
Percentage of the requests served within a certain time (ms)
50% 1890
66% 2406
75% 3093
80% 3984
90% 4906
95% 4906
98% 4906
99% 4906
100% 4906 (longest request)
-----------------------------------------------------------------------------
格式： ./ab [options] [http://]hostname[:port]/path
參數：
-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)
二、 webbench
wget http://blog.s135.com/soft/linux/webbench/webbench-1.5.tar.gz
tar zxvf webbench-1.5.tar.gz
cd webbench-1.5
make && make install
#webbench -c 100 -t 10 http://192.168.200.100/info.php
參數說明：-c表示併發數，-t表示持續時間(秒)
root@ubuntu-desktop:/etc/nginx/sites-available# webbench -c 100 -t 10 http://192.168.200.100/info.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.200.100/info.php
100 clients, running 10 sec.
Speed=19032 pages/min, 18074373 bytes/sec.
Requests: 3172 susceed, 0 failed.
三、 Siege
apache ab做重複壓力測試不錯，但是每次只能測試一個鏈接
如何測試一組鏈接（比如從日誌中導出的1個小時的日誌，做真實壓力測試），後來找到了這個：
Siege是一個壓力測試和評測工具，設計用於WEB開發這評估應用在壓力下的承受能力：可以根據配置對一個WEB站點進行多用戶的併發訪問，記錄每個用戶所有請求過程的相應時間，並在一定數量的併發訪問下重複進行。
下載/安裝
Siege時一個開放源代碼項目：http://www.joedog.org/siege/
下載：
wget ftp://sid.joedog.org/pub/siege/siege-latest.tar.gz
安裝：
#./configure ; make
#make install
#siege -help （如果有help出現，則已經安裝成功）
siege包含了一組壓力測試工具：
SIEGE (1) Siege是一個HTTP壓力測試和評測工具.
使用樣例：
任務列表：www.chedong.com.url文件
http://www.chedong.com/tech/
http://www.chedong.com/tech/acdsee.html
http://www.chedong.com/tech/ant.html
http://www.chedong.com/tech/apache_install.html
http://www.chedong.com/tech/awstats.html
http://www.chedong.com/tech/cache.html
http://www.chedong.com/tech/click.html
http://www.chedong.com/tech/cms.html
http://www.chedong.com/tech/compress.html
http://www.chedong.com/tech/cvs_card.html
http://www.chedong.com/tech/default.html
http://www.chedong.com/tech/dev.html
http://www.chedong.com/tech/gnu.html
….
siege -c 20 -r 2 -f www.chedong.com.url
參數說明：
-c 20 併發20個用戶
-r 2 重複循環2次
-f www.chedong.com.url 任務列表：URL列表
輸出樣例：
** Siege 2.59
** Preparing 20 concurrent users for battle. 這次“戰鬥”準備了20個併發用戶
The server is now under siege.. done. 服務在“圍攻”測試中：
Transactions: 40 hits 完成40次處理
Availability: 100.00 % 成功率
Elapsed time: 7.67 secs 總共用時
Data transferred: 877340 bytes 共數據傳輸：877340字節
Response time: 1.65 secs 相應用時1.65秒：顯示網絡連接的速度
Transaction rate: 5.22 trans/sec 平均每秒完成5.22次處理：表示服務器後臺處理的速度
Throughput: 114385.92 bytes/sec 平均每秒傳送數據：114385.92字節
Concurrency: 8.59 最高併發數 8.59
Successful transactions: 40 成功處理次數
Failed transactions: 0 失敗處理次數
輔助工具：
增量壓力測試：
爲了方便增量壓力測試，siege還包含了一些輔助工具：
bombardment (1)
是一個輔助工具：用於按照增量用戶壓力測試：
使用樣例：
bombardment urlfile.txt 5 3 4 1
初始化URL列表：urlfile.txt
初始化爲：5個用戶
每次增加：3個用戶
運行：4次
每個客戶端之間的延遲爲：1秒
輸出成CSV格式：
siege2csv.pl (1)
siege2csv.pl將bombardment的輸出變成CSV格式：
Time Data Transferred Response Time Transaction Rate Throughput Concurrency Code 200 (note that this is horribly broken.)
242 60.22 603064 0.02 4.02 10014.35 0.08
605 59.98 1507660 0.01 10.09 25136.05 0.12
938 59.98 2337496 0.02 15.64 38971.26 0.26
1157 60 2883244 0.04 19.28 48054.07 0.78
四、 http_load
下載地址：http://www.acme.com/software/http_load/http_load-12mar2006.tar.gz
程序非常小，解壓後也不到100K 居家旅行 攜帶方便 呵呵
http_load以並行複用的方式運行，用以測試web服務器的吞吐量與負載。但是它不同於大多數壓力測試工具，它可以以一個單一的進程運行，一般不會把客戶機搞死。可以可以測試HTTPS類的網站請求。
命令格式：http_load -p 併發訪問進程數 -s 訪問時間 需要訪問的URL文件
例如：
引用
http_load -p 30 -s 60 urllist.txt
準 備URL文件：tst.list，文件格式是每行一個URL，URL最好超過50－100個測試效果比較好，另外，測試結果中主要的指標是 fetches/sec 這個選項，即服務器每秒能夠響應的查詢次數，用這個指標來衡量性能。似乎比 apache的ab準確率要高一些，也更有說服力一些。
官方的例子：
引用
% ./http_load -rate 10 -seconds 60 urllist.txt
49 fetches, 4 max parallel, 289884 bytes, in 10.0148 seconds
5916 mean bytes/connection
4.89274 fetches/sec, 28945.5 bytes/sec
msecs/connect: 28.8932 mean, 44.243 max, 24.488 min
msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
4.89274 fetches/sec 這個值得就是說服務器每秒能夠響應的查詢次數爲4.8左右
這個值得是根據 49 fetches / 10.0148 seconds 秒計算出來的
五、 Web Application Stress 【附下載】
http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&displaylang=en
說明：
1. 在“settings”的功能設置中，一個是Stress level (threads)這裏是指定程序在後臺用多少線程進行請求，也就是相當於模擬多少個客戶機的連接，更加形象的就是說設置多少轟炸的線程數。一般填寫 500～1000，因爲這個線程數是根據本機的承受力來設置的，如果你對自己的機器配置有足夠信心的話，那麼設置的越高，轟炸的效果越好。
2.在“Test Run Time”中來指定一次壓力測試需要持續的時間，分爲天、小時、分、秒幾個單位級別，你根據實際情況來設置吧！
使用：
在工具中點右鍵，選擇Add命令，增加了一個新的測試項目：New script，對它進行設置，在主選項中的server中填寫要測試的服務器的IP地址[192.168.200.100]。在下方選擇測試的Web連接方式，這裏的方式Verb選擇 get，path選擇要測試的Web頁面路徑[/info.php]，
在“Settings”的功能設置中將Stress level (threads)線程數設置爲1000。完畢後，點工具中的灰色三角按鈕即可進行測試（如圖4）。測試完畢，等待朋友把任務管理器以及連接查看的截圖發過來！
攻 擊開始後，朋友從任務管理器中可以看到CPU使用率已經達到100%，損耗率達到最大。在CMD窗口中使用命令netstat -an,可以看到我的IP地址在朋友服務器上的80端口進行了非常多的連接。而且它的Web網站已經打不開了，提示過多用戶連接，達到了跟 D.O.S攻擊一樣的目的。
數據分析：
選擇“View”菜單下的“Reports”命令，或單擊工具欄上的 按鈕，打開報告窗口，在左側列表中展開相應的報告。
檢查Socket Errors部分是否有任何的socket有關的錯誤（值不爲0）。
Socket Errors
--------------------------------------------------------------------------------
Connect: 406
Send: 0
Recv: 306
Timeouts: 0
這裏列出每種socket錯誤的解釋：Connect——客戶端不能與服務器取得連接的次數。如果這個值偏高，檢查在客戶端與服務器之間產生的任何潛在的錯誤。從每個客戶端Ping服務器或telnet服務器的端口80驗證你得到正確的迴應；Send——客戶端不能正確發送數據到服務器的次數。如果這個值偏高，檢查服務器是否正確地工作着。在客戶端打開一個瀏覽器然後手工點擊站點頁面驗證站點正確地工作着；Recv——客戶端不能正確從服務器接收數據的次數。如果這個值偏高，執行和Send錯誤相同的操作，還要檢查一下如果你減低負載係數，錯誤是否跟着減少；Timeouts——超時的線程的數目，而且隨後就關閉了。如果這個值偏高，在客戶端打開一個瀏覽器，然後手工點擊站點頁面驗證是否即使只有一個用戶你的程序也會很慢。再做一個不同負載係數的壓力測試，看看程序的潛在特徵。
Result Codes
Code Description Count
================================================================================
200 OK 11058
NA HTTP result code not given 306
如果“socket”錯誤很低或爲0，在左側的報告列表中找到“Result Codes”部分。檢查一下是否所有結果代碼都是200，200表示所有請求都被服務器成功地返回。如果找到大於或等於400的結果，單擊報告列表中的 “Page Data”節點，展開所有項目，查看每個腳本項在右邊窗口頁面數據的報告，找出出現錯誤的項目。