當你設置好服務器投入使用後，你最關心的事莫過於服務器的性能了。你可以用一些手動的方法進行測試，但手動方法有很多局限性。
先不論手工測試方法所投入的時間和精力問題，用手工方法測試的一大不足就是它不容易揭示出你的站點的真正問題所在，是服務器設置的問題還是因為一些動態組件又或是網絡基礎設施造成的問題？
幸運的Apache HTTP工程包含了一個名為HTTPD-Test的子工程，正如這個名稱所揭示的，這是一個Apache的通用測試工具包，這個包裡包含了大量的不同工 具，而本文將主要介紹其中一個名為洪水（Flood）的工具，它之所以如此命名，是因為它利用向服務器發出洪水般的大量請求測試服務器的響應時間。
Flood使用一個XML文件來進行必要的測試設置，包括測試中使用的URL和POST數據和准備測試的服務器組，然後Flood開始測量以下一系統操作的時間：
-
打開一個到服務器的socket
-
向socket寫入對服務器的請求
-
讀出服務器的響應
-
關閉socket
當測試結束，管理員就可以了解到是否存在Apache服務器（或其它HTTP服務器）的設置問題，服務器的實際負荷，硬件的性能表現和是否存在著網絡基礎設置瓶頸。
安裝Flood
你可以在Apache網站下載httpd-test和apr/apr-util軟件包，後者是當從Apache的CVS服務器上直接build時所需要的。你必需先進行登錄（密碼是"anoncvs"）
$ cvs -d :pserver:
[email protected]:/home/cvspublic login
$ cvs -d :pserver:
[email protected]:/home/cvspublic co httpd-test/flood
$ cd httpd-test/flood
$ cvs -d :pserver:
[email protected]:/home/cvspublic co apr
$ cvs -d :pserver:
[email protected]:/home/cvspublic co apr-util
如果你取得了源碼，你可以用下面的命令安裝：
$ buildconf
$ configure
$ make all
現在，安裝完成了。
設置Flood
Flood通 過一個XML格式的設置文件來定義測試中使用的各種參數，我們不妨通過一個形象的比喻也說明一下Flood的工作過程和需要設置的各個方面。首 先，Flood使用一個模型（pro
file）來定義一組給定的URL如何被訪問，具體的訪問由一個或多個農夫(farmer)來進行，而這些農夫又屬於 一個或多個農場(farm)，我們來看一下下面這個示意圖：
如圖所示，現在我們使用一個農場，這個農場有兩組農夫，其中農夫組Joe使用訪問模型A與一個包含五個地址的URL列表，農夫組B使用訪問模型B與一個包含 三個URL的地址列表，這些家夫直接向WEB服務器請求列表中的地址。Flood使用線程來創建各個農夫，然後比較各個農夫收集到的數據並存入一個單獨的 文件以便之後做進一步的處理。
XML文件包括了這個測試需要定義的四個方面：URL列表，訪問模型，農夫和農場。
URL列表也即一組即將被訪問的地址的列表，這些URL地址可以被簡單的引用進一步定義特定的請求方法（GET，POST，HEAD）。
訪問模型定義測試使用哪一個地址列表，它們如何被訪問，使用哪一種Socket，收集的信息如何被報告。
農夫負責實際的請求過程，對農夫唯一的可設置選項是使用哪一個訪問模型和對一個訪問模型的調用次數。每個農夫獨立的執行自己的訪問模型，但一個訪問模型可以執行多次，因此最後的請求過程可能是這樣：地址一、地址二、地址一、地址二、……。
對 家場的定義涉及到創建農夫的數目和時間，通過增加一個家場創建農夫的數目，可以增加並發請求的數目。並通一些附加的設置，你可以設置一些初始數目的農夫， 然後每隔特定的時間增加一定的農夫數量。例如，你可以開始創建兩個農夫，然後每5秒鐘增加一個農夫，直到農夫數目達到20時停止增加。這可以在一個給定的 期間形成一個最大20的並發訪問升級過程，然後又逐步將並發請求數降到0。另外也可以模擬這種訪問情況，一定數目的訪問者長時期的訪問一系列頁面，並操持 最大並發請求數在5-6之間。
注意：到寫這篇文章的時候為止，目前的Flood僅支持一個農場，而且它的名子必須是"Bingo"，不過，通過為一個農場定義多個農夫，你可以取得同樣的基本效果。
通過調節農夫，農場和URL列表的參數，你可以控制總請求數，並發請求數，測試時間（基於URL列表，重復次數和農夫的數量可以決定這一點），以及這些請求在整個測試期間的分布，這就允許你針對不同的條件訂制你的測試。
在使用Flood進行測試設置時你應該記住的三個基本點是：
-
地址列表定義了農夫們將訪問的地址
-
每個農夫的重復數目定義了一個用戶訪問你的站點的次數。
-
一個農場的農夫數目定義了並發訪問用戶的數目。
在Flood發行包裡的examples目錄下有一個樣例設置文件，round-robin.xml可能是一個最適合初學者學習的例子，不過本文並不准備就編輯此XML文件的規則或處理產生的數據文件做進一步的解說。
這裡，我們主要想講一下如何針對不同類型的WEB服務器來調整測試的參數。為了便於理解後面的內容，這裡我們先看一下使用examples目錄下的analyze-relative測試腳本得到的一個結果。在這個例子中，測試對象是一台內部服務器。
Slowest pages on average (worst 5):
Average times (sec)
connect write read close hits URL
0.0022 0.0034 0.0268 0.0280 100 http://test.mcslp.pri/java.html
0.0020 0.0028 0.0183 0.0190 700 http://www.mcslp.pri/
0.0019 0.0033 0.0109 0.0120 100 http://test.mcslp.pri/random.html
0.0022 0.0031 0.0089 0.0107 100 http://test.mcslp.pri/testr.html
0.0019 0.0029 0.0087 0.0096 100 http://test.mcslp.pri/index.html
Requests: 1200 Time: 0.14 Req/Sec: 9454.08
在這裡你可以看到測試中進行連接（connect），請求（write/request），回應（read /response），關閉連接（close）的平均時間。你也可以對服務器每稱處理的請求數目有個基本的印象。
對於新聞類站點的測試
對於如New York Times、Slashdot之類的新聞站點以及一些BLOG之類，它們都有一個主要的首頁，首頁上有著眾多到欄目頁和內容頁的連接，對某條信息感興趣的讀者可以點進去仔細閱讀。
通常情況下，這類站點的首頁訪問量相對固定而對於其它頁面，訪問量的變化就會更大一些。如果它推出了RSS/RDF訂閱服務，那麼就會出現一定量的直接到內 容頁的流量而不經過首頁。大部分的此類站點都使用了某種內容的動態化技術，而Flood是測試這類動態站點的一個不錯方法，特別你可以將之與一些靜態站的 響應相對比。
你可以用以下的參數設置模擬對一個新聞類型的網站的訪問：
Farmer Set A
Farmer Set B
Farmer Set C
URL List
Homepage Only
Homepage 3 stories
3 story pages
Repeat Count
1
3
3
Count
100
20
20
Start Count
5
5
5
Start Delay
1
5
5
Notes
Home page only
Homepage Stories
Stories only (RSS)
測試在線商店站點
在線商店，在線商品目錄或其它一些更具交互性的網站則有不同的使用模型。雖然仍會有一部分人到達你的首頁，一些人會直接進入你站內的某一個頁面，大多數用戶會在你的站裡找來找去，他們可能會在一個產品頁上浏覽大量的產品，進行一些搜索或者點擊進入一些相關的產品頁面。
因此，你應該用更大數量的地址列表測試這類站點，更大的重復次數（以模擬大量的用戶）和相對新聞類站點比較低的並發訪問數目：
Farmer Set
URL List
10-15 pages
Repeat Count
5
Count
50
Start Count
5
Start Delay
5
測試 "Slashdot" 效應
有時，你必須測試你的系統能否應付某個特定時刻大量用戶同時訪問你的網站的情況。很多網站已經遇到過這個問題，一次重大事件中對於Slashdot網站的幾個頁面的引用就引發了對這個頁面的巨量並發請求。
典型的情況下這些請求僅針對一個特殊的頁面，我們可以通過在Flood中創建成百上千的家夫來並發請求服務器上的特定頁面來模擬這種情況，通過設置高重復率和延遲系統來模擬一定時間內大量用戶的連續訪問。
Farmer Set
URL List
1 page
Repeat Count
50
Count
250
Start Count
100
Start Delay
1
測試技巧
為了讓以上各類測試都工作得很好，你應該記住以下幾點：
-
最重要的是，不要直接在WEB服務器上用Flood進行測試，如果你這樣做你僅僅是在測試一台機器打開一個網絡連接與自己通訊的能力，一定要在另一台機器上進行測試。
-
要對自己機器的一些技術限制有所了解，這包括你機器容許的最大線程數和最大網絡連接數，如果你試圖創建超過這個限制的農夫將會帶來讓人難以理解的測試結果。
-
Flood是一個客戶端解決方案，因此對於在多台機器上進行測試沒有任何限制。事實上我們推薦你這樣做，因為這是一個在想進行飽和性測試時避免你的客戶機系統的技術限制的好方法。
-
Flood測試由於是在客戶機上運行，它的表現也要依賴於客戶的性能，如果客戶機系統處於繁忙的狀態，Flood進程會與其它客戶進程一樣被阻塞，因此，最好使用一台專用的客戶機進行測試，如果客戶機上還運行著其它任務，在開始測試之前最好關掉它們。
