使用MicrosoftWebApplicationStressTool對web進(jìn)行壓力測試

你的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è)計性能改善方案之前的一個至關(guān)緊要的步驟。

本文介紹Microsoft的WebApplicationStressTool（WAS,Web應(yīng)用負(fù)載測試

工具）在Web服務(wù)器性能測試中的應(yīng)用（注：Stress基本含義為“重壓；壓力”等，本文

稱之為“負(fù)載”）。另外，我們還將通過WAS評估一種相對簡單的網(wǎng)站性能改善方法，這

種方法的基本思想是在服務(wù)器上生成靜態(tài)的HTML頁面、避免過多的數(shù)據(jù)庫調(diào)用。

負(fù)載測試是任何Web應(yīng)用的開發(fā)周期中一個重要的步驟。如果你在構(gòu)造一個為大量用

戶服務(wù)的應(yīng)用，搞清楚你的產(chǎn)品配置能夠承受多大的負(fù)載非常重要。如果你在構(gòu)造一個小型

的Intranet網(wǎng)站，測試能夠暴露出最終會導(dǎo)致服務(wù)器崩潰的內(nèi)存漏洞以及競爭情況。

無論是哪種情形，花些時間對應(yīng)用進(jìn)行負(fù)載測試可以獲得重要的基準(zhǔn)性能數(shù)據(jù)，為未

來的代碼優(yōu)化、硬件配置以及系統(tǒng)軟件升級帶來方便。即使經(jīng)費有限的開發(fā)組織也可以對

它們的網(wǎng)站進(jìn)行負(fù)載測試，因為Microsoft的WAS是可以免費下載的。WAS要求

WindowsNT4.0SP4或者更高，或者Windows2000。為了對網(wǎng)站進(jìn)行負(fù)載測試，WAS

可以通過一臺或者多臺客戶機(jī)模擬大量用戶的活動。WAS支持身份驗證、加密和Cookies,

也能夠模擬各種瀏覽器類型和Modem速度，它的功能和性能可以與數(shù)萬美元的產(chǎn)品相媲

美。如果你對WAS和Microsoft的另夕I、一個測試工具WebCapacityAnalysisTool

(WCAT)之間的差別感興趣，可以訪問MicrosoftWeb工具的比較頁面。

要對網(wǎng)站進(jìn)行負(fù)載測試首先必須創(chuàng)建WAS腳本模擬用戶活動。我們可以用下面四種方法

之一創(chuàng)建腳本：通過記錄瀏覽器的活動；通過導(dǎo)入HS日志；通過把WAS指向Web網(wǎng)站

的內(nèi)容；或者手工制作。圖1所顯示的是通過記錄瀏覽器事件生成的腳本的一部分，網(wǎng)站是

Microsoft的DuwamishBookStorePDuwamish是Microsoft開發(fā)的電子商務(wù)Web

應(yīng)用示例，從Duwamish網(wǎng)站的“Phase4”鏈接可以下載這個軟件包。下載包中包含了

它自己的WAS測試腳本。

□

【圖1】

制作WAS腳本是楣當(dāng)簡單的，不過要制作出模擬真實用戶活動的腳本有點兒復(fù)雜。

如果你已經(jīng)有一個運行的Web網(wǎng)站，可以使用Web服務(wù)器的日志來確定Web網(wǎng)站上的用

戶點擊分布。如果你的應(yīng)用還沒有開始運行，那么只好根據(jù)經(jīng)驗作一些猜測了。

圖1這個腳本中我們假定有30個會員在瀏覽書店，同時又有一個會員正在購買，要

模擬兩者混合而成的行為，首先必須創(chuàng)建頁面組并在腳本的PageGroup分枝確定點擊分

布情況。在PageGroup分枝中我們可以增力口、修改或刪除頁面組，也可以為各個組修改

流量的分布。

圖2顯示/grp_browse和grp_buy這兩個頁面組以及30比1的流量分布

□

【圖2】

創(chuàng)建了頁面組之后，我們就可以在主腳本視圖中賦予各個請求不同的頁面組，如圖3

所示。為每個請求指定頁面組相當(dāng)于告訴WAS如何分布流量。記住在本例中對grp_buy

組頁面的請求約占總數(shù)的3%,而對grp.browse組頁面的請求約占97%。

□

【圖3】

如果需要在查詢字符串中傳遞“名字?值”對，可以用WAS的查詢字符串編輯器來定

義各個變量的所有可能的值。在輸入變量值后，既可以要求WAS順序地使用變量的各個

值，也可以要求WAS在請求時隨機(jī)選擇變最值。這在一定程度上增加了腳本所模擬行為的

真實性，也可以幫助避免緩沖對測試結(jié)果的影響準(zhǔn)備好測試腳本之后，我們可以調(diào)整測試

配置以便觀察不同條件卜.的應(yīng)用性能。圖4是WAS的設(shè)置界面

□

【圖4】

StressLevel和Stressmultiplier這二個項決定了訪問服務(wù)器的并發(fā)連接的教量。

Microsoft建議不要選擇超過100的StressLevel值。如果要模擬的并發(fā)連接數(shù)量超過

100個，可以調(diào)整Stressmultiplier或使用多個客戶機(jī)。在負(fù)載測試期間WAS將通過

DCOM與其他客戶機(jī)協(xié)調(diào)。有關(guān)在測試中使用多個客戶機(jī)的更多信息，參見

/kb/hkbl3.htmo

如果網(wǎng)站提供個性化服務(wù)，要進(jìn)行身份驗證或使用Cookies,我們還要為WAS遑供

一個用戶目錄。WAS中的用戶存儲了發(fā)送給服務(wù)器的密碼以及服務(wù)器發(fā)送給客戶端的

Cookies。增加用戶數(shù)量并不增加Web服務(wù)器的魚載。必須提供足夠數(shù)量的用戶以滿足并

發(fā)連接的要求(StesssLevel乘以StressMultiplier)。有關(guān)線程、用戶、Cookies相互

作用的更多信息請參見

/Threads/WASThreads.htrrio本文來自無涯教程

網(wǎng)：http:〃

WAS允許設(shè)置warmup(熱身)時間，一般可以設(shè)置為1分鐘。在warmup期間

WAS開始執(zhí)行腳本，但不收集統(tǒng)計數(shù)據(jù)。warmup時間給MTS、數(shù)據(jù)庫以及磁盤緩沖等

一個機(jī)會來做準(zhǔn)備工作。如果在warmup時間內(nèi)收集統(tǒng)計數(shù)據(jù)，這些操作的開銷將影響性

能測試結(jié)果。

設(shè)置頁面提供的另外一個有用的功能是限制帶寬(throttlebandwidth)。帶寬限制

功能能夠為測試模擬出Modem(14.kK,28.8K,56K)、ISDN(64K,128K)以及

T1(1.54M)的速度。使用帶寬限制功能可以精確地預(yù)測出客戶通過撥號網(wǎng)絡(luò)或其他外部

連接訪問Web服務(wù)器所感受的性能。

要理解這弊不同的設(shè)置對應(yīng)用的影響，有必要了解如何使用WAS收集性能數(shù)據(jù)。

使用WAS,從遠(yuǎn)程WindowsNT和Windows2000機(jī)器獲取和分析性能計數(shù)器

(PerformanceCounter)是很方便的。加入計數(shù)器要用到圖5所示的PerfCounters

分枝。

□

【圖5】

在測試中選擇哪些計數(shù)器顯然跟測試目的有關(guān)。雖然卜面這個清單不可能精確地隔離

出性能瓶頸所在，但對一股的Web服務(wù)器性能測試來說卻是一個好的開始。

?處理器：CPU使用百分比(%CPUUtilization)

?線程：每秒的上下文切換次數(shù)(ContextSwitchesPerSecond(Total))

?ASP:每秒請求數(shù)量(RequestsPerSecond)

?ASP:請求執(zhí)行忖間(RequestExecutionTime)

?ASP:請求等待時間(RequestWaitTime)

?ASP:置入隊列的請求數(shù)量(RequestsQueued)

CPU使用百分比反映了處理器開銷。CPU使用百分比持續(xù)地超過75%是性能瓶頸在

于處理器的一個明顯的跡象。每秒上下文切換次數(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ù)量也會增加。然而，我們最終會達(dá)到這樣一個點，此時并發(fā)

用戶數(shù)量開始“壓倒”服務(wù)器。如果繼續(xù)增加并發(fā)用戶數(shù)量，每秒請求數(shù)量開始下降，而反

應(yīng)時間則會增加。要搞清楚硬件和軟件的能力，找出這個并發(fā)用戶數(shù)量開始“壓倒”服務(wù)

器的臨界點非常重:要。

置入隊列的ASP請求數(shù)量也是一個重要的指標(biāo)。如果在測試中這個數(shù)最有波動，某個

COM對象所接收到的請求數(shù)量超過了它的處理能力。這可能是因為在應(yīng)用的中間層使用了

一個低效率的組件，或者在ASP會話對象中存儲了一個單線程的單元組件。

運行WAS的客戶機(jī)CPU使用率也有必要監(jiān)視。如果這些機(jī)器上的CPU使用率持續(xù)地

超過75%,說明客戶機(jī)沒有足夠的資源來正確地運行測試，此時應(yīng)該認(rèn)為測試結(jié)果不可

信。在這種情況下，測試客戶機(jī)的數(shù)量必須增加，或者減小測試的StressLevel.

本文來自無涯教程網(wǎng):http://www.

每次測試運行結(jié)束后WAS會生成詳細(xì)的報表，即使測試被提前停止也一樣。WAS報表可

以從View菜單選擇Reports查看。下面介紹一下報表中幾個重要的部分.

如果這是一個新創(chuàng)建的測試腳本，你應(yīng)該檢查一下報表的Resul.Codes部分。這部分

內(nèi)容包含了請求結(jié)果代碼、說明以及服務(wù)器返回的結(jié)果代碼的數(shù)量。如果這里出現(xiàn)了404

代碼（貝面沒有找到），說明在腳本中有錯誤的頁面請求.

.頁面摘要部分提供了頁面的名字，接收到第一個字節(jié)的平均時間（TTFB）,接收到最后

一個字節(jié)的平均時間（TTLB）,以及測試腳本中各個頁面的命中.數(shù)。TTFB和TTLB這兩

個值對于計算客戶端所看到的服務(wù)器性能具有重要意義,TTFB反映了從發(fā)出頁面請求到接

收到應(yīng)答數(shù)據(jù)第一個字節(jié)的時間總和（.亳秒計），TTLB包含了TTFB,它是客戶機(jī)接收到

頁面最后一個字節(jié)所需要的累計時間.

報表中還包含了所有性能計數(shù)器的信息。這些數(shù)據(jù)顯示了運行時各個項目的測量值，同

時還提供了最大值、最小值、平均值等。報表實際提供的信息遠(yuǎn)遠(yuǎn)超過了我們這里能夠介紹

的內(nèi)容。為了給你一個有關(guān)表所提供信息種類的印象，圖6摘錄了一個報表實例。

□

【圖6】

.隨著Internet應(yīng)用的日益廣泛，用戶的要求和期望也在不斷地發(fā)展。今天的客戶期待

個性化的可定制的方案，期待這些方案不僅簡單，而且快速、可靠、.本低廉。對于能夠適

應(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)用性能大打折扣.

我們可以使用以下幾種方法來解決這些問題.

.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)站的用戶進(jìn)行數(shù)據(jù)庫調(diào)用.

.這里提出的性能優(yōu)化方案正是基于以下事實：訪問靜態(tài)HTML頁面要比訪問那些內(nèi)容

依賴于數(shù)據(jù)庫調(diào)用的頁面要快。它的基本思想是：在用戶訪問頁面之前，.先從數(shù)據(jù)庫提取信

息寫入存儲在服務(wù)器上的靜態(tài)HTML頁面。為了保證這些靜態(tài)頁面能夠及時地反映不斷變

化的數(shù)據(jù)庫數(shù)據(jù)，必須有一個調(diào)度程序管理靜態(tài)頁面.生成..

當(dāng)然，這種方案并不能夠適應(yīng)所有的情形。例如，如果是從持續(xù)變化的大容量數(shù)據(jù)庫提

取少量信息，這種方案是不合適的。不過可以適用該方案的場合還是很多.

為了保證能夠在合適的時,可更新靜態(tài)HTML頁面，把下面的代碼加入到相應(yīng)的ASP頁面前

面：

.著Internet應(yīng)用的H益泛，用戶的要求和期望也在不斷地發(fā)展。今天的客戶期待個性化

的可定制的方案，期待這些方案不僅簡單，而且快速、可靠、成.低廉。對于能夠適應(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)用性能大打折扣.

本文來自無涯教程網(wǎng):http://www.

我們可以使用以下幾種方

法來解決這些問題.

.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)頁面命中平均TTLB

平均TTFB(ms)

的速度相比，任何數(shù)據(jù)庫調(diào)用數(shù)(ms)

都會顯著地影響Web網(wǎng)站的

響應(yīng)速度，這主要是因為在發(fā)

送頁面之前必須單獨地為每個

訪問網(wǎng)站的用戶進(jìn)行數(shù)據(jù)庫調(diào)

用.

.這里提出的性能優(yōu)化方案

正是基于以下事實：訪問靜態(tài)

HTML頁面要比訪問那些內(nèi)容

依賴于數(shù)據(jù)庫調(diào)用的頁面要

快。它的基本思想是：在用戶

訪問頁面之前，.先從數(shù)據(jù)庫提

取信息寫入存儲在服務(wù)費上的

靜態(tài)HTML頁面。為了保證這

些靜態(tài)頁面能夠及時地反映不

斷變化的數(shù)據(jù)庫數(shù)據(jù)，必須有

?個調(diào)度程序管理靜態(tài)頁面.

生成.

當(dāng)然，這種方案并不能夠

適應(yīng)所有的情形。例如，如果

是從持續(xù)變化的大容量數(shù)據(jù)庫

提取少量信息，這種方案是不

合適的。不過可以適用該方案

的場合還是很多.

為了保證能夠在合適的時間更

新靜態(tài)HTML頁面，把下面的

代碼加入到相應(yīng)的ASP頁面前

面.

□

.每當(dāng)該頁面被調(diào)用，腳本

就會提取最后的更新時間并將

它與當(dāng)前時間比較。如果兩個

時間之間的差值大于預(yù)定的數(shù)

值,Update.asp腳本就會運

行；否則，該ASP頁面把余下

的HTML代碼發(fā)送給瀏覽器.

最后更新時間從

Application變量得到,它的

第一次初始化由global.asa

完成。具體的更新時間間隔應(yīng)

根據(jù)頁面內(nèi)容的更新要求調(diào)

整.

如果每次訪問ASP頁面的

時候都要提供最新的信息，或

者輸出與用戶輸入密切相關(guān)，

這種方法并不實用，但這種方

法可以適應(yīng)以固定的時間間隔

更新信息的場合.

如果數(shù)據(jù)庫內(nèi)容由客戶通

過適當(dāng)?shù)腁SP頁面更新，要確

保靜態(tài)頁面也能夠自動反映數(shù)

據(jù)的變化，我們可以在ASP頁

面中調(diào)用Update腳本。這樣，

每當(dāng)數(shù)據(jù)庫內(nèi)容改變時服務(wù)器

上也有了最新的靜態(tài)HTML頁

面.

另一種處理頻繁變動數(shù)據(jù)的辦

法是借助

Microsf.SQ.Serve.7.0的

Web助手向?qū)?/p>

(We.Assistan.Wizard),這

個向?qū)軌蚶?/p>

Transact-SQL,存儲過程等從

SQ.Server數(shù)據(jù)生成標(biāo)準(zhǔn)的

HTML文件.

利用SQ.Server任務(wù)，

Web助手向?qū)軌蛴脕矶ㄆ?/p>

地生成HTML頁面。正如前面

概要介紹的方案.Web助手可

以通過觸發(fā)子更新HTML頁

面，比如在指定的時間執(zhí)行更

新或者在數(shù)據(jù)庫數(shù)據(jù)變化時執(zhí)

行更新.本文來自無涯教程

|?|:http://www.wuyapc.co.

.SQ.Server使用名為

sp_makewebtask的存儲過

程創(chuàng)建HTML頁面，它的參數(shù)

是目標(biāo)HTML文件的名字和待

執(zhí)行存儲過程的名字，查詢的

輸出.送到HTML頁面。另外，

也可以選擇使用可供結(jié)果數(shù)據(jù)

插入的模板文件,從前面的代

碼可以看出，當(dāng)ASP頁面

HtmIMain.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ù)以寫

模式打開HtmIMain.asp文

件，數(shù)據(jù)庫操作,輸出以HTML

格式寫入這個文件.

萬一用戶訪問頁面的時候

正好在執(zhí)行更新，我們可以利

用鎖或者其他類似的機(jī)制把頁

面延遲幾秒鐘.HtmIMain.asp

(純HTML力口調(diào)度ASP代碼)

和main.asp(普通的ASP文

件)在WAS下進(jìn)行了性能測

試。main.asp文件要查.5個

不同的表為頁面提取數(shù)據(jù)。為

了和這兩個文件相比較，一個

只訪問單個表的ASP頁面

(SingleTableTest.asp)和

一個純HTML文.

(PlainHtml.html)也進(jìn)行了

測試..測試結(jié)果如下表所示.

文件名字

PlainHtml.html847474

SingleTableTest.asp868.88789.38

Main.asp9125.893759.56

HtmIMain.asp9149.891739.89

其中TTFB是指TotalTimetoFirstByte,TTLB是指TotalTimetoLastByte。

這些測試在一臺WindowsNTWorkstation4.0SP6運行PersonalWebServer

的機(jī)器上實施。為了使性能指標(biāo)更明顯，帶寬限制到了14.4K。在實際環(huán)境中數(shù)值變化可

能很大，但這個結(jié)果精確地反映了各個頁面在性能.上