對你的ASP程序作負載測試

介紹
當我們從傳統的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的用戶來說這將會是一個很好的附加特性）。另一個好處是它是免費的，我的一個好朋友常說，“如果是免費的，那么就是我的?！背怂膬r格優勢外，這個工具還提供了完整的功能，而且還在不斷地升級更新中。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使用Aclearcase/" target="_blank" >ccess .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應用。

原文轉自：http://www.kjueaiud.com