隨着服務器端處理任務的日益複雜以及網站訪問量的迅速增長，服務器性能的優化也成了非常迫切的任務。在優化之前，最好能夠測試一下不同條件下服務器的性能表現。找出性能瓶頸所在是設計性能改善方案之前的一個至關緊要的步驟。
本文介紹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。 本文來自無涯教程網:http://www.wuyapc.com
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頁面前面： 
每當該頁面被調用，腳本就會提取最後的更新時間並將它與當前時間比較。如果兩個時間之間的差值大於預定的數值，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頁面，比如在指定的時間執行更新或者在數據庫數據變化時執行更新。
本文來自無涯教程網:http://www.wuyapc.com
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上花費一些時間，你就能夠更深入地瞭解你的應用的性能、穩定性、瓶頸和侷限性。花費這種時間是值得的。