使用WAS Tool對web進行壓力測試

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

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

一、工具簡單介紹

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

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

二、工具簡單設置

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

 

圖1


 

1.     在“settings”的功能設置中(如圖2),一個是Stress level (threads)這裏是指定程序在後臺用多少線程進行請求,也就是相當於模擬多少個客戶機的連接,更加形象的就是說設置多少轟炸的線程數。一般填寫500~1000,因爲這個線程數是根據本機的承受力來設置的,如果你對自己的機器配置有足夠信心的話,那麼設置的越高,轟炸的效果越好。

 

圖2

 

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

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)。測試完畢,等待朋友把任務管理器以及連接查看的截圖發過來!

 

圖4

 

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

 

圖5

圖6

 

試想,如果利用多臺肉雞對一臺服務器進行Web壓力測試,那麼對這臺服務器來說將是滅頂之災,所以朋友們在使用它之前一定要慎重考慮。
l另使用:
製作WAS腳本是相當簡單的,不過要製作出模擬真實用戶活動的腳本有點兒複雜。如果你已經有一個運行的Web網站,可以使用Web服務器的日誌來確定Web網站上的用戶點擊分佈。如果你的應用還沒有開始運行,那麼只好根據經驗作一些猜測了。我們假定有30個會員在瀏覽書店,同時又有一個會員正在購買。要模擬兩者混合而成的行爲,首先必須創建頁面組並在腳本的Page Group分枝確定點擊分佈情況。在Page Group分枝中我們可以增加、修改或刪除頁面組,也可以爲各個組修改流量的分佈。
創建了頁面組之後,我們就可以在主腳本視圖中賦予各個請求不同的頁面組,如圖3所示。爲每個請求指定頁面組相當於告訴WAS如何分佈流量。記住在本例中對grp_buy組頁面的請求約佔總數的3%,而對grp_browse組頁面的請求約佔97%。
如果網站提供個性化服務,要進行身份驗證或使用Cookies,我們還要爲WAS提供一個用戶目錄。WAS中的用戶存儲了發送給服務器的密碼以及服務器發送給客戶端的Cookies。增加用戶數量並不增加Web服務器的負載。必須提供足夠數量的用戶以滿足併發連接的要求(Stesss Level乘以Stress Multiplier)。Stress Level和Stress multiplier這二個項決定了訪問服務器的併發連接的數量。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章