J.D. Meier
September 27, 1999
內容
介紹
劇情
測試需求
介紹測試載入器WAS
分析測試結果
影響表現和可測性的因素
類比多使用者
運行需要登入認證的測試
WAS的應用技巧
資源
介紹
當我們從傳統的CS結構的應用程式轉到當前流行的Web空間的程式時，我們發現我們在嘗試跟上不斷增長的可測性需求和效能要求。其中一個最大的挑戰在於如何確定你的程式能最多支援多少個使用者的訪問。你如何面對這一挑戰？設定清晰的效能目標並使用Web壓力測試工具會是一個好的開始。
這篇文章將會介紹如何對你的ASP程式進行壓力測試，同時將會介紹微軟的壓力測試工具- Web Application Stress test Tool (WAS).在接下來的一章，你將會學習到壓力測試的基礎，同時還會學到一些必要的技巧，通過這些學習，你將可以根據測試的結果更加有效測試和修改你的程式。
劇情
假設你將要發布一個預期有1000使用者使用的ASP程式。你清楚的知道你的程式至少能處理兩個並發的使用者的訪問，因為你和你的夥伴能整天地點擊這個ASP程式而不會出現任何的問題。你在懷疑到底兩個使用者能否精確地反映你的程式的受壓能力。當然你可以使用標準的測試方法（發布你的程式，然後期待最好的結果出現），然而你還是決定預先測試你的程式的表現。這是一個好兆頭！
測試需求
為了更好的測試你的ASP程式，你首先需要決定你的程式將來需要面對多大的壓力。簡單的說，壓力或負載可以分解成以下數字：
· 最低使用者數量。（這個程式的使用者的最低數量是多少？通常這個數值可以是每日或沒周或每月的點擊量—當然你也可以分解成一個更可控的數值—每小時訪問量，）
· 並發使用者的總量. (在最高峰時的糟糕狀況是什嗎？作出相應的計劃. 希望在有壓力的情況下工作正常有效.)
· 請求高峰值. (每秒鐘需要產生多少ASP頁面? 這也許是在衡量一個ASP程式對使用者請求作出反應的能力時的一個最重要的因素.)
為你的程式決定使用者量和並發使用者數通常是很困難的事情，而且是在你的程式在被實際使用之前。尤其是網路程式。即使是區域網路程式也常常要面對使用者增加的問題，所以準確的預計使用者量將會是困難的。當你不知道怎麼開始時，最好從基礎的開始：
Internet需要考慮的問題：
· 分析你已有的IIS日誌。這個數值會暗示出一些實際的幾率
· 你的網站將會有多流行？流行的網站一天會有100萬或更多的訪問量。不會那麼流行？那麼假設一些不同的情況？假設你有1000以上的使用者群？你能通過增加更多的硬體裝置來解決擴充性問題嗎？或者，你的程式的架構會成為瓶頸嗎？
· 什麼是最糟糕的情況？問一下你的朋友這些情況會發生嗎？
Intranet需要考慮的問題：
· 同樣地，分析你已有的IIS日誌。
· 這個ASP程式是可以給每個人用的嗎？在公司內部網有多少台機器？你的系統管理員可以告訴你有關網路高峰流量的東西嗎？
· 這個程式有特定的使用者物件嗎？只是HR人力資源部？有多少個人力資源部的員工在使用？
· 最糟糕的情況是怎樣的？
如果你不能提前決定適當的負載，那麼確定你的程式的最高上限將是你最好的選擇。如果被10個使用者點擊，你能在1秒內產生多少的ASP響應結果？100個呢？1000個呢？10000個呢？記錄你的基準。當你從實際使用中得到你的流量日誌顯示你正在接近你的極限時，你將不僅會為你知道你當前的極限是什麼，而且你會有時間準備解決的辦法。
介紹測試載入器WAS
雖然有很多的壓力測試工具可供選擇，但是在本文，我會主要集中介紹WAS（就是以前所謂的Homer），WAS是當前微軟的標準網頁壓力測試工具。如果你已經對WebCat很熟悉了，你會激動的發現WAS可以很方便地匯入現有的WebCat指令碼。如果你以前用過InetMonitor，你會激動的發現WAS也是基於GUI的（對於很多使用命令列的WebCat的使用者來說這將會是一個很好的附加特性）。另一個好處是它是免費的，我的一個好朋友常說，“如果是免費的，那麼就是我的。”除了它的價格優勢外，這個工具還提供了完整的功能，而且還在不斷地升級更新中。Microsoft.com經常要使用它，所以他們會明白這個工具的重要性。
但是你不需要過多地理會我的話，只管自己去嘗試。我在文章的結尾會提供一個列表，列出一些第三方的壓力測試工具，你可以自己決定選什麼工具。底線是你需要一個工具，能夠把你的ASP程式放到負載下，在發布之前測試它。
開始使用WAS
我會教你怎樣第一次使用這個工具來測試一個ASP頁面。我也會介紹怎樣使用署名登入的測試和多使用者並發訪問的測試，因為這些東西會使初學者一頭霧水。
首先你需要下載和安裝這個工具。你能從下面的連結中得到最新版本
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/itsolutions/intranet/downloads/webstres.asp. 在這個網站上還會有關於這個工具的入門指導，你可以隨時回去看看。
以下是在安裝時需要注意的幾點：
· 不要把WAS安裝在你的測試目標伺服器上，安裝在別的機器以確保得到準確的測試結果。
· 在安裝WAS的機器上需要有ADO2。1以上的版本。如果oledb32.dll的版本不是2.10.3711或以上，ADO會被WAS自動安裝。
· 在安裝後你會有一個完整的安裝日誌，預設會在\Program Files\Microsoft Web Application Stress Tool\INSTALL.LOG.
· 如果你已經安裝了舊版本的WAS，更新時會保留資料檔案完好。WAS使用Access .mdb檔案作為資料存放區檔案。WAS的初始.mdb包是WAS.mdb，可以在程式安裝路徑找到。
· WAS在註冊表的HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WAS儲存註冊資訊。
在運行我們新安裝的WAS之前，我們建立一個簡單的ASP指令碼作為測試頁面。建立一個新的叫做MyASPPage.asp 的ASP頁面，然後插入以下指令碼：
MyASPPage.asp
<%@ Language=VBScript %>
<HTML>
<BODY>
<% CONST ForAppending = 8
set oFSO = server.CreateObject("Scripting.FileSystemObject")
'translate our virtual directory into a physical path
strFilePath = Server.MapPath(Request.ServerVariables("PATH_INFO"))
'grab the root of the virtual directory
strFilePath = left(strFilePath, (InstrRev(strFilePath, "\")))
strFilePath = strFilePath & "MyFile.txt"
'write out to the screen the full file path
Response.Write(strFilePath & "<BR>")
set oTS = oFSO.OpenTextFile(strFilePath,ForAppending, true)
oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
"Time: " & Cstr(now()))
%>
</BODY>
</HTML>
這個ASP指令碼將在一個文字檔中插入SessionId及其啟用時間，這樣我們可以方便地確認我們的ASP頁面是否在正確的執行。一旦你熟悉了這個工具，你就可以指向你實際的ASP頁面以作真正的測試。
在伺服器的恰當的目錄放置你的ASP頁面以使它可以被匿名訪問。我們在後面將會再試署名訪問的測試，但是現在我們需要運行一個最基本的測試。用全路徑URL瀏覽你的頁面，包括你的伺服器名。例如，一個完整的URL看起來像http://MyServer/MyVirtualDirectory/MyASPPage.asp。一旦你能成功地瀏覽你的ASP頁面（務必檢查MyFile.txt這個檔案，這個檔案會被程式寫在虛擬目錄的物理位置），你就可以運行WAS做實際的測試了。
當你第一次運行WAS時，將會出現下面的對話方塊：
Figure 1. Create a new script
雖然其他選項也很誘人，現在我們先選Manual 這項。將來你還可以從菜單的Scripts或在工具攔點取New Script表徵圖來建立一個新的指令碼。
歡迎來到指令碼瀏覽介面。左手邊的視窗以樹型結構列出了你的指令碼。在右手邊的視窗裡你可以修改你的指令碼設定。
在左手邊的視窗裡的樹狀列表單擊New Script可以啟用指令碼的瀏覽。在Server輸入框輸入你的伺服器的名字。在Script Item的第一項，選擇GET作為你的動作。在PATH輸入你的ASP地址，以虛擬目錄為開始符。見圖Figure 2如下：
Figure 2. Enter the URL in the Path field
這時候，你可以點工具條上的Run Script箭頭符號來執行你的指令碼（務必確保你在左邊的視窗點取了正確的指令碼）。在產生一個概要的效能報告之前，這個指令碼需要運行大概1分鐘的時間。
分析測試結果
你可以點工具條上的Reports表徵圖來看產生的報告。這將產生一個與Script tab相臨的新的tab。報告被儲存在一個大綱視圖裡。首先，在你的報告下面點Result Codes，這個將給你一個快速的印象，這次測試是否出現了什麼問題。如果你看到的狀態碼不是200，你也許需要調查一下出現了什麼問題，通常的問題包括署名和不正確的URL路徑。
點Overview，你將看到這個測試活動的一個簡要快速的分析。從ASP的技術角度看，Request per Second，是一個需要深入分析的關索引值。這個值越高越好。通常，如果你不能從使用報告和預算中決定出一個特定的目標，你可以讓ASP 的Requests per Second值高於30，當然這個ASP是沒有連資料庫或使用其他組件的。因為可以預見，串連資料庫將增加程式的負擔。
雖然有Request per Second這個計數器預設包含在WAS裡，你也許想增加其他的計數器。你可以在點了Perf Counters的表徵圖後通過點Add Counter來增加其他的計數器。一個特別有用的計數器是ASP Requests Queued，這個計數器往往是在識別一個阻塞或長期駐留的頁面或組件時的關鍵。關於分析ASP效能的資源有：
· Tuning Internet Information Server Performance
· Navigating the Maze of Settings for Web Server Performance Optimization
· IIS 4 Resource Kit
影響效能和可測量性的因素
伺服器組成，資料庫訪問，和其他因素會大大降低ASP的Request per Second值。不同的配置選擇也會起到不同的作用，在這裡我要指出幾個常出現的因素：
· 如果你在訪問一個資料庫，你是否有做串連池？關於串連池的詳細資料請看Pooling in the Microsoft Data Access Components.
· 你是否在使用ASP Session 變數來儲存狀態？Session 變數會很快地影響可測性。它們需要伺服器資源，而且如果你想增加機器以擴充性能，它們會起阻礙作用，因為Session是與特定機器相關連的。無狀態是最大化可擴充性的方法。關於Session的替代請參考這篇文章: HowTo: Persisting Values without Session.
· 你是否在Session狀態中儲存有Visual Basic的組件？現在就去掉它們。Session中的Visual Basic對象會導致線程相關性而且會干擾打擊IIS的線程池。這是一個複雜的主題，但是滿足它的經驗方法是：不要在Session中儲存Single-threaded Apartment (STA) objects。如果你需要在Session中保留對象，它們應該被標記為”Both”，而且你需要自己彙總這些自由線程成為一個集合。Active Template Library (ATL)可以建立這樣的怪物。
· 你的網路程式是被限定運行在它自己的記憶體空間的嗎？實際上我們推薦進程保護。然而，如果你需要榨出一些額外的效能，在進程中運行你的網路程式將會節省一些交叉進程集合的開銷。
· 當涉及Microsoft Transaction Server (MTS) components時，如果組件是作為伺服器包而啟動並執行而不是庫包，那麼將會有明顯的效能區別。一個通常的建議是設定網路程式在它自己的記憶體空間中運行，然後在庫包中運行MTS組件。
類比多使用者的情況
我會簡要的介紹如何在WAS中類比多使用者請求的情況。你需要做兩件事：
1. 在Settings面板改變Concurrent Connections。
2. 在Users建立使用者，至少要建立多於你在Concurrent Connections裡指定的使用者數。
要改變並發使用者數，點Settings表徵圖。如果少於100個使用者，你可以直接設定Stress Level，要類比多於100個使用者，你還須設定Stress Multiplier。基本公式為：使用者數（線程數）= Stress Level * Stress Multiplier.如果要類比1,000個使用者，你可以設定Stress Level為100而Stress Multiplier為10。
如果你在沒有設定足夠的使用者前嘗試運行指令碼，你將會得到一個警告。通過點Users表徵圖可以修改你的使用者數，你將在右邊的視窗看到一個預設的Default組。雙擊Default組展開你的使用者列表，如果你被允許匿名訪問，那麼你只要簡單的填入新使用者的代碼然後點Create就可以了。
運行需要署名登入的測試
如果你想運行需要署名登入的頁面，那麼你需要建立合適的使用者名稱和密碼以便WAS在運行時可以使用。這同樣是在Users設定的。你可以一開始就通過Remove All去掉當前的使用者列表，然後添加你需要的使用者，你也可以選擇從文字檔匯入使用者名和密碼。
但是無論如何，需要確保這些使用者擁有有效帳號，而且他們都可以訪問IIS伺服器。如果你使用的是BASIC基本認證使用者帳號，你可以通過在你的瀏覽器提交認證來測試這個帳號，在文字檔寫出Request.ServerVariables("AUTH_USER")這個值將會有很大的協助作用。我們修改後的ASP代碼將看起來是這樣的：
oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
"Time: " & Cstr(now()) & "AUTH USER: " & chr(32) & Request.ServerVariables("AUTH_USER"))
使用WAS的技巧和提示
作為結束，我會提供一些技巧和提示，還有一些經驗總結：
· 調整你的網站的記錄檔的儲存,因為這個檔案將會快速的增大（見IIS文檔）
· 通過設定註冊表中的HKEY_LOCAL_MACHINE\Software\Microsoft\WAS\SessionTrace的DWORD為1，你可以以調試的方式追蹤WAS的活動
· 如果你的WAS報告顯示錯誤,務必檢查Event Log，在工具外用瀏覽器瀏覽你的頁面，然後檢查伺服器的日誌：\WinNT\system32\LogFiles\W3SVCi
· 如果你的測試用戶端機器的處理器使用率超過了%85，你也許需要添加更多的測試用戶端
· 一些更有趣的話題會在WAS的文檔裡出現：Page Groups, Query Strings, Cookies, Web Application Stress Object Model和Active Server Page Client (這個會讓你有能力通過Web遠端控制測試用戶端)
請注意這是個沒有支援人員的工具，發送你的問題到webtool@microsoft.com。你可以在Web Application Stress Tool這個網沾上搜尋一些常見的問題。你也可以對這個工具進行編程，在同樣的網站上有物件模型的參考。
資源
要想擷取更多的資訊，WAS的網站上的tutorial是一個好去處。當然，請務必讀一下隨WAS附帶的線上協助—特別是一個叫Web stress testing overview的話題。
· WebHammer。一個由ServerObjects做的用於測試網路程式和伺服器的工具
· LoadRunner .一個由Mercury Interactive做的壓力測試工具,可以用來預見企業級程式的系統資料表現和效能
· Enterprise Monitor .由MediaHouse Software公司出品，用於監視，通報和恢複你的intranet 和 internet網路
· Extreme Soft's PerfMon。為Microsoft Transaction Server而做的工具，能從效能監控中提供直接的MTS監視。
J.D. Meier在美國東海岸出生並成長。自從留意了Greeley的建議以後，他就成為了一名開發支援工程師，專註於伺服器端的組件和涉及MTS和ASP技術的Windows DNA應用。
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
