微軟Web應(yīng)用負載測試工具WAS教程

1、微軟Web應(yīng)用負載測試工具WAS教程 來源：E網(wǎng)中國 作者：Liuhui 發(fā)布時間：2007-07-20   你的Web服務(wù)器和應(yīng)用到底能夠支持多少并發(fā)用戶訪問？在出現(xiàn)大量并發(fā)請求的情況下，軟件會出現(xiàn)問題嗎？這些問題靠通常的測試手段是無法解答的。本文介紹了Microsoft為這個目的而提供的免費工具WAS及其用法。另外，本文介紹了一種Web應(yīng)用的性能優(yōu)化方法，并利用WAS測試了它的性能改善程度。原文出處：編譯如下：隨著服務(wù)器端處理任務(wù)的日益復(fù)雜以及網(wǎng)站訪問量的迅速增長，服務(wù)器性能的優(yōu)化也成了非常迫切的任務(wù)。在優(yōu)化之前，最好能夠測試一下不同條件下服務(wù)器的性能表現(xiàn)。找出性能瓶頸所在是設(shè)計

2、性能改善方案之前的一個至關(guān)緊要的步驟。 本文介紹Microsoft的Web Application Stress Tool（WAS，Web應(yīng)用負載測試工具）在Web服務(wù)器性能測試中的應(yīng)用（注：Stress基本含義為“重壓；壓力”等，本文稱之為“負載”）。另外，我們還將通過WAS評估一種相對簡單的網(wǎng)站性能改善方法，這種方法的基本思想是在服務(wù)器上生成靜態(tài)的HTML頁面、避免過多的數(shù)據(jù)庫調(diào)用。 負載測試是任何Web應(yīng)用的開發(fā)周期中一個重要的步驟。如果你在構(gòu)造一個為大量用戶服務(wù)的應(yīng)用，搞清楚你的產(chǎn)品配置能夠承受多大的負載非常重要。如果你在構(gòu)造一個小型的Intranet網(wǎng)站，測試能夠暴露出最終會導(dǎo)致服務(wù)

3、器崩潰的內(nèi)存漏洞以及競爭情況。 無論是哪種情形，花些時間對應(yīng)用進行負載測試可以獲得重要的基準性能數(shù)據(jù)，為未來的代碼優(yōu)化、硬件配置以及系統(tǒng)軟件升級帶來方便。即使經(jīng)費有限的開發(fā)組織也可以對它們的網(wǎng)站進行負載測試，因為Microsoft的WAS是可以免費下載的。WAS要求Windows NT 4.0 SP4或者更高，或者Windows 2000。為了對網(wǎng)站進行負載測試，WAS可以通過一臺或者多臺客戶機模擬大量用戶的活動。WAS支持身份驗證、加密和Cookies，也能夠模擬各種瀏覽器類型和Modem速度，它的功能和性能可以與數(shù)萬美元的產(chǎn)品相媲美。如果你對WAS和Microsoft的另外一個測試工具We

4、b Capacity Analysis Tool （WCAT）之間的差別感興趣，可以訪問Microsoft Web工具的比較頁面。 要對網(wǎng)站進行負載測試首先必須創(chuàng)建WAS腳本模擬用戶活動。我們可以用下面四種方法之一創(chuàng)建腳本：通過記錄瀏覽器的活動；通過導(dǎo)入IIS日志；通過把WAS指向Web網(wǎng)站的內(nèi)容；或者手工制作。圖1所顯示的是通過記錄瀏覽器事件生成的腳本的一部分，網(wǎng)站是Microsoft的Duwamish Book Store。Duwamish是Microsoft開發(fā)的電子商務(wù)Web應(yīng)用示例，從Duwamish網(wǎng)站的“Phase 4”鏈接可以下載這個軟件包。下載包中包含了它自己的WAS測試腳本

5、。        【圖1】        制作WAS腳本是相當簡單的，不過要制作出模擬真實用戶活動的腳本有點兒復(fù)雜。如果你已經(jīng)有一個運行的Web網(wǎng)站，可以使用Web服務(wù)器的日志來確定Web網(wǎng)站上的用戶點擊分布。如果你的應(yīng)用還沒有開始運行，那么只好根據(jù)經(jīng)驗作一些猜測了。 圖1這個腳本中我們假定有30個會員在瀏覽書店，同時又有一個會員正在購買。要模擬兩者混合而成的行為，首先必須創(chuàng)建頁面組并在腳本的Page Group分枝確定點擊分布情況。在Page Group分枝中我們可以增加、

6、修改或刪除頁面組，也可以為各個組修改流量的分布。 圖2顯示了grp_browse和grp_buy這兩個頁面組以及30比1的流量分布。        【圖2】       創(chuàng)建了頁面組之后，我們就可以在主腳本視圖中賦予各個請求不同的頁面組，如圖3所示。為每個請求指定頁面組相當于告訴WAS如何分布流量。記住在本例中對grp_buy組頁面的請求約占總數(shù)的3%，而對grp_browse組頁面的請求約占97%。 主機之家     

7、60; 【圖3】       如果需要在查詢字符串中傳遞“名字-值”對，可以用WAS的查詢字符串編輯器來定義各個變量的所有可能的值。在輸入變量值后，既可以要求WAS順序地使用變量的各個值，也可以要求WAS在請求時隨機選擇變量值。這在一定程度上增加了腳本所模擬行為的真實性，也可以幫助避免緩沖對測試結(jié)果的影響準備好測試腳本之后，我們可以調(diào)整測試配置以便觀察不同條件下的應(yīng)用性能。圖4是WAS的設(shè)置界面。         【圖4】   

8、0;   Stress Level和Stress multiplier這二個項決定了訪問服務(wù)器的并發(fā)連接的數(shù)量。Microsoft建議不要選擇超過100的Stress Level值。如果要模擬的并發(fā)連接數(shù)量超過100個，可以調(diào)整Stress multiplier或使用多個客戶機。在負載測試期間WAS將通過DCOM與其他客戶機協(xié)調(diào)。有關(guān)在測試中使用多個客戶機的更多信息，參見。 如果網(wǎng)站提供個性化服務(wù)，要進行身份驗證或使用Cookies，我們還要為WAS提供一個用戶目錄。WAS中的用戶存儲了發(fā)送給服務(wù)器的密碼以及服務(wù)器發(fā)送給客戶端的Cookies。增加用戶數(shù)量并不增加Web服務(wù)

9、器的負載。必須提供足夠數(shù)量的用戶以滿足并發(fā)連接的要求（Stesss Level乘以Stress Multiplier）。有關(guān)線程、用戶、Cookies相互作用的更多信息請參見。 WAS允許設(shè)置warmup（熱身）時間，一般可以設(shè)置為1分鐘。在warmup期間WAS開始執(zhí)行腳本，但不收集統(tǒng)計數(shù)據(jù)。warmup時間給MTS、數(shù)據(jù)庫以及磁盤緩沖等一個機會來做準備工作。如果在warmup時間內(nèi)收集統(tǒng)計數(shù)據(jù)，這些操作的開銷將影響性能測試結(jié)果。 設(shè)置頁面提供的另外一個有用的功能是限制帶寬（throttle bandwidth）。帶寬限制功能能夠為測試模擬出Modem（14.k K，28.8 K，56 K）

10、、ISDN（64 K，128 K）以及T1（1.54 M）的速度。使用帶寬限制功能可以精確地預(yù)測出客戶通過撥號網(wǎng)絡(luò)或其他外部連接訪問Web服務(wù)器所感受的性能。 要理解這些不同的設(shè)置對應(yīng)用的影響，有必要了解如何使用WAS收集性能數(shù)據(jù)。 使用WAS，從遠程Windows NT和Windows 2000機器獲取和分析性能計數(shù)器（Performance Counter）是很方便的。加入計數(shù)器要用到圖5所示的Perf Counters分枝。 主機之家        【圖5】      

11、 在測試中選擇哪些計數(shù)器顯然跟測試目的有關(guān)。雖然下面這個清單不可能精確地隔離出性能瓶頸所在，但對一般的Web服務(wù)器性能測試來說卻是一個好的開始。        · 處理器：CPU使用百分比（% CPU Utilization）        · 線程：每秒的上下文切換次數(shù)（Context Switches Per Second (Total)）        · ASP：每秒請求數(shù)量（R

12、equests Per Second）        · ASP：請求執(zhí)行時間（Request Execution Time）        · ASP：請求等待時間（Request Wait Time）        · ASP：置入隊列的請求數(shù)量（Requests Queued） CPU使用百分比反映了處理器開銷。CPU使用百分比持續(xù)地超過75%是性能瓶頸在于處理器的一個明顯的跡象。

13、每秒上下文切換次數(shù)指示了處理器的工作效率。如果處理器陷于每秒數(shù)千次的上下文切換，說明它忙于切換線程而不是處理ASP腳本。 主機之家每秒的ASP請求數(shù)量、執(zhí)行時間以及等待時間在各種測試情形下都是非常重要的監(jiān)測項目。每秒的請求數(shù)量告訴我們每秒內(nèi)服務(wù)器成功處理的ASP請求數(shù)量。執(zhí)行時間和等待時間之和顯示了反應(yīng)時間，這是服務(wù)器用處理好的頁面作應(yīng)答所需要的時間。 我們可以繪出隨著測試中并發(fā)用戶數(shù)量的增加每秒請求數(shù)量和反應(yīng)時間的變化圖。增加并發(fā)用戶數(shù)量時每秒請求數(shù)量也會增加。然而，我們最終會達到這樣一個點，此時并發(fā)用戶數(shù)量開始“壓倒”服務(wù)器。如果繼續(xù)增加并發(fā)用戶數(shù)量，每秒請求數(shù)量開始下降，而反應(yīng)時間則會增

14、加。要搞清楚硬件和軟件的能力，找出這個并發(fā)用戶數(shù)量開始“壓倒”服務(wù)器的臨界點非常重要。 置入隊列的ASP請求數(shù)量也是一個重要的指標。如果在測試中這個數(shù)量有波動，某個COM對象所接收到的請求數(shù)量超過了它的處理能力。這可能是因為在應(yīng)用的中間層使用了一個低效率的組件，或者在ASP會話對象中存儲了一個單線程的單元組件。 運行WAS的客戶機CPU使用率也有必要監(jiān)視。如果這些機器上的CPU使用率持續(xù)地超過75%，說明客戶機沒有足夠的資源來正確地運行測試，此時應(yīng)該認為測試結(jié)果不可信。在這種情況下，測試客戶機的數(shù)量必須增加，或者減小測試的Stress Level。 每次測試運行結(jié)束后WAS會生成詳細的報表，即

15、使測試被提前停止也一樣。WAS報表可以從View菜單選擇Reports查看。下面介紹一下報表中幾個重要的部分。 如果這是一個新創(chuàng)建的測試腳本，你應(yīng)該檢查一下報表的Result Codes部分。這部分內(nèi)容包含了請求結(jié)果代碼、說明以及服務(wù)器返回的結(jié)果代碼的數(shù)量。如果這里出現(xiàn)了404代碼（頁面沒有找到），說明在腳本中有錯誤的頁面請求。 頁面摘要部分提供了頁面的名字，接收到第一個字節(jié)的平均時間（TTFB），接收到最后一個字節(jié)的平均時間（TTLB），以及測試腳本中各個頁面的命中次數(shù)。TTFB和TTLB這兩個值對于計算客戶端所看到的服務(wù)器性能具有重要意義。TTFB反映了從發(fā)出頁面請求到接收到應(yīng)答數(shù)據(jù)第一個

16、字節(jié)的時間總和（以毫秒計），TTLB包含了TTFB，它是客戶機接收到頁面最后一個字節(jié)所需要的累計時間。 報表中還包含了所有性能計數(shù)器的信息。這些數(shù)據(jù)顯示了運行時各個項目的測量值，同時還提供了最大值、最小值、平均值等。報表實際提供的信息遠遠超過了我們這里能夠介紹的內(nèi)容。為了給你一個有關(guān)表所提供信息種類的印象，圖6摘錄了一個報表實例。            【圖6】       隨著Internet應(yīng)用的日益廣泛，用戶的要求和期望也在不斷地發(fā)展。今天的客戶期待

17、個性化的可定制的方案，期待這些方案不僅簡單，而且快速、可靠、成本低廉。對于能夠適應(yīng)用戶需求不斷變動的可定制頁面來說，靜態(tài)HTML已經(jīng)退出了舞臺，比如內(nèi)容根據(jù)客戶請求變化的頁面就是其中一例。這一切都要求系統(tǒng)保存相關(guān)的數(shù)據(jù)，例如有關(guān)用戶本身以及用戶可能請求哪些信息的數(shù)據(jù)。 緊跟這些趨勢的Web開發(fā)者已經(jīng)開始提供可定制的Web網(wǎng)站。象搜索數(shù)據(jù)之類的任務(wù)現(xiàn)在可以由服務(wù)器執(zhí)行而無需客戶干預(yù)。然而，這些變革也導(dǎo)致了一個結(jié)果，這就是許多網(wǎng)站都在使用大量的未經(jīng)優(yōu)化的數(shù)據(jù)庫調(diào)用，從而使得應(yīng)用性能大打折扣。 我們可以使用以下幾種方法來解決這些問題：      &#

18、160; 1. 優(yōu)化ASP代碼。        2. 優(yōu)化數(shù)據(jù)庫調(diào)用。        3. 使用存儲過程。        4. 調(diào)整服務(wù)器性能。 優(yōu)秀的網(wǎng)站設(shè)計都會關(guān)注這些問題。然而，與靜態(tài)頁面的速度相比，任何數(shù)據(jù)庫調(diào)用都會顯著地影響Web網(wǎng)站的響應(yīng)速度，這主要是因為在發(fā)送頁面之前必須單獨地為每個訪問網(wǎng)站的用戶進行數(shù)據(jù)庫調(diào)用。 這里提出的性能優(yōu)化方案正是基于以下事實：訪問靜態(tài)HTML頁面要比訪問那些內(nèi)容依賴于數(shù)據(jù)庫調(diào)

19、用的頁面要快。它的基本思想是：在用戶訪問頁面之前，預(yù)先從數(shù)據(jù)庫提取信息寫入存儲在服務(wù)器上的靜態(tài)HTML頁面。為了保證這些靜態(tài)頁面能夠及時地反映不斷變化的數(shù)據(jù)庫數(shù)據(jù)，必須有一個調(diào)度程序管理靜態(tài)頁面的生成。 當然，這種方案并不能夠適應(yīng)所有的情形。例如，如果是從持續(xù)變化的大容量數(shù)據(jù)庫提取少量信息，這種方案是不合適的。不過可以適用該方案的場合還是很多。 為了保證能夠在合適的時間更新靜態(tài)HTML頁面，把下面的代碼加入到相應(yīng)的ASP頁面前面：隨著Internet應(yīng)用的日益廣泛，用戶的要求和期望也在不斷地發(fā)展。今天的客戶期待個性化的可定制的方案，期待這些方案不僅簡單，而且快速、可靠、成本低廉。對于能夠適應(yīng)用

20、戶需求不斷變動的可定制頁面來說，靜態(tài)HTML已經(jīng)退出了舞臺，比如內(nèi)容根據(jù)客戶請求變化的頁面就是其中一例。這一切都要求系統(tǒng)保存相關(guān)的數(shù)據(jù)，例如有關(guān)用戶本身以及用戶可能請求哪些信息的數(shù)據(jù)。 緊跟這些趨勢的Web開發(fā)者已經(jīng)開始提供可定制的Web網(wǎng)站。象搜索數(shù)據(jù)之類的任務(wù)現(xiàn)在可以由服務(wù)器執(zhí)行而無需客戶干預(yù)。然而，這些變革也導(dǎo)致了一個結(jié)果，這就是許多網(wǎng)站都在使用大量的未經(jīng)優(yōu)化的數(shù)據(jù)庫調(diào)用，從而使得應(yīng)用性能大打折扣。 我們可以使用以下幾種方法來解決這些問題：        1. 優(yōu)化ASP代碼。     &

21、#160;  2. 優(yōu)化數(shù)據(jù)庫調(diào)用。        3. 使用存儲過程。        4. 調(diào)整服務(wù)器性能。 優(yōu)秀的網(wǎng)站設(shè)計都會關(guān)注這些問題。然而，與靜態(tài)頁面的速度相比，任何數(shù)據(jù)庫調(diào)用都會顯著地影響Web網(wǎng)站的響應(yīng)速度，這主要是因為在發(fā)送頁面之前必須單獨地為每個訪問網(wǎng)站的用戶進行數(shù)據(jù)庫調(diào)用。 這里提出的性能優(yōu)化方案正是基于以下事實：訪問靜態(tài)HTML頁面要比訪問那些內(nèi)容依賴于數(shù)據(jù)庫調(diào)用的頁面要快。它的基本思想是：在用戶訪問頁面之前，預(yù)先從數(shù)據(jù)庫提取信息寫入存儲在服務(wù)

22、器上的靜態(tài)HTML頁面。為了保證這些靜態(tài)頁面能夠及時地反映不斷變化的數(shù)據(jù)庫數(shù)據(jù)，必須有一個調(diào)度程序管理靜態(tài)頁面的生成。 當然，這種方案并不能夠適應(yīng)所有的情形。例如，如果是從持續(xù)變化的大容量數(shù)據(jù)庫提取少量信息，這種方案是不合適的。不過可以適用該方案的場合還是很多。 為了保證能夠在合適的時間更新靜態(tài)HTML頁面，把下面的代碼加入到相應(yīng)的ASP頁面前面：          每當該頁面被調(diào)用，腳本就會提取最后的更新時間并將它與當前時間比較。如果兩個時間之間的差值大于預(yù)定的數(shù)值，Update.asp腳本就會運行；否則，該ASP頁面把余

23、下的HTML代碼發(fā)送給瀏覽器。 最后更新時間從Application變量得到，它的第一次初始化由global.asa完成。具體的更新時間間隔應(yīng)根據(jù)頁面內(nèi)容的更新要求調(diào)整。 如果每次訪問ASP頁面的時候都要提供最新的信息，或者輸出與用戶輸入密切相關(guān)，這種方法并不實用，但這種方法可以適應(yīng)以固定的時間間隔更新信息的場合。 如果數(shù)據(jù)庫內(nèi)容由客戶通過適當?shù)腁SP頁面更新，要確保靜態(tài)頁面也能夠自動反映數(shù)據(jù)的變化，我們可以在ASP頁面中調(diào)用Update腳本。這樣，每當數(shù)據(jù)庫內(nèi)容改變時服務(wù)器上也有了最新的靜態(tài)HTML頁面。 另一種處理頻繁變動數(shù)據(jù)的辦法是借助Microsft SQL Server 7.0的We

24、b助手向?qū)В╓eb Assistant Wizard），這個向?qū)軌蚶肨ransact-SQL、存儲過程等從SQL Server數(shù)據(jù)生成標準的HTML文件。 利用SQL Server任務(wù)，Web助手向?qū)軌蛴脕矶ㄆ诘厣蒆TML頁面。正如前面概要介紹的方案， Web助手可以通過觸發(fā)子更新HTML頁面，比如在指定的時間執(zhí)行更新或者在數(shù)據(jù)庫數(shù)據(jù)變化時執(zhí)行更新。 SQL Server使用名為sp_makewebtask的存儲過程創(chuàng)建HTML頁面，它的參數(shù)是目標HTML文件的名字和待執(zhí)行存儲過程的名字，查詢的輸出發(fā)送到HTML頁面。另外，也可以選擇使用可供結(jié)果數(shù)據(jù)插入的模板文件。 從前面的代碼可以看

25、出，當ASP頁面HtmlMain.asp需要更新時，控制以ASP文件的物理路徑為參數(shù)轉(zhuǎn)到了Update頁面。Update腳本的任務(wù)是用新的HTML數(shù)據(jù)刷新發(fā)出調(diào)用的ASP文件，并把調(diào)度ASP代碼加入到文件的開頭。為此，Update腳本打開調(diào)度模板文件，拷貝調(diào)度ASP代碼，然后控制轉(zhuǎn)到了另一部分腳本，這部分腳本主要任務(wù)是執(zhí)行數(shù)據(jù)庫操作。Update用路徑參數(shù)以寫模式打開HtmlMain.asp文件，數(shù)據(jù)庫操作的輸出以HTML格式寫入這個文件。 萬一用戶訪問頁面的時候正好在執(zhí)行更新，我們可以利用鎖或者其他類似的機制把頁面延遲幾秒鐘。 HtmlMain.asp（純HTML加調(diào)度ASP代碼）和main.asp（普通的ASP文件）在WAS下進行了性能測試。main.asp文件要查找5個不同的表為頁面提取數(shù)據(jù)。為了和這兩個文件相比較，一個只訪問單個表的ASP頁面（SingleTableTest.as