基於Windows下的Web效能測試和壓力測試〔轉〕

轉自：http://blog.csdn.net/mengyao/archive/2008/05/22/2468117.aspxvWeb測試

　　隨著Internet的日益普及，現在基於B/S結構的大型應用越來越多，可如何對這些應用進行測試成為日益迫切的問題。有許多測試人員來信問我B/S的測試如何做，由於工作較繁忙，對大家提出的問題也是頭痛醫頭腳痛醫腳，沒有對WEB的測試過程做一個整體的概述。希望通過本篇能夠讓大家瞭解大型Web應用是如何來進行測試的。

B/S下的功能測試比較簡單，關鍵是如何做好效能測試。目前大多數的測試人員認為只要跑一些測試載入器證明我的產品是可以達到效能的就ok了，為了證明而去測試是沒有任何價值的，關鍵是要發現產品效能上的缺陷，定位問題，解決問題，這才是測試要做的。

首先我們從兩個方面分析如何進行WEB測試，從技術實現上來講一般的B/S結構，無論是.NET還是J2EE,都是多層構架，有介面層，商務邏輯層，資料層。而從測試的流程上來說，首先是發現問題，分析問題，定位問題，再由開發人員解決問題。那麼B/S的結構的測試如何來做？

如何發現問題是我首先要介紹的，在做WEB測試之前你需要一些資料，比如產品功能說明書，效能需求說明書，不一定很完善，但一定要有，明確測試目標，這是基本的常識，可是我往往看到的是已經開始動手測了，但還不知自己的系統要達到的效能指標是什麼。這裡我簡單講一下測試的效能指標：

1、通用指標（指Web應用伺服器、資料庫伺服器必需測試項）:
* ProcessorTime: 指伺服器CPU佔用率，一般 平均達到70%時，服務就接近飽和；
* Memory Available Mbyte : 可用記憶體數，如果測試時發現記憶體有變化情況也要注意，如果是記憶體泄露則比較嚴重；
* Physicsdisk Time : 物理磁碟讀寫時間情況；

2、Web伺服器指標：
* Avg Rps: 平均每秒鐘響應次數＝總請求時間 / 秒數；
* Avg time to last byte per terstion （mstes）:平均每秒業務角本的迭代次數 ,有人會把這兩者混淆；
* Successful Rounds：成功的請求；
* Failed Rounds ：失敗的請求；
* Successful Hits ：成功的點擊次數；
* Failed Hits ：失敗的點擊次數；
* Hits Per Second ：每秒點擊次數；
* Successful Hits Per Second ：每秒成功的點擊次數；
* Failed Hits Per Second ：每秒失敗的點擊次數；
* Attempted Connections ：嘗試連結數；

3、資料庫伺服器指標：
* User 0 Connections ：使用者串連數，也就是資料庫的串連數量；
* Number of deadlocks：資料庫死結；
* Butter Cache hit ：資料庫Cache的命中情況；

上面的指標只是一些通用的指標，起到拋磚引玉的作用，對於不同的應用你還必需作相應的調整，比如程式使用的是.NET技術的，則必需加入一些針對性的測試單位。對於這些指標的詳細瞭解，你可以參考Windows 下面的 SystemMonitor的協助與LoadRunner、ACT的協助。對於發現問題，指標的設定非常重要，它會幫你定性的發現一些錯誤。對於定性的壓力測試我就不做過多的分析，工具很多，流行的主要有LoadRunner、ACT、WAS、WebLoad 各個工具有它的使用範圍；其中我各個認為：

LoadRunner 最全面，它提供了多種協議的支援，對複雜的壓力測試都可以勝任；
WAS與ACT則對微軟的支援人員的比較好，其中WAS支援分布式機群測試；
ACT則是與.NET整合比較好，支援ViewState （.NET 下控制項緩衝的支援）的測試。

在這一階段測試你要不斷的跟據係數的測試目標進行變化，一開始由於系統過於龐大，所以我們要分成若干個子系統，各個子系統的效能目標必需明確，主要是並髮指標定一個閾值，同時設定一些與系統相關的測試參數，應用伺服器，資料庫伺服器都要有，對達不到閾值的與一些通用參數有問題的子系統進行深入分析。比如它的並發達不到你的要求，證明子系統效能有問題，或是資料庫使用者串連過高，程式沒有釋放使用者串連等等。這個我們要對子系統進行詳細測試，由於B/S 結構下,圖片的請求對效能的影響較大，所以我們對子系統測試時要分兩個部分進行：
一、非程式部分，即圖片等等；
二、應用程式本身。
通過事務或函數的分離，可以把這兩塊實現單獨的測試，具體做法參考各個工具的手冊，我這裡就不做說明。對子系統的測試參數的設定要求則更高，它有助你後面精確的定位問題，比如對異常、死結、網路流量等等前面沒有注意到的情況的增加；同時你要注意增加測試參數的收集對系統的效能影響比較大，所以一般不要超過10個。剛剛介紹的整體的效能測試指標也不要增加很多，這樣影響會小一點。最後在這一階段要說明的是資料庫的資料量會很大程度的影響效能，所以要根據前面的效能需求說明書向資料庫中類比相應的資料量，來進行測試，這樣才有更高的可信度。

上面所說的是對問題的發現，下面就是分析問題原因，這一步的要求比較高，一般由測試人員與程式員配合完成，當然如果你有相當的開發經驗，再做這方面的測試，就更為難得。下面我們說說如何精確定位問題，出現問題的可能性可能有很多種，大致分以下幾種：
一、效能達不到目標；
二、效能達到目標，但有一些其它的問題，比如異常、死結。快取命中過低，網路流量較大；
三、伺服器穩定性的問題，比如記憶體流失……。

　　要發現這些問題起馬的要求要有一款使用的比較稱心的效能分析與最佳化工具，比如微軟的.NET下就有自己開發的工具，對Borland的Java開發工具中也有類似的工具，但我個人認為更好的工具是Rose下的Purify與Quantify，主要是他對.net 與java 、C++都有支援，而且分析效果特別專業。我們先瞭解一下 Rational Purify。

Rational Purify 能自動找出Visual C/C++ 和Java 代碼中與記憶體有關的錯誤，確保整個應用程式的品質和可靠性。在尋找典型的Visual C/C++ 程式中的傳統記憶體訪問錯誤，以及Java，C# 代碼中與垃圾記憶體收集相關的錯誤方面；Rational Quantity 則是一款針對函數級的效能分析利器，使用它你可以從圖形化的介面中得到函數調用的時間，百分比與次數，以及子函數所佔時間，使你可以更快的定位效能瓶頸。

我們先說效能最佳化與異常的處理，效能最佳化有一個原則 —— 即用時間比例最大的進行最佳化，效果才最明顯。比如有個函數它的執行時間為30秒，如果你最佳化了一百倍則執行時間為0.3秒，提升了29.7秒；而如果它的執行時間為0.3秒，最佳化後為0.003秒，實際提升了0.297秒，提升的效果並不明顯而且寫過程式的人都知道，後者效能最佳化的代價更大。

　　在效能最佳化的過程中，一般是先資料庫，後程式。因為資料庫的最佳化不需要修改程式，修改的風險很小。但如何才能確定是資料庫的問題，這就需要技巧，在使用Quantity時，你一路分析下去，大多數最終會發現，是資料庫查詢函數佔用時間比較大，比如什麼，SqlCmd.ExecuteNoQuery等等資料庫執行函數，這時你就需要分析資料庫，呵呵。

資料庫的分析原則是先索引，後預存程序，最後表結構視圖的最佳化。索引的最佳化是最簡單也是通常最有效方法，如果合理的使用會帶來意想不到不到的效果。在這裡我要給大家簡單的介紹一下我的最愛：SQLProfile、SQL查詢分析器。
Precise SQLProfile是一個SQL語句跟蹤器，可以跟蹤程式流程使用的SQL語句與預存程序，結合查詢分析器對SQL的分析，可以對索引的最佳化做出很好的判斷，但索引也不是萬能的，在增刪改較多的表，索引過多會引起這些操作的效能下降，所以判斷還是需要一定的經驗。同時針對使用者使用頻度最高的SQL進行最佳化也是最行之有效，這時我則需要Precise，它可以觀測某一個較長時間內的SQL語句的執行情況。

資料庫最佳化的潛能挖光後，如果還是達不到效能要求或是還有問題，則要從程式來進行最佳化，這是程式員做的事。測試人員要做的，就是告訴他們，哪個函數執行過多引起了效能下降，比如異常過多，某個迴圈過多，或是DCOM調用過多等等，但說服程式員也是一件不容易的事，你要在這一階段做的出色一定要有幾年的編程經驗，並且要讓程式員感到聽你的效能會有提升，這是一件很不容易的事情哦。

記憶體的分析，一般是一個長期分析的過程，要做好不容易，首先要有長期奮戰的準備，其次記憶體流失的分析最好是放在單元測試之中同步進行，而不是要等到最後再去發現問題，當然出了問題也只好面對，一般這類問題都是在伺服器運行了很久才暴露出來，一旦發現問題後，則需要定位問題，分析的原則採用子系統相互獨立運行，找到最小問題的系統集,或是藉助記憶體分析工具觀察記憶體對象情況，初步定位問題，再用Purify進行運行時分析，通常C++ 記憶體問題比較多，Java與.NET比較少，一般由GC不合理引起。C++的記憶體錯誤就比較多了，主要常見的有:
1、 Array Bounds Read (ABR) ：數組越界讀
2、 Array Bounds Write (ABW)：數組越界寫
3、 Beyond stack Read (BSR)：堆棧越界讀
4、 Free Memory Read(FMR)：空閑記憶體讀
5、 Invalid pointer Read(IPR)：非法指標閱讀
6、 Null Pointer Read(NPR)： null 指標閱讀
7、 Uninitialized Memory Read(UMR)：未初始化記憶體讀寫　　
8、 Memory Leak：記憶體流失
註：如果需要更多的資訊，可以參見Purify的協助資訊。
順便提一句，為什麼我要說做單元測試時做記憶體分析比較好，由於單元測試針對的是單一功能，這時結合單元測試案例做記憶體分析會更快的定位問題，同時由於問題較早的發現，則後期的風險則會減少，當然如果結合代碼覆蓋工具PureCoverage 來做就更完美了。
註：本篇只是對B/S應用的測試過程作一個整體的描述，對某一個階段使用的工具只是作大概的介紹，你也可使用你比較熟悉的工具達到相同的目標。

效能管理

說到Windows環境下的效能管理，許多人首先想到的可能就是無處不在的Performance Monitor工具。早在Windows NT時代，Performance Monitor就是擷取效能資訊的主要工具，當然，工作管理員和Windows管理規範（Windows Management Instrumentation）也屬於常用工具之列，它們不僅能夠提供效能資料，而且還能提供其他與效能有關的管理資訊。本文介紹了一些充分發揮這些經典工具潛能的技巧，同時介紹了Windows XP新增的工具，探討如何運用它們來評估系統的效能情況。

一、什麼是效能管理？

　　對於許多管理員來說，Windows的效能管理不外乎開啟控制台→管理工具中的“效能”程式，即Performance Monitor程式，然後檢查一下CPU利用率、磁碟忙閑狀況、記憶體壓力，而且通常只有在出現效能問題時才會去檢查，例如伺服器響應突然變慢，或者使用者不能訪問伺服器。這種效能管理方式完全屬於事後補救的方式，只起到了救火隊員的作用，由於缺乏詳盡、明確的事前評估、規劃，算不上優秀的策略。要實現有效效能管理，一定要在出現問題之前掌握系統的效能情況。

　　只有事先採取有效效能管理原則，才能全面掌握系統的效能特徵，在此基礎上，就可以估計何時可能出現效能問題以及問題的具體表現。預先收集的效能資料還可以用來規劃未來的運算能力需求，例如，假設有一個IIS Web伺服器，當並發使用者數量是200時CPU的利用率是60%，據此可以推斷系統負載何時達到極限，以及達到負載極限時能夠支援的並發使用者數量。另外，根據網站的增長情況，還可以估計出何時需要增添硬體裝置。

　　系統的整體效能由許多因素決定，例如CPU利用率，CPU隊列長度（即，有多少任務正在等待CPU的服務），磁碟忙閑程度（即，磁碟機有多少時間用於響應請求），可用的實體記憶體，網路介面的利用情況，等等，表一概括了最常用的效能計數器。

 

 

表一：重要的效能計數器
效能物件	計數器	提供的資訊
Memory	Available Bytes	Available Bytes顯示出當前閒置實體記憶體總量。當這個數值變小時，Windows開始頻繁地調用磁碟分頁檔。如果這個數值很小，例如小於5 MB，系統會將大部分時間消耗在操作分頁檔上。
Memory	% Committed Bytes in Use	% Committed Bytes In Use 是 Memory: Committed Bytes 與Memory: Commit Limit之間的比值。(Committed memory指如果需要寫入磁碟時已在分頁檔案中保留空間的處於使用中的實體記憶體。Commit Limit是由分頁檔案的大小而決定的。如果擴大了分頁檔案，該比例就會減小)。這個計數器只顯示當前百分比；而不是一個平均值。
Memory	Page Faults/sec	Page Faults/sec是指處理器處理錯誤頁的綜合速率。用錯誤頁數/秒來計算。當處理器請求一個不在其工作集(在實體記憶體中的空間)內的代碼或資料時出現的頁錯誤。這個計數器包括硬性錯誤(那些需要磁碟訪問的)和軟性錯誤(在實體記憶體的其它地方找到的錯誤頁)。許多處理器可以在有大量軟性錯誤的情況下繼續操作。但是，硬性錯誤可以導致明顯的拖延。這個計數器顯示用上兩個執行個體中觀察到的值之間的差除以執行個體間隔的期間所得的值。
Network Interface	Bytes Total/sec	Bytes Total/sec是發送和接收位元組的速率，包括幀字元在內。
Network Interface	Packets/sec	Packets/sec為發送和接收資料包的速率。
Physical Disk	% Busy Time	% Busy Time指磁碟機忙於為讀或寫入請求提供服務所用的時間的百分比。
Physical Disk	Avg. Disk Queue Length	Avg. Disk Queue Length 指讀取和寫入請求(為所選磁碟在執行個體間隔中列隊的)的平均數。
Physical Disk	Current Disk Queue Length	Current Disk Queue Length指在收集操作資料時在磁碟上未完成的請求的數目。它包括在快照記憶體時正在為其提供服務中的請求。這是一個即時間長度度而非一定間隔時間的平均值。多主軸磁碟裝置可以一次有多個請求操作，但是其它同時發生的請求為等候服務。這個計數器可能會反映一個暫時的高或低的列隊長度，但是如果在磁碟機存在持續負載，可能值會總是很高。請求等待時間與這個列隊的長度減去磁碟上的主軸成正比。這個差值應小於2才能保持良好的效能。
Processor	% Processor Time	% Processor Time指處理器執行非閑置線程時間的百分比。這個計數器設計成用來作為處理器活動的主要指標。它通過在每個範例間隔中衡量處理器用於執行閑置處理線程的時間，並且用100%減去該值得出。(每個處理器有一個閑置線程，該線程在沒有其它線程可以運行時消耗周期)。可將其視為範例間隔用於做有用工作的百分比。
Processor	% User Time	% User Time指用於使用者模式的非閑置處理器時間的百分比(使用者模式是為應用程式、環境分系統和整數分系統設計的有限處理模式。另一個模式為特權模式，它是為作業系統組件設計的並且允許直接存取硬體和所有記憶體。作業系統將應用程式線程轉換成特權模式以訪問作業系統服務)。這個計數值將平均忙時作為執行個體時間的一部分顯示。
Server Work Queues	Queue Length	Queue Length指CPU當前的伺服器作業隊列長度。隊列長度長時間超過四可能表示處理器堵塞。此值為即時計數，不是一段時間的平均值。
System	Processor Queue Length	Processor Queue Length是指處理隊列中的線程數。即使在有多個處理器的電腦上處理器時間也會有一個單隊列。不象磁碟計數器，這個計數器僅計數就緒的線程，而不計數運行中的線程。如果處理器隊列中總是有兩個以上的線程通常表示處理器堵塞。這個計數器僅顯示上一次觀察的值；而不是一個平均值。
TCP	Segments Retransmitted/sec	Segments Retransmitted/sec指程式段重新傳輸的速率，即傳輸的程式段中包含一個或多個以前傳輸過的位元組。

 

二、定製效能監控器

　　在Windows 2K/XP中，Performance Monitor仍是最常用的效能管理工具。當然，新版的工具不少地方已經改進，增添了不少功能。在Win 2K中，效能監控器以一個管理主控台（MMC）單元的形式實現。啟動Win 2K/XP的效能監控器，可以看到類似圖一的介面。

 

圖一

　　在Win XP中，效能監控器預設裝入三個計數器：Pages/sec，Avg. Disk Queue Length，% Processor Time。這三個計數器無法直接刪除，但一直留著又降低了監視器啟動速度。如果要讓監視器啟動時不裝入任何計數器。（讓監視器啟動時不裝入任何計數器）首先要清除\%systemroot%\system32目錄下perfmon.msc檔案的唯讀屬性：進入命令視窗，轉到system32目錄，執行命令attrib r perfmon.msc。然後重新啟動計數器，選中一個計數器，點擊工具列上黑色的“X”按鈕即可刪除一個計數器。選擇菜單“檔案”→“儲存”，將更改後的管理主控台儲存到磁碟。如果要將管理主控台執行標記成唯讀，只需在命令列上執行attrib +r perfmon.msc即可。

　　在NT 4.0中，效能監控器包含一個即時圖表，另外還有記錄日誌和警示功能，但在Win 2K和XP的中，這些功能分開了。在Win 2K/XP中，即時效能圖表變成了“系統監視器”，系統監視器之下是日誌和警報工具。系統監視器可以看作一個純粹的即時效能資料察看工具，只能看，不能儲存，點擊工具列上的“+”按鈕可以添加新的效能計數器。效能記錄檔及警示工具則具有操作曆史資料的功能。

　　如果要建立一個只有系統監視器、不帶效能記錄檔及警示工具的管理主控台，可按如下步驟操作：執行“MMC”命令，開啟一個空白的MMC視窗，選擇菜單“檔案”→“添加/刪除嵌入式管理單元”，點擊“添加”，選擇“ActiveX控制項”，再點擊“添加”，在嚮導中選擇System Monitor Control，確認即可。

 

三、效能記錄檔及警示工具

　　系統監視器只能簡單地查看即時效能資料，如果需要長期的、持久化的效能資料，必須使用效能記錄檔及警示工具。效能日誌工具能夠在一個記錄檔中集中記錄來自本地或遠端多個系統的效能資料，這些日誌資料可以用系統監視器查看或用其他工具處理。擴充控制台中的“效能記錄檔及警示”節點，可以看到它的三個分支：計數器日誌，追蹤記錄檔，警報。警報工具的功能很簡單，就是當某個計數器的效能資料達到指定的值時，執行一定的動作，例如發送Email或用Net Send命令發送訊息。下面我們主要討論的是日誌工具。

　　為了說明如何使用計數器日誌，我們要建立一個日誌會話。右擊“計數器日誌”節點，選擇“建立日誌設定”，指定日誌設定的名稱，點擊“確定”，出現圖二的對話方塊，在這裡設定要在日誌中記錄的計數器。

 

圖二

　　記錄檔的預設儲存路徑是C:\perflogs目錄，可以在對話方塊的“記錄檔”頁修改，但首先要設定待記錄的對象和計數器才能轉到“記錄檔”頁。點擊“添加對象”按鈕，將某個監視對象的所有計數器加入日誌記錄，或者點擊“添加計數器”按鈕加入單個計數器。無論選擇哪種加入選項，監視目標（對象或計數器）都可以是本地的，也可以是遠程機器的。

　　如果要長期收集效能資料，最好調整一下採樣間隔時間——特別地，如果要監視的計數器很多，而且來自不同的機器，如果採樣間隔時間設定得太小，記錄檔很快會變得很大。從每隔15分鐘採樣一次開始，試運行一段時間，看看記錄檔變得多大了，然後再作相應的調整。

　　如果要串連遠程機器，可以在“運行方式”輸入框提供登入遠程機器的使用者名稱字。

　　收集效能監控資料需要一定的許可權，HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib註冊子鍵控制著對效能監控資料的訪問，效能監控資料正是通過該註冊子鍵流到系統監視器之類的工具。用右鍵點擊該註冊子鍵，選擇菜單“許可權”，三，調整這裡的許可權分配也就調整了有權訪問效能資料的使用者。

 

圖三

 

設定好要監視的對象和計數器之後，可以在“記錄檔”頁調整記錄檔的格式，在“計劃”頁設定啟動、停止日誌的時間。如果設定成手工啟動，啟動方式是在MMC視窗中右擊日誌會話並選擇“啟動”。

　　在“記錄檔”頁中，四，效能計數器日誌除了預設的二進位.blg格式之外，還可以儲存為其他多種格式，例如逗號分隔的文字檔（即CSV檔案），甚至還可以儲存到SQL Server表——這是Windows Server 2003和XP才有的功能。如果選擇了SQL Server，還要指定一個SQL Server資料來源和儲存資料的表，雖然麻煩一點，不過如果要收集大量的效能資料並進行分析，SQL Server還是一種不錯的選擇。

 

圖四

　　開機記錄之後，可以看到日誌目錄中產生了一個65 KB的記錄檔。每次關閉和重新開機記錄，都會產生一個新的記錄檔，檔案名稱字中的序號依次增加。Win XP和2K支援一項非常實用的功能，即使在效能監控器工具不啟動並執行時候，也能繼續將效能資料寫入日誌。如果是NT 4.0，則需要安裝NT 4.0 Resource Kit的DataLog服務才能使用這個無人值守日誌記錄功能。Win 2K和XP本身就有Performance Logs and Alerts服務，該服務在日誌會話啟動時自動啟動，日誌會話結束時自動停止。

　　Win 2K/XP效能日誌的另一個改進之處是儲存日誌會話功能。在NT 4.0中，如果要為某個日誌會話重新使用一組選定的效能物件和計數器，必須為每一台想要監視的伺服器重新建立工作台檔案，如果要將一組日誌配置分別在多台伺服器上本地運行，必須重複執行繁瑣的配置操作。但在Win 2K/XP中，所有設定檔（包括日誌和警報）都以HTML檔案的形式儲存，很容易修改和重用。要儲存一個日誌會話配置，只要在MMC視窗中右擊會話，然後選擇菜單“將設定另存新檔”即可。

　　四、命令列工具

　　XP提供了一個叫做Logman的新工具，它不僅能夠在命令列上啟動和停止日誌會話，而且能夠從命令列建立新的日誌會話。

　　例如，下面的第一Logman命令建立了一個iislogging會話，記錄檔儲存在預設c:\perflogs\IISLogging.blg，日誌中加入了本機伺服器上inetinfo.exe進程的Process\% Processor Time計數器，收集效能資料的時間間隔是15分鐘。第二個命令啟動了iislogging日誌會話。運行這些命令之後，如果啟動MMC效能監控工具，可以看到計數器日誌中已經列出了剛才建立的日誌會話。

logman create counter iislogging -c "\Process(inetinfo)\% Processor Time" -si 15:00logman start iislogging

用Logman的-s選項可以啟動遠程機器上的日誌，使用形式類如“-s \\ServerName”。使用該選項時，Logman啟動的日誌將在遠程伺服器上運行，而不是執行Logman命令的本地機器。

　　五、WMIC

　　WMIC即Windows管理規範的命令列工具，在命令上執行執行wmic，即可啟動WMIC環境。第一次執行wmic命令時，WMIC首先把自己安裝到WMI名稱空間。雖然微軟推出WMIC的意圖是簡化WMI的使用，不過WMIC的命令列文法還是顯得比較複雜。WMIC依靠別名來描述經常要訪問的WMI類，例如，WMIC的別名pagefile相當於WMI查詢Select * from Win32_PageFileUsage，如果在wmic提示符下輸入pagefile命令，WMIC將顯示出當前的分頁檔使用方式。

　　遺憾的是，WMIC沒有為基於WMI的效能監控資料提供別名，所以要查詢效能監控器資料，必須直接調用相應的WMI類。例如，如果要查看伺服器當前的實體記憶體使用方式，可以在WMIC命令列上執行path win32_perfformatteddata_perfos_memory，該命令要求WMIC返回WMI類win32_perfformatteddata_perfos_memory的資料，輸出結果包含了指定WMI記憶體對象的每一個屬性。如果只想查看Available Bytes屬性，可以將命令改為path win32_perfformatteddata_perfos_memory get AvailableBytes。

　　另外，WMIC命令還可以從Windows命令列直接執行，例如，要查看Available Bytes，可以執行wmic path win32_perfformatteddata_perfos_memory get AvailableBytes命令，如果要返回多個屬性值，只要依次列出各個屬性，屬性之間用逗號分隔，例如“AvailableBytes,AvailableMBytes,CacheBytes”。

　　那麼，如何獲得各種效能監控器計數器的WMI類名稱呢？最好的辦法是使用WMI Tools。WMI Tools是微軟提供的一個免費工具，可以從http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=6430F853-1120-48DB-8CC5-F2ABDC3ED314下載，五所示，它能夠清楚地顯示出各個類的名稱、屬性、方法。

 

圖五

　　在多層應用環境中，如果要尋找效能瓶頸的具體位置，效能監控資料無疑是極其寶貴的依據，只要充分運用Win 2K/XP提供的效能工具，我們可以構造出功能豐富的效能管理系統。

使用Microsoft Web Application Stress 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壓力測試，那麼對這台伺服器來說將是滅頂之災，所以朋友們在使用它之前一定要謹慎考慮。

v