Web壓力測試是目前比較流行的話題，利用Web壓力測試可以有效地測試一些Web服務器的運行狀態(tài)和響應時間等等，對于Web服務器的承受力測試是個非常好的手法。Web 壓力測試通常是利用一些工具，例如微軟的Web Application Stress、Linux下的siege、功能全面的Web-CT等等，這些都是非常優(yōu)秀的Web壓力測試工具。

雖然這些工具給我們測試服務器承受能力帶來方便，但是它們的危害卻更是驚人，甚至于利用隨便一種比較全面的測試工具就可以對一臺小型的 Web服務器發(fā)動災難性的拒絕式攻擊。下面我就帶大家利用微軟的Web Application Stress進行一次Web壓力測試，其目的是為了讓大家看到它的巨大危害。

一、工具簡單介紹

Microsoft Web Application Stress Tool 是由微軟的網站測試人員所開發(fā)，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的客戶端計算機仿真大量用戶上線對網站服務所可能造成的影響，在網站實際上線之前先對您所設計的網站進行如同真實環(huán)境下的測試，以找出系統(tǒng)潛在的問題，對系統(tǒng)進行進一步的調整、設置工作。就是因為這些特性，才使它具備了D.O.S轟炸的功能。

小提示：D.O.S（拒絕服務攻擊）通過使你的服務計算機崩潰或把它壓跨來阻止你提供服務。簡單來說，就是讓你的計算機提供可能多的服務從而使你的計算機陷入崩潰的邊緣或崩潰。

二、工具簡單設置

打開Web Application Stress Tool，很簡潔的一個頁面（如圖1），上面是工具欄，左下方是功能選項，右下方是詳細設置選項。在對目標Web服務器進行壓力測試之前，先對它進行一些必要的設置。

圖1

1. 在“settings”的功能設置中（如圖2），一個是Stress level (threads)這里是指定程序在后臺用多少線程進行請求，也就是相當于模擬多少個客戶機的連接，更加形象的就是說設置多少轟炸的線程數。一般填寫 500～1000，因為這個線程數是根據本機的承受力來設置的，如果你對自己的機器配置有足夠信心的話，那么設置的越高，轟炸的效果越好。
要改變并發(fā)用戶數，點Settings圖標。如果少于100個用戶，你可以直接設置Stress Level，要模擬多于100個用戶，你還須設置Stress Multiplier。基本公式為：用戶數（線程數）= Stress Level * Stress Multiplier.如果要模擬1,000個用戶，你可以設置Stress Level為100而Stress Multiplier為10。

圖2

2.在“Test Run Time”中來指定一次壓力測試需要持續(xù)的時間，分為天、小時、分、秒幾個單位級別，你根據實際情況來設置吧！

3.其余的選項不太重要，這里就不再浪費筆墨，朋友們可以自己嘗試一下設置。

三、壓力測試

工具介紹完了，下面來準備條件：這里與一個朋友商量好進行測試，他是單機上網，機器配置是CPU:Athlon XP2500+、內存512MB、硬盤80GB等，機器配置還不錯。他在機器上安裝了IIS，架設了一臺對外的Web服務器，Web服務中的程序是動網 7.0。我就利用壓力測試工具對這臺服務器進行測試。

步驟1：在工具中點右鍵，選擇Add命令，增加了一個新的測試項目：New script，對它進行設置，在主選項中的server中填寫要測試的服務器的IP地址。在下方選擇測試的Web連接方式，這里的方式Verb選擇 get，path選擇要測試的Web頁面路徑，這里填寫/Index.asp,即動網的首頁文件（如圖3）。

圖3

步驟2：在“Settings”的功能設置中將Stress level (threads)線程數設置為1000。完畢后，點工具中的灰色三角按鈕即可進行測試（如圖4）。測試完畢，等待朋友把任務管理器以及連接查看的截圖發(fā)過來！

圖4

攻擊開始后，朋友從任務管理器中可以看到CPU使用率已經達到100%，損耗率達到最大（如圖5）。在CMD窗口中使用命令netstat -an,可以看到我的IP地址在朋友服務器上的80端口進行了非常多的連接（如圖6）。而且它的Web網站已經打不開了，提示過多用戶連接，達到了跟 D.O.S攻擊一樣的目的。

圖5

圖6

試想，如果利用多臺肉雞對一臺服務器進行Web壓力測試，那么對這臺服務器來說將是滅頂之災，所以朋友們在使用它之前一定要慎重考慮。


分析測試結果
你可以點工具條上的Reports圖標來看產生的報告。這將產生一個與Script tab相臨的新的tab。報告被存儲在一個大綱視圖里。首先，在你的報告下面點Result Codes，這個將給你一個快速的印象，這次測試是否出現(xiàn)了什么問題。如果你看到的狀態(tài)代碼不是200，你也許需要調查一下出現(xiàn)了什么問題，通常的問題包括署名和不正確的URL路徑。

點Overview，你將看到這個測試活動的一個簡要快速的分析。從ASP的技術角度看，Request per Second，是一個需要深入分析的關鍵值。這個值越高越好。通常，如果你不能從使用報告和預算中決定出一個特定的目標，你可以讓ASP 的Requests per Second值高于30，當然這個ASP是沒有連數據庫或使用其他組件的。因為可以預見，連接數據庫將增加程序的負擔。

雖然有Request per Second這個計數器默認包含在WAS里，你也許想增加其他的計數器。你可以在點了Perf Counters的圖標后通過點Add Counter來增加其他的計數器。一個特別有用的計數器是ASP Requests Queued，這個計數器往往是在識別一個阻塞或長期駐留的頁面或組件時的關鍵。關于分析ASP性能的資源有：

· Tuning Internet Information Server Performance

· Navigating the Maze of Settings for Web Server Performance Optimization

· IIS 4 Resource Kit

影響性能和可測量性的因素
服務器組成，數據庫訪問，和其他因素會大大降低ASP的Request per Second值。不同的配置選擇也會起到不同的作用，在這里我要指出幾個常出現(xiàn)的因素：

· 如果你在訪問一個數據庫，你是否有做連接池？關于連接池的詳細資料請看Pooling in the Microsoft Data Access Components.

· 你是否在使用ASP Session 變量來存儲狀態(tài)？Session 變量會很快地影響可測性。它們需要服務器資源，而且如果你想增加機器以擴展性能，它們會起阻礙作用，因為Session是與特定機器相關連的。無狀態(tài)是最大化可擴展性的方法。關于Session的替代請參考這篇文章: HowTo: Persisting Values without Session.

· 你是否在Session狀態(tài)中存儲有Visual Basic的組件？現(xiàn)在就去掉它們。Session中的Visual Basic對象會導致線程相關性而且會干擾打擊IIS的線程池。這是一個復雜的主題，但是滿足它的經驗方法是：不要在Session中存儲Single-threaded Apartment (STA) objects。如果你需要在Session中保留對象，它們應該被標記為”Both”，而且你需要自己聚合這些自由線程成為一個集合。Active Template Library (ATL)可以創(chuàng)建這樣的怪物。

· 你的網絡程序是被限定運行在它自己的內存空間的嗎？實際上我們推薦進程保護。然而，如果你需要榨出一些額外的性能，在進程中運行你的網絡程序將會節(jié)省一些交叉進程集合的開銷。

· 當涉及Microsoft Transaction Server (MTS) components時，如果組件是作為服務器包而運行的而不是庫包，那么將會有明顯的性能區(qū)別。一個通常的建議是設置網絡程序在它自己的內存空間中運行，然后在庫包中運行MTS組件。

模擬多用戶的情況
我會簡要的介紹如何在WAS中模擬多用戶請求的情況。你需要做兩件事：

1. 在Settings面板改變Concurrent Connections。

2. 在Users創(chuàng)建用戶，至少要創(chuàng)建多于你在Concurrent Connections里指定的用戶數。

要改變并發(fā)用戶數，點Settings圖標。如果少于100個用戶，你可以直接設置Stress Level，要模擬多于100個用戶，你還須設置Stress Multiplier。基本公式為：用戶數（線程數）= Stress Level * Stress Multiplier.如果要模擬1,000個用戶，你可以設置Stress Level為100而Stress Multiplier為10。

如果你在沒有設置足夠的用戶前嘗試運行腳本，你將會得到一個警告。通過點Users圖標可以修改你的用戶數，你將在右邊的窗口看到一個默認的Default組。雙擊Default組展開你的用戶列表，如果你被允許匿名訪問，那么你只要簡單的填入新用戶的代碼然后點Create就可以了。

運行需要署名登錄的測試
如果你想運行需要署名登錄的頁面，那么你需要創(chuàng)建合適的用戶名和密碼以便WAS在運行時可以使用。這同樣是在Users設置的。你可以一開始就通過Remove All去掉當前的用戶列表，然后添加你需要的用戶，你也可以選擇從文本文件導入用戶名和密碼。

但是無論如何，需要確保這些用戶擁有有效的帳號，而且他們都可以訪問IIS服務器。如果你使用的是BASIC基本認證用戶帳號，你可以通過在你的瀏覽器提交證書來測試這個帳號，在文本文件寫出Request.ServerVariables("AUTH_USER")這個值將會有很大的幫助作用。我們修改后的ASP代碼將看起來是這樣的：

oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
"Time: " & Cstr(now()) & "AUTH USER: " & chr(32) & Request.ServerVariables("AUTH_USER"))
使用WAS的技巧和提示
作為結束，我會提供一些技巧和提示，還有一些經驗總結：

· 調整你的網站的日志文件的存儲,因為這個文件將會快速的增大（見IIS文檔）

· 通過設置注冊表中的HKEY_LOCAL_MACHINESoftwareMicrosoftWASSessionTrace的DWORD為1，你可以以調試的方式追蹤WAS的活動

· 如果你的WAS報告顯示錯誤,務必檢查Event Log，在工具外用瀏覽器瀏覽你的頁面，然后檢查服務器的日志：WinNTsystem32LogFilesW3SVCi

· 如果你的測試客戶端機器的處理器使用率超過了%85，你也許需要添加更多的測試客戶端

· 一些更有趣的話題會在WAS的文檔里出現(xiàn)：Page Groups, Query Strings, Cookies, Web Application Stress Object Model和Active Server Page Client (這個會讓你有能力通過Web遠程控制測試客戶端)

請注意這是個沒有技術支持的工具，發(fā)送你的問題到webtool@microsoft.com。你可以在Web Application Stress Tool這個網沾上搜索一些常見的問題。你也可以對這個工具進行編程，在同樣的網站上有對象模型的參考。