WAS伺服器負載測試軟體導讀

轉帖：出處未知 你的Web伺服器和應用到底能夠支援多少並發使用者訪問？在出現大量並發請求的情況下，軟體會出現問題嗎？這些問題靠通常的測試手段是無法解答的。本文介紹了Microsoft為這個目的而提供的免費工具WAS及其用法。另外，本文介紹了一種Web應用的效能最佳化方法，並利用WAS測試了它的效能改善程度。　　編譯如下：　　隨著伺服器端處理任務的日益複雜以及網站訪問量的迅速增長，伺服器效能的最佳化也成了非常迫切的任務。在最佳化之前，最好能夠測試一下不同條件下伺服器的效能表現。找出效能瓶頸所在是設計效能改善方案之前的一個至關緊要的步驟。 　　本文介紹Microsoft的Web Application Stress Tool（WAS，Web應用負載測試工具）在Web伺服器效能測試中的應用（註：Stress基本含義為“重壓；壓力”等，本文稱之為“負載”）。另外，我們還將通過WAS評估一種相對簡單的網站效能改善方法，這種方法的基本思想是在伺服器上產生靜態HTML頁面、避免過多的資料庫調用。 　　負載測試是任何Web應用的開發週期中一個重要的步驟。如果你在構造一個為大量使用者服務的應用，搞清楚你的產品配置能夠承受多大的負載非常重要。如果你在構造一個小型的Intranet網站，測試能夠暴露出最終會導致伺服器崩潰的記憶體漏洞以及競爭情況。 　　無論是哪種情形，花些時間對應用進行負載測試可以獲得重要的基準效能資料，為未來的代碼最佳化、硬體設定以及系統軟體升級帶來方便。即使經費有限的開發組織也可以對它們的網站進行負載測試，因為Microsoft的WAS是可以免費下載的。WAS要求Windows NT 4.0 SP4或者更高，或者Windows 2000。為了對網站進行負載測試，WAS可以通過一台或者多台客戶機類比大量使用者的活動。WAS支援身分識別驗證、加密和Cookies，也能夠類比各種瀏覽器類型和Modem速度，它的功能和效能可以與數萬美元的產品相媲美。如果你對WAS和Microsoft的另外一個測試載入器Web Capacity Analysis Tool （WCAT）之間的差別感興趣，可以訪問Microsoft Web工具的比較頁面。 要對網站進行負載測試首先必須建立WAS指令碼類比使用者活動。我們可以用下面四種方法之一建立指令碼：通過記錄瀏覽器的活動；通過匯入IIS日誌；通過把WAS指向Web網站的內容；或者手工製作。圖1所顯示的是通過記錄瀏覽器事件產生的指令碼的一部分，網站是Microsoft的Duwamish Book Store。Duwamish是Microsoft開發的電子商務Web應用樣本，從Duwamish網站的“Phase 4”連結可以下載這個軟體包。下載包中包含了它自己的WAS測試指令碼。         【圖1】         製作WAS指令碼是相當簡單的，不過要製作出類比真實使用者活動的指令碼有點兒複雜。如果你已經有一個啟動並執行Web網站，可以使用Web伺服器的日誌來確定Web網站上的使用者點擊分布。如果你的應用還沒有開始運行，那麼只好根據經驗作一些猜測了。 　　圖1這個指令碼中我們假定有30個會員在瀏覽書店，同時又有一個會員正在購買。要類比兩者混合而成的行為，首先必須建立頁面組並在指令碼的Page Group分枝確定點擊分布情況。在Page Group分枝中我們可以增加、修改或刪除頁面組，也可以為各個組修改流量的分布。 　　圖2顯示了grp_browse和grp_buy這兩個頁面組以及30比1的流量分布。          【圖2】         建立了頁面組之後，我們就可以在主指令碼視圖中賦予各個請求不同的頁面組，3所示。為每個請求指定頁面組相當於告訴WAS如何分布流量。記住在本例中對grp_buy組頁面的請求約佔總數的3%，而對grp_browse組頁面的請求約佔97%。          【圖3】         如果需要在查詢字串中傳遞“名字-值”對，可以用WAS的查詢字串編輯器來定義各個變數的所有可能的值。在輸入變數值後，既可以要求WAS順序地使用變數的各個值，也可以要求WAS在請求時隨機播放變數值。這在一定程度上增加了指令碼所類比行為的真實性，也可以協助避免緩衝對測試結果的影響準備好測試指令碼之後，我們可以調整測試組態以便觀察不同條件下的應用效能。圖4是WAS的設定介面。           【圖4】         Stress Level和Stress multiplier這二個項決定了訪問伺服器的並發串連的數量。Microsoft建議不要選擇超過100的Stress Level值。如果要類比的並發串連數量超過100個，可以調整Stress multiplier或使用多個客戶機。在負載測試期間WAS將通過DCOM與其他客戶機協調。有關在測試中使用多個客戶機的更多資訊，參見http://webtool.rte.microsoft.com/kb/hkb13.htm。 　　如果網站提供個人化服務，要進行身分識別驗證或使用Cookies，我們還要為WAS提供一個使用者目錄。WAS中的使用者儲存了發送給伺服器的密碼以及伺服器發送給用戶端的Cookies。增加使用者數量並不增加Web伺服器的負載。必須提供足夠數量的使用者以滿足並發串連的要求（Stesss Level乘以Stress Multiplier）。有關線程、使用者、Cookies相互作用的更多資訊請參見http://webtool.rte.microsoft.com/Threads/WASThreads.htm。 　　WAS允許設定warmup（熱身）時間，一般可以設定為1分鐘。在warmup期間WAS開始執行指令碼，但不收集統計資料。warmup時間給MTS、資料庫以及磁碟緩衝等一個機會來做準備工作。如果在warmup時間內收集統計資料，這些操作的開銷將影響效能測試結果。 　　設定頁面提供的另外一個有用的功能是限制頻寬（throttle bandwidth）。頻寬節流設定功能能夠為測試類比出Modem（14.k K，28.8 K，56 K）、ISDN（64 K，128 K）以及T1（1.54 M）的速度。使用頻寬節流設定功能可以精確地預測出客戶通過撥號網路或其他外部串連訪問Web伺服器所感受的效能。 　　要理解這些不同的設定對應用的影響，有必要瞭解如何使用WAS收集效能資料。 使用WAS，從遠程Windows NT和Windows 2000機器擷取和分析效能計數器（Performance Counter）是很方便的。加入計數器要用到圖5所示的Perf Counters分枝。         【圖5】         在測試中選擇哪些計數器顯然跟測試目的有關。雖然下面這個清單不可能精確地隔離出效能瓶頸所在，但對一般的Web伺服器效能測試來說卻是一個好的開始。         · 處理器：CPU使用百分比（% CPU Utilization）         · 線程：每秒的環境切換次數（Context Switches Per Second (Total)）         · ASP：每秒請求數量（Requests Per Second）         · ASP：請求執行時間（Request Execution Time）         · ASP：請求等待時間（Request Wait Time）         · ASP：置入隊列的請求數量（Requests Queued） 　　CPU使用百分比反映了處理器開銷。CPU使用百分比持續地超過75%是效能瓶頸在於處理器的一個明顯的跡象。每秒環境切換次數指示了處理器的工作效率。如果處理器陷於每秒數千次的環境切換，說明它忙於切換線程而不是處理ASP指令碼。 　　每秒的ASP請求數量、執行時間以及等待時間在各種測試情形下都是非常重要的監測項目。每秒的請求數量告訴我們每秒內伺服器成功處理的ASP請求數量。執行時間和等待時間之和顯示了反應時間，這是伺服器用處理好的頁面作應答所需要的時間。 　　我們可以繪出隨著測試中並發使用者數量的增加每秒請求數量和反應時間的變化圖。增加並發使用者數量時每秒請求數量也會增加。然而，我們最終會達到這樣一個點，此時並發使用者數量開始“壓倒”伺服器。如果繼續增加並發使用者數量，每秒請求數量開始下降，而反應時間則會增加。要搞清楚硬體和軟體的能力，找出這個並發使用者數量開始“壓倒”伺服器的臨界點非常重要。 　　置入隊列的ASP請求數量也是一個重要的指標。如果在測試中這個數量有波動，某個COM對象所接收到的請求數量超過了它的處理能力。這可能是因為在應用的中介層使用了一個低效率的組件，或者在ASP會話對象中儲存了一個單線程的單元組件。 　　運行WAS的客戶機CPU使用率也有必要監視。如果這些機器上的CPU使用率持續地超過75%，說明客戶機沒有足夠的資源來正確地運行測試，此時應該認為測試結果不可信。在這種情況下，測試客戶機的數量必須增加，或者減小測試的Stress Level。 每次測試回合結束後WAS會產生詳細的報表，即使測試被提前停止也一樣。WAS報表可以從View菜單選擇Reports查看。下面介紹一下報表中幾個重要的部分。 　　如果這是一個新建立的測試指令碼，你應該檢查一下報表的Result Codes部分。這部分內容包含了請求結果代碼、說明以及伺服器返回的結果代碼的數量。如果這裡出現了404代碼（頁面沒有找到），說明在指令碼中有錯誤的頁面請求。 　　頁面摘要部分提供了頁面的名字，接收到第一個位元組的平均時間（TTFB），接收到最後一個位元組的平均時間（TTLB），以及測試指令碼中各個頁面的叫用次數。TTFB和TTLB這兩個值對於計算用戶端所看到的伺服器效能具有重要意義。TTFB反映了從發出頁面請求到接收到應答資料第一個位元組的時間總和（以毫秒計），TTLB包含了TTFB，它是客戶機接收到頁面最後一個位元組所需要的累計時間。 　　報表中還包含了所有效能計數器的資訊。這些資料顯示了運行時各個項目的測量值，同時還提供了最大值、最小值、平均值等。報表實際提供的資訊遠遠超過了我們這裡能夠介紹的內容。為了給你一個有關表所提供資訊種類的印象，圖6摘錄了一個報表執行個體。 　　          【圖6】         隨著Internet應用的日益廣泛，使用者的要求和期望也在不斷地發展。今天的客戶期待個人化的可定製的方案，期待這些方案不僅簡單，而且快速、可靠、成本低廉。對於能夠適應使用者需求不斷變動的可定製頁面來說，靜態HTML已經退出了舞台，比如內容根據客戶請求變化的頁面就是其中一例。這一切都要求系統儲存相關的資料，例如有關使用者本身以及使用者可能請求哪些資訊的資料。 　　緊跟這些趨勢的Web開發人員已經開始提供可定製的Web網站。象搜尋資料之類的任務現在可以由伺服器執行而無需客戶幹預。然而，這些變革也導致了一個結果，這就是許多網站都在使用大量的未經最佳化的資料庫調用，從而使得應用效能大打折扣。 　　我們可以使用以下幾種方法來解決這些問題：         1. 最佳化ASP代碼。         2. 最佳化資料庫調用。         3. 使用預存程序。         4. 調整伺服器效能。 　　優秀的網站設計都會關注這些問題。然而，與靜態頁面的速度相比，任何資料庫調用都會顯著地影響Web網站的響應速度，這主要是因為在發送頁面之前必須單獨地為每個訪問網站的使用者進行資料庫調用。 　　這裡提出的效能最佳化方案正是基於以下事實：訪問靜態HTML頁面要比訪問那些內容依賴於資料庫調用的頁面要快。它的基本思想是：在使用者訪問頁面之前，預先從資料庫提取資訊寫入儲存在伺服器上的靜態HTML頁面。為了保證這些靜態頁面能夠及時地反映不斷變化的資料庫資料，必須有一個發送器管理靜態頁面的產生。 　　當然，這種方案並不能夠適應所有的情形。例如，如果是從持續變化的大容量資料庫提取少量資訊，這種方案是不合適的。不過可以適用該方案的場合還是很多。 為了保證能夠在合適的時間更新靜態HTML頁面，把下面的代碼加入到相應的ASP頁面前面：隨著Internet應用的日益廣泛，使用者的要求和期望也在不斷地發展。今天的客戶期待個人化的可定製的方案，期待這些方案不僅簡單，而且快速、可靠、成本低廉。對於能夠適應使用者需求不斷變動的可定製頁面來說，靜態HTML已經退出了舞台，比如內容根據客戶請求變化的頁面就是其中一例。這一切都要求系統儲存相關的資料，例如有關使用者本身以及使用者可能請求哪些資訊的資料。 　　緊跟這些趨勢的Web開發人員已經開始提供可定製的Web網站。象搜尋資料之類的任務現在可以由伺服器執行而無需客戶幹預。然而，這些變革也導致了一個結果，這就是許多網站都在使用大量的未經最佳化的資料庫調用，從而使得應用效能大打折扣。 　　我們可以使用以下幾種方法來解決這些問題：         1. 最佳化ASP代碼。         2. 最佳化資料庫調用。         3. 使用預存程序。         4. 調整伺服器效能。 　　優秀的網站設計都會關注這些問題。然而，與靜態頁面的速度相比，任何資料庫調用都會顯著地影響Web網站的響應速度，這主要是因為在發送頁面之前必須單獨地為每個訪問網站的使用者進行資料庫調用。 　　這裡提出的效能最佳化方案正是基於以下事實：訪問靜態HTML頁面要比訪問那些內容依賴於資料庫調用的頁面要快。它的基本思想是：在使用者訪問頁面之前，預先從資料庫提取資訊寫入儲存在伺服器上的靜態HTML頁面。為了保證這些靜態頁面能夠及時地反映不斷變化的資料庫資料，必須有一個發送器管理靜態頁面的產生。 　　當然，這種方案並不能夠適應所有的情形。例如，如果是從持續變化的大容量資料庫提取少量資訊，這種方案是不合適的。不過可以適用該方案的場合還是很多。 為了保證能夠在合適的時間更新靜態HTML頁面，把下面的代碼加入到相應的ASP頁面前面： 　  < %lastUpdated=Application("LastUpdated")presentTime=now if DATEDIFF("h",lastUpdated,presentTime) >= 1 then   Application ("LastUpdated") =presentTime   response.redirect   "Update.asp?physicalpath="&Request.ServerVariables("PATH_TRANSLATED")end if% >< html >Static content goes here< /html >         每當該頁面被調用，指令碼就會提取最後的更新時間並將它與目前時間比較。如果兩個時間之間的差值大於預定的數值，Update.asp指令碼就會運行；否則，該ASP頁面把餘下的HTML代碼發送給瀏覽器。 　　最後更新時間從Application變數得到，它的第一次初始化由global.asa完成。具體的更新時間間隔應根據頁面內容的更新要求調整。 　　如果每次訪問ASP頁面的時候都要提供最新的資訊，或者輸出與使用者輸入密切相關，這種方法並不實用，但這種方法可以適應以固定的時間間隔更新資訊的場合。 　　如果資料庫內容由客戶通過適當的ASP頁面更新，要確保靜態頁面也能夠自動反映資料的變化，我們可以在ASP頁面中調用Update指令碼。這樣，每當資料庫內容改變時伺服器上也有了最新的靜態HTML頁面。 另一種處理頻繁變動資料的辦法是藉助Microsft SQL Server 7.0的Web助手嚮導（Web Assistant Wizard），這個嚮導能夠利用Transact-SQL、預存程序等從SQL Server資料產生標準的HTML檔案。 　　利用SQL Server任務，Web助手嚮導能夠用來定期地產生HTML頁面。正如前面概要介紹的方案， Web助手可以通過觸發子更新HTML頁面，比如在指定的時間執行更新或者在資料庫資料變化時執行更新。 　　SQL Server使用名為sp_makewebtask的預存程序建立HTML頁面，它的參數是目標HTML檔案的名字和待執行預存程序的名字，查詢的輸出發送到HTML頁面。另外，也可以選擇使用可供結果資料插入的模板檔案。 從前面的代碼可以看出，當ASP頁面HtmlMain.asp需要更新時，控制以ASP檔案的實體路徑為參數轉到了Update頁面。Update指令碼的任務是用新的HTML資料重新整理發出調用的ASP檔案，並把調度ASP代碼加入到檔案的開頭。為此，Update指令碼開啟調度模板檔案，拷貝調度ASP代碼，然後控制轉到了另一部分指令碼，這部分指令碼主要任務是執行資料庫操作。Update用路徑參數以寫入模式開啟HtmlMain.asp檔案，資料庫操作的輸出以HTML格式寫入這個檔案。 　　萬一使用者訪問頁面的時候正好在執行更新，我們可以利用鎖或者其他類似的機制把頁面延遲幾秒鐘。 HtmlMain.asp（純HTML加調度ASP代碼）和main.asp（普通的ASP檔案）在WAS下進行了效能測試。main.asp檔案要尋找5個不同的表為頁面提取資料。為了和這兩個檔案相比較，一個只訪問單個表的ASP頁面（SingleTableTest.asp）和一個純HTML檔案（PlainHtml.html）也進行了測試。 　　 測試結果如下表所示： 檔案名稱字 命中數 平均TTFB（ms） 平均TTLB（ms） PlainHtml.html 8 47 474 SingleTableTest.asp 8 68.88 789.38 Main.asp 9 125.89 3759.56 HtmlMain.asp 9 149.89 1739.89         其中TTFB是指Total Time to First Byte，TTLB是指Total Time to Last Byte。 　　這些測試在一台Windows NT Workstation 4.0 SP6 運行Personal Web Server的機器上實施。為了使效能指標更明顯，頻寬節流設定到了14.4 K。在實際環境中數值變化可能很大，但這個結果精確地反映了各個頁面在效能上的差異。 　　測試結果顯示訪問單個表的ASP頁面的處理時間是720.5ms，而純HTML檔案則為427ms。Main.asp和HtmlMain.asp的輸出時間相同，但它們的處理時間分別為3633.67ms和1590ms。也就是說，在這個測試環境下我們可以把處理速度提高43%。 如果我們要讓頁面每隔一定的訪問次數更新，比如100次，那麼這第100個使用者就必須等待新的HTML頁面產生。不過，這個代價或許不算太高，其他99個使用者獲得了好處。 　　靜態頁面方法並不能夠適合所有類型的頁面。例如，某些頁面在進行任何處理之前必須要有使用者輸入。但是，這種方法可以成功地應用到那些不依賴使用者輸入卻進行大量資料庫調用的頁面，而且這種情況下它將發揮出更大的效率。 　　在大多數情況下，動態網頁面的產生將在相當大的程度上提高網站的效能而且無需在功能上有所折衷。雖然有許多大的網站採用了這個策略來改善效能，也有許多網站完全由於進行大量沒有必要的資料庫調用而表現出很差的效能。 　　Microsoft的WAS是一個功能非常豐富的伺服器效能測試工具，可以協助我們準確地判斷什麼方案將適合於提升網站效能；是否某個方案（比如本文第二部分的靜態頁面方案）能夠顯著地改善效能。 　　本文對WAS的介紹應當說是相當粗略和膚淺的。WAS還提供了一個物件模型，我們可以通過指令碼擴充它的功能。訪問http://webtool.rte.microsoft.com/?ObjModel/default.htm可以看到一個指令碼樣本。這個指令碼將登記Web伺服器的每秒最大請求數量，自動地增加Stress Level值直到伺服器處理器利用率達到90%為止。 　　WAS能夠為你提供有關ASP應用和它所啟動並執行硬體的豐富的資訊。在WAS上花費一些時間，你就能夠更深入地瞭解你的應用的效能、穩定性、瓶頸和局限性。花費這種時間是值得的。