使用MicrosoftWebAppIicationStressTool對web進行壓力

測試

你的Web服務器和應用到底能夠支持多少并發用戶訪問？在出現大量并發請求的情況

下，軟件會出現問題嗎？這些問題靠通常的測試手段是無法解答的。本文介紹了Microsoft

為這個目的而提供的免費工具WAS及其用法。另外，本文介紹了一種Web應用的性能優

化方法，并利用WAS測試了它的性能改善程度。

隨著服務器端處理任務的日益復雜以及網站訪問量的迅速增長，服務器性能的優化也

成了非常迫切的任務。在優化之前，最好能夠測試一下不同條件下服務器的性能表現。找出

性能瓶頸所在是設計性能改善方案之前的一個至關緊要的步驟。

本文介紹Microsoft的WebApplicationStressTool（WAS,Web應用負載測試工具）

在Web服務器性能測試中的應用（注：Stress基本含義為“重壓；壓力”等，本文稱之為“負

載”）。另外，我們還將通過WAS評估一種相對簡單的網站性能改善方法，這種方法的基

本思想是在服務器上生成靜態的HTML頁面、避免過多的數據庫調用。

負載測試是任何Web應用的開發周期中一個重要的步驟。如果你在構造一個為大量用

戶服務的應用，搞清楚你的產品配置能夠承受多大的負載非常重要。如果你在構造一個小型

的Intranet網站，測試能夠暴露出最終會導致服務器崩潰的內存漏洞以及競爭情況。

無論是哪種情形，花些時間對應用進行負載測試可以獲得重要的基準性能數據，為未

來的代碼優化、硬件配置以及系統軟件升級帶來方便。即使經費有限的開發組織也可以時

它們的網站進行負載測試，因為Microsoft的WAS是可以免費下載的。WAS要求Windows

NT4.0SP4或者更高，或者Windows2000。為了對網站進行負載測試，WAS可以通過一

臺或者多臺客戶機模擬大量用戶的活動。WAS支持身份驗證、加密和Cookies,也能夠模

擬各種瀏覽器類型和Modem速度，它的功能和性能可以與數萬美元的產品相媲美。如果

你對WAS和Microsoft的另外一個測試工具WebCapacityAnalysisTool（WCAT）之間

的差別感興趣，可以訪問MicrosoftWeb工具的比較頁面。

要對網站進行負載測試首先必須創建WAS腳本模擬用戶活動。我們可以用下面四種方法

之創建腳本：通過記錄瀏覽器的活動；通過導入HS日志；通過把WAS指向Web網站

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

是Microsoft的DuwamishBookStore?Duwamish是Microsoft開發的電子商務Web應用

示例，從Duwamish網站的“Phase4”鏈接可以下載這個軟件包。卜一載包中包含了它自己的

WAS測試腳本。

彳產Wc，，Appimatton5la?*ag\PfogiMniFWi

File￡&SonpUViewWindow

riairi^

DefeUH

SampleScriptServo|Ind2a

Ul?ra_pe<f

NoimBto^J

DtAM4fTVSh

ContentItee

Settr?g5

fillP?ifCouni?ft

手PageGroups

Doublv-cbck?r?avcv。itemtoviewd，3.

<?Ue

6ClMr^t

0Cookies

UMre(_db?<reTt

UKr?_pu&hup

Scripts:D“WIE..

【圖1】

制作WAS腳本是相當簡單的，不過要制作出模擬真實用戶活動的腳本有點兒復雜。如

果你已經有?個運行的Web網站，可以使用Web服務器的日志來確定Web網站上的用戶

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

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

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

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

的分布。

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

:WWebApplicationStress-GAProgramFiles\MicrosoftWebA叩licdtionStressTo

瞥FileEditScriptsViewWindowHelp■1x|

閨譽|@叫噢|廿|0X|封圄闿U

固

：wDefaults

由

：警SampleScript

@.:-警Ultra.perf

日

.等Duwamish

.

.恒ContentTree

啕Sellings

IsilPerfCounters

PageGroups

.Users

噢Clients

,Cookies

Illh^rlhTra代d

警Scripts：Duwam..

圖2】

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

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

頁面的請求約占總數的3%,而對grp_browse組頁面的請求約占97%。

【圖3】

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

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

也可以要求WAS在請求時隨機選擇變量值。這在一定程度上增加了腳本所模擬行為的真實

性，也可以幫助避免緩沖對測試結果的影響準備好測試腳本之后，我們可以調整測試配置

以便觀察不同條件下的應用性能。圖4是WAS的設置界面

掾?WebApplicationStress-G:\ProgramFilesKMiciosoKWebApplicationStres…

瞥FileEditScriptsViewWindowHelp■|t91x|

包警|Ql|電I砌I|x|到圖置

0-:Defaults

國

.ConcurrentConnections

由SampleScript

：Ukra_perfStresslevel(threads):I50^

0-

Duwamish

ContentT隧Stressmultiplier(socketsperthread):|1

Settings

PerfCounUTestRunTime

PageGroup

的

UsersDays:|0Hrs:|0Mins:|Sec:|0

Clients

Cookies

.RequestDelay(inmilliseconds)

固

Ultra_db$Ues$

…

「Userandomdelay|5000

?:-Ultra_pushup

?.-

@-ws51

NewRecordedSuspend

Warmup:Hrs:|0Mins:|FSec:|0

Cooldown:Hrs:|0Mins:|TSec:|0

Bandwith

廠Throttlebandwidth□

Redirects

gFollowHTTPredirectsMax:|15

Throughput

底Useusers,passwords,andsavecookies

廠Savepagestatistics

r~Resolvenetworklookupsonremoteclients

4—I」

警Scripts：Duwam..

【圖4】

StressLevel和Stressmultiplier這二個項決定了訪問服務器的并發連接的數量。

Microsoft建議不要選擇超過100的StressLevel值。如果要模擬的并發連接數量超過100個,

可以調整Stressmultiplier或使用多個客戶機。在負載測試期間WAS將通過DCOM與其他客

戶機協調。有關在測試中使用多個客戶機的更多信息，參見

/kb/hkb13.htrrio

如果網站提供個性化服務，要進行身份驗證或使用Cookies,我們還要為WAS提供一

個用戶目錄。WAS中的用戶存儲了發送給服務器的密碼以及服務器發送給客戶端的

Cookies?增加用戶數量并不增加Web服務器的負載。必須提供足夠數量的用戶以滿足并發

連接的要求(StesssLevel乘以StressMultiplier)。

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

開始執行腳本，但不收集統計數據。warmup時間給MTS、數據庫以及磁盤緩沖等一個機

會來做準備工作。如果在warmup時間內收集統計數據，這些操作的開銷將影響性能測試結

果。

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

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

M)的速度。使用帶寬限制功能可以精確地預測出客戶通過撥號網絡或其他外部連接訪問

Web服務器所感受的性能。

要理解這些不同的設置對應用的影響，有必要了解如何使用WAS收集性能數據。

使用WAS,從遠程WindowsNT和Windows2000機器獲取和分析性能計數器(Performance

Counter)是很方便的。加入計數器要用到圖5所示的PerfCounters分枝。

*WebApplicationStress-G:\ProgramFilesXMicrosoftWebApplicationSt，.

轡FileEditScriptsViewWindowHelp-|g|x|

閨警|國|日噢I睜kIx|LUU

?:-Defaults

?:-

CollectionInterval:AddCounter

ls:-SampleScript

B-Ultra_perf

WBITMASKV^ctiveServerPage式RequestExecutionTime

DuwamishWBITMASKXActiveServerPage$\RequestWaitTime

花|ContentTreeWBITMASKXActiveServerPage八RequestsQueued

曲Settings\\BITMASK\ActiveServerPage$\Reque$ts/Sec

PerfCounters\\BITMASK\ProcessorLTProcessorTime

5PdgeGroups

.Users

啜Clients

3Cookies

Ultra_dbstress

Ultra_pushup

ws$1

NewRecordedScript

鏟Scripts：Duwam..

【圖5】

在測試中選擇哪些計數器顯然跟測試目的有關。雖然下面這個清單不可能精確地隔離

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

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

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

?ASP：每秒請求數量(RequestsPerSecond)

-ASP：請求執行時間(RequestExecutionTime)

-ASP：請求等待時間(RequestWaitTime)

-ASP：置入隊列的請求數量(RequestsQueued)

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

處理器的一個明顯的跡象。每秒上下文切換次數指示了處理器的工作效率。如果處理器陷于

每秒數千次的上下文切換，說明它忙于切換線程而不是處理ASP腳本。

每秒的ASP請求數量、執行時間以及等待時間在各種測試情形下都是非常重要的監測

項目。每秒的請求數量告訴我們每秒內服務器成功處理的ASP請求數量。執行時間和等待

時間之和顯示了反應時間，這是服務器用處理好的頁面作應答所需要的時間。

我們可以繪出隨著測試中并發用戶數量的增加每秒請求數量和反應時間的變化圖。增

加并發用戶數量時每秒請求數量也會增加。然而，我們最終會達到這樣一個點，此時并發

用戶數量開始“壓倒”服務器。如果繼續增加并發用戶數量，每秒請求數量開始下降，而反應

時間則會增加。要搞清楚硬件和軟件的能力，找出這個并發用戶數量開始“壓倒”服務器的

臨界點非常重要。

置入隊列的ASP請求數量也是一個重要的指標。如果在測試中這個數量有波動，某個

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

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

運行WAS的客戶機CPU使用率也有必要監視。如果這些機器上的CPU使用率持續地

超過75%,說明客戶機沒有足夠的資源來正確地運行測試，此時應該認為測試結果不可信。

在這種情況下，測試客戶機的數量必須增加，或者減小測試的StressLevel。

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

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

如果這是一個新創建的測試腳本，你應該檢查一下報表的ResultCodes部分。這部分

內容包含了請求結果代碼、說明以及服務器返回的結果代碼的數量。如果這里出現了404

代碼(頁面沒有找到)，說明在腳本中有錯誤的頁面請求。

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

后一個字節的平均時間(TTLB),以及測試腳本中各個頁面的命中次數。TTFB和TTLB

這兩個值對于計算客戶端所看到的服務器性能具有重要意義。TTFB反映了從發出頁面請求

到接收到應答數據第-個字節的時間總和(以毫秒計),TTLB包含了TTFB,它是客戶機

接收到頁面最后一個字節所需要的累計時間。

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

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

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

<、WebApplicationStiett-G:\ProQfamFilot\MiciosoftWebApplicationStie??TooAWAS.mdb[RepofU),1□!x|

QReEdiScnpUViewWindowHelp

p|產IQHMI||M贊I

.?=>ageGroupsFageResults

:*30?Data

URI:_GETzd4_3/xnlcatasp?l

PGET/d<3/HitCount12

pGET/d4_giaphct/$p^

?GET/d4_gtaphics/tabResultCodes

?GET/d4_gtaph?csAabCodeDescriptionCount

PGET/d4_gfophcx/ms?200OK12

pGET/D4_Graphicj/d4

3GET/msdn_ie4-Timeto(fxrstbyte(inmi11iseconds)

GET/d4_araphcs/d4t

?GET/d4_3/catx$lAverage

Min:

pGET/d4_3/xnlcatasp25thPercentlie

pGETAM_3/cMxtl50thPercentil?

PGET/d4_3/xmlcat7SthPercen11le

?GET/d<3/c^tx$l」Max209360

PGET/d4_3/xmlcataspTimetolastbyte(inmi11iseconds)

GET/d4_3/c?txsl

PGET/d4_3/xmlcotaspAverage7S383

pGETZd4_3/c?txslMin52489

1□GETZd43/xmldetacjzJ25thPercentile53434

14

皆ScriptsQReports|

【圖6】

隨著Internet應用的11益廣泛，用戶的要求和期望也在不斷地發展。今天的客戶期待

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

適應用戶需求不斷變動的可定制頁面來說，靜態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頁面前

面：

<%

Iastllpdated=AppIication("LastUpdated")

present!ime=now

ifDATEDIFFCh''IastUpdated.oresentTime)>=1then

AppIicationCLastUpdated")=presentTime

response.redirect

("PATHTRANSLATED")

endif

K>

<htmI>

Staticcontentgoeshere

</htmI>

每當該頁面被調用，腳本就會提取最后的更新時間并將它與當前時間比較。如果兩個時間之

間的差值大于預定的數值，Update.asp腳本就會運行；否則，該ASP頁面把余下的HTML

代碼發送給瀏覽器。

最后更新時間從Application變量得到，它的第一次初始化由global.asa完成。具體的

更新時間間隔應根據頁面內容的更新要求調整。

如果每次訪問ASP頁面的時候都要提供最新的信息，或者輸出與用戶輸入密切相關，

這種方法并不實用，但這種方法可以適應以固定的時間間隔更新信息的場合。

如果數據庫內容由客戶通過適當的ASP頁面更新，要確保靜態頁面也能夠自動反映數

據的變化，我們可以在ASP頁面中調用Update腳本。這樣，每當數據庫內容改變時服務

器上也有了最新的靜態HTML頁面。

另種處理頻繁變動數據的辦法是借助MicrosftSQLServer7.0的Web助手向導(Web

AssistantWizard),這個向導能夠利用Transact-SQL、存儲過程等從SQLServer數據生

成標準的HTML文件。

利用SQLServer任務，Web助手向導能夠用來定期地生成HTML頁面。正如前面概

要介紹的方案，Web助手可以通過觸發子更新HTML頁面，比如在指定的時間執行更新或

者在數據庫數據變化時執行更新。

SQLServer使用名為sp_makewebtask的存儲過程創建HTML頁面，它的參數是目

標HTML文件的名字和待執行存儲過程的名字，查詢的輸出發送到HTML頁面。另外，也

可以選擇使用可供結果數據插入的模板文件。從前面的代碼可以看出，當ASP頁面

HtmIMain.asp需要更新時,控制以ASP文件的物理路徑為參數轉到了Update貞血。Update

腳本的任務是用新的HTML數據刷新發出調用的ASP文件，并把調度ASP代碼加入到文

件的開頭。為此，Update腳本打開調度模板文件，拷貝調度ASP代碼，然后控制轉到了

另一部分腳本，這部分腳本主要任務是執行數據庫操作。Update用路徑參數以寫模式打開

HtmIMain.asp文件，數據庫操作的輸出以HTML格式寫入這個文件。

萬一用戶訪問頁面的時候正好在執行更新，我們可以利用鎖或者其他類似的機制把頁面

延遲幾秒鐘。HtmIMain.asp(純HTML加調度ASP代碼)和main.asp(普通的ASP文

件)在WAS卜進行了性能測試。main.asp文件要查找5個不同的表為頁面提取數據。為

了和這兩個文件相比較，一個只訪問單個表的ASP頁面(SingleTableTest.asp)和一個純

HTML文件(PlainHtml.html)也進行強試.測試結果如?所示：

平均TTLB

文件名字命中數平均TTFB(ms)

(ms)

PlainHtml.html847474

SingleTableTest.asp868.88789.38

Main,asp9125.893759.56

HtmlMain.asp9149.891739.89

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

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

上實施。為了使性能指標更明顯，帶寬限制到了14.4K。在實際環境中數值變化可能很大,

但這個結果精確地反映了各個頁面在性能上的差異。

測試結果顯示訪問單個表的ASP頁面的處理時間是720.5ms,而純HTML文件則為

427ms。Main.asp和HtmIMain.asp的輸出時間相同，但它們的處理時間分別為3633.67ms

和1590ms。也就是說，在這個測試環境下我們可以把處理速度提高43%。

如果我們要讓頁面每隔?定的訪問次數更新，比如100次，那么這第100個用戶就必須等

待新的HTML頁面生成。不過，這個代價或許不算太高，其他99個用戶獲得了好處。

靜態頁面方法并不能夠適合所有類型的頁面。例如，某些頁面在進行任何處理之前必須

要有用戶輸入。但是，這種方法可以成功地應用到那些不依賴用戶輸入卻進行大量數據庫調

用的頁面，而且這種情況下它將發揮出更大的效率。

在大多數情況F，動態頁面的生成將在相當大的程度上提高網站的性能而且無需在功能

匕有所折衷。雖然有許多大的網站采用了這個策略來改善性能，也有許多網站完全由于進行

大量沒有必要的數據庫調用而表現出很差的性能。

Microsoft的WAS是一個功能非常豐富的服務器性能測試工具，可以幫助我們準確地判

斷什么方案將適合于提升網站性能；是否某個方案(比如本文第二部分的靜態頁面方案)能

夠顯著地改善性能。

本文對WAS的介紹應當說是相當粗略和膚淺的。WAS還提供了一個對象模型，我們可

以通過腳本擴展它的功能。T^H/?ObjModel/default.htmnJ

以看到一個腳本示例。這個腳本將登記Web服務器的每秒最大請求數量，自動地增加Stress

Level值直到服務器處理器利用率達到90%為止。

WAS能夠為你提供有關ASP應用和它所運行的硬件的豐富的信息。在WAS上花費一些

時間，你就能夠更深入地了解你的應用的性能、穩定性、瓶頸和局限性。花費這種時間是值

得的。

posted@2008-10-1414:04liuhaitao閱讀(125)|評論(0)|編輯

ASP.NET性能優化

轉：http://wangwblogs.com/archive/2006/06/05/417632.html

1.數據庫訪問性能優化

數據庫的連接和關閉

訪問數據庫資源需要創建連接、打開連接和關閉連接幾個操作。這些過程需要多次與數

據庫交換信息以通過身份驗證，比較耗費服務器資源。ASP.NET中提供了連接池

(ConnectionPool)改善打開和關閉數據庫對性能的影響。系統將用戶的數據庫連接放在

連接池中，需要時取出，關閉時收回連接，等待下一次的連接請求。

連接池的大小是有限的，如果在連接池達到最大限度后仍要求創建連接，必然大大影響

性能?因此，在建立數據庫連接后只有在真正需要操作時才打開連接，使用完畢后馬上關閉，

從而盡量減少數據庫連接打開的時間，避免出現超出連接限制的情況。

使用存儲過程

存儲過程是存儲在服務器上的一組預編譯的SQL語句，類似于DOS系統中的批處理

文件。存儲過程具有對數據庫立即訪問的功能，信息處理極為迅速。使用存儲過程可以避免

對命令的多次編譯，在執行一次后其執行規劃就駐留在高速緩存中，以后需要時只需直接調

用緩存中的二進制代碼即可。

另外，存儲過程在服務器端運行，獨立于ASP.NET程序，便于修改，最重要的是它可

以減少數據庫操作語句在網絡中的傳輸。

優化查詢語句

ASP.NET中ADO連接消耗的資源相當大，SQL語句運行的時間越長，占用系統資源

的時間也越長。因此，盡量使用優化過的SQL語句以減少執行時間。比如，不在查詢語句

中包含子查詢語句，充分利用索引等。

2.字符串操作性能優化

使用值類型的ToString方法

在連接字符串時，經常使用"+”號直接將數字添加到字符串中。這種方法雖然簡單，也

可以得到正確結果，但是由于涉及到不同的數據類型，數字需要通過裝箱操作轉化為引用類

型才可以添加到字符串中。但是裝箱操作對性能影響較大，因為在進行這類處理時，將在托

管堆中分配一個新的對象，原有的值復制到新創建的對象中。

使用值類型的ToString方法可以避免裝箱操作，從而提高應用程序性能。

運用StringBuilder類

String類對象是不可改變的，對于String對象的重新賦值在本質上是重新創建了一個

String對象并將新值賦予該對象，其方法ToString對性能的提高并非很顯著。

在處理字符串時，最好使用StringBuilder＞類，其.NET命名空間是System.Text。該類

并非創建新的對象，而是通過Append,Remove,Insert等方法直接對字符串進行操作，

通過ToString方法返回操作結果。

其定義及操作語句如下所示：

intnum;

System.Text.StringBuilderstr=newSystem.Text.StringBuilder();〃創建字符串

str.Append(num.ToString());〃添力口數值num

Response.Write（str.ToString）;〃顯示操作結果

3.優化Web服務器計算機和特定應用程序的配置文件以符合您的特定需要

默認情況下，ASP.NET配置被設置成啟用最廣泛的功能并盡量適應最常見的方案。因

此，應用程序開發人員可以根據應用程序所使用的功能，優化和更改其中的某些配置，以提

高應用程序的性能。下面的列表是您應該考慮的一些選項。

僅對需要的應用程序啟用身份驗證。默認情況下，身份驗證模式為Windows,或集成

NTLMo大多數情況下，對于需要身份驗證的應用程序，最好在Machine.config文件中禁

用身份驗證，并在Web.config文件中啟用身份驗證。

根據適當的請求和響應編碼設置來配置應用程序。ASP.NET默認編碼格式為UTF-8。

如果您的應用程序為嚴格的ASCII,請配置應用程序使用ASCII以獲得稍許的性能提高。

考慮對應用程序禁用AutoEventWireupo在Machine.config文件中將

AutoEventWireup屬性設置為false,意味著頁面不將方法名與事件進行匹配和將兩者掛鉤

（例如Page_Load）。如果頁面開發人員要使用這些事件，需要在基類中重寫這些方法（例

如，需要為頁面加載事件重寫Page.OnLoad,而不是使用Page_Load方法）。如果禁用

AutoEventWireup,頁面將通過將事件連接留給頁面作者而不是自動執行它，獲得稍許的性

能提升。

從請求處理管線中移除不用的模塊。默認情況下，服務器計算機的Machine.config文

件中＜httpModules＞節點的所有功能均保留為激活。根據應用程序所使用的功能，您可以

從請求管線中移除不用的模塊以獲得稍許的性能提升。檢查每個模塊及其功能，并按您的需

要自定義它。

例如，如果您在應用程序中不使用會話狀態和輸出緩存，則可以從＜httpModules＞列

表中移除它們，以便請求在不執行其他有意義的處理時，不必執行每個模塊的進入和離開代

碼。

4.一定要禁用調試模式

在部署生產應用程序或進行任何性能測量之前，始終記住禁用調試模式。如果啟用了調

試模式，應用程序的性能可能受到非常大的影響。

5.對于廣泛依賴外部資源的應用程序，請考慮在多處理器計算機上啟用網絡園藝

ASP.NET進程模型幫助啟用多處理器計算機上的可縮放性，將工作分發給多個進程

（每個CPU一個），并且每個進程都將處理器關系設置為其CPUo此技術稱為網絡園藝。

如果應用程序使用較慢的數據庫服務器或調用具有外部依賴項的COM對象（這里只是提

及兩種可能性），則為您的應用程序啟用網絡園藝是有益的。但是，在決定啟用網絡園藝之

前，您應該測試應用程序在網絡園中的執行情況。

6.只要可能，就緩存數據和頁輸出

ASP.NET提供了一些簡單的機制，它們會在不需要為每個頁請求動態計算頁輸出或數

據時緩存這些頁輸出或數據。另外，通過設計要進行緩存的頁和數據請求（特別是在站點中

預期將有較大通訊量的區域），可以優化這些頁的性能。與.NETFramework的任何Web

窗體功能相比，適當地使用緩存可以更好的提高站點的性能，有時這種提高是超數量級的。

使用ASP.NET緩存機制有兩點需要注意。首先，不要緩存太多項。緩存每個項均有

開銷，特別是在內存使用方面。不要緩存容易重新計算和很少使用的項。其次，給緩存的項

分配的有效期不要太短。很快到期的項會導致緩存中不必要的周轉，并且經常導致更多的代

碼清除和垃圾回收工作。若關心此問題，請監視與ASP.NETApplications性能對象關聯的

CacheTotalTurnoverRate性能計數器。高周轉率可能說明存在問題，特別是當項在到期

前被移除時。這也稱作內存壓力。

7.選擇適合頁面或應用程序的數據查看機制

根據您選擇在Web窗體頁顯示數據的方式，在便利和性能之間常常存在著重要的權

衡。例如，DataGridWeb服務器控件可能是一種顯示數據的方便快捷的方法，但就性能而

言它的開銷常常是最大的。在某些簡單的情況下，您通過生成適當的HTML自己呈現數據

可能很有效，但是自定義和瀏覽器定向會很快抵銷所獲得的額外功效。RepeaterWeb服務

器控件是便利和性能的折衷。它高效、可自定義且可編程。

8.將SqlDataReader類用于快速只進數據游標

SqlDataReader類提供了一種讀取從SQLServer數據庫檢索的只進數據流的方法。

如果當創建ASP.NET應用程序時出現允許您使用它的情況，則SqlDataReader類提供

比DataSet類更高的性能。情況之所以這樣，是因為SqlDataReader?使用SQLServer

的本機網絡數據傳輸格式從數據庫連接直接讀取數據。另外，SqlDataReader類實現

Enumerable接口，該接口也允許您將數據綁定到服務器控件。有關更多信息，請參見

SqlDataReader類。有關ASP.NET如何訪問數據的信息，請參見通過ASP.NET訪問數

據。

9.將SQLServer存儲過程用于數據訪問

在.NETFramework提供的所有數據訪問方法中，基于SQLServer的數據訪問是生

成高性能、可縮放Web應用程序的推薦選擇。使用托管SQLServer提供程序時，可通

過使用編譯的存儲過程而不是特殊查詢獲得額外的性能提高。

10.避免單線程單元(STA)COM組件

默認情況下，ASP.NET不允許任何STACOM組件在頁面內運行。若要運行它們，

必須在.aspx文件內將ASPCompat=true屬性包含在@Page指令中。這樣就將執行用

的線程池切換到STA線程池，而且使HttpContext和其他內置對象可用于COM對象。

前者也是一種性能優化，因為它避免了將多線程單元(MTA)封送到STA線程的任何調

用。

使用STACOM組件可能大大損害性能，應盡量避免。若必須使用STACOM組件,

如在任何interop方案中，則應在執行期間進行大量調用并在每次調用期間發送盡可能多

的信息。另外，小心不要在構造頁面期間創建任何STACOM組件。例如下面的代碼中，

在頁面構造時將實例化由某個線程創建的MySTAComponent,而該線程并不是將運行頁面

的STA線程。這可能對性能有不利影響，因為要構造頁面就必須完成MTA和STA線程

之間的封送處理。

<%@PageLanguage="VB"ASPCompat="true"%>

<scriptrunat=server>

DimmyCompasnewMySTAComponent()

PublicSubPage_Load()

myComp.Name="Bob"

EndSub

</script>

<html>

<%

Response.Write(myComp.SayHello)

%>

</html>

首選機制是推遲對象的創建，直到以后在STA線程下執行上述代碼，如下面的例子所

示。

<%@PageLanguage="VB"ASPCompat="true"%>

<scriptrunat=server>

DimmyComp

PublicSubPage_Load()

myComp=newMySTAComponent()

myComp.Name="Bob"

EndSub

</script>

<html>

<%

Response.Write(myComp.SayHello)

%>

</html>

推薦的做法是在需要時或者在Page_Load方法中構造任何COM組件和外部資源。

永遠不要將任何STACOM組件存儲在可以由構造它的線程以外的其他線程訪問的共

享資源里。這類資源包括像緩存和會話狀態這樣的資源。即使STA線程調用STACOM組

件，也只有構造此STACOM組件的線程能夠實際為該調用服務，而這要求封送處理對創

建者線程的調用。此封送處理可能產生重大的性能損失和可伸縮性問題。在這種情況下，請

研究一下使COM組件成為MTACOM組件的可能性，或者更好的辦法是遷移代碼以使

對象成為托管對象。

11.將調用密集型的COM組件遷移到托管代碼

.NETFramework提供了一個簡單的方法與傳統的COM組件進行交互。其優點是可

以在保留現有投資的同時利用新的平臺。但是在某些情況下，保留舊組件的性能開銷使得將

組件遷移到托管代碼是值得的。每一情況都是不樣的，決定是否需要遷移組件的最好方法

是對Web站點運行性能測量。建議您研究一下如何將需要大量調用以進行交互的任何

COM組件遷移到托管代碼。

許多情況下不可能將舊式組件遷移到托管代碼，特別是在最初遷移Web應用程序時。

在這種情況下，最大的性能障礙之?是將數據從非托管環境封送到托管環境。因此，在交互

操作中，請在任何一端執行盡可能多的任務，然后進行一個大調用而不是一系列小調用。例

如，公共語言運行庫中的所有字符串都是Unicode的，所以應在調用托管代碼之前將組件

中的所有字符串轉換成Unicode格式。

另外，-處理完任何COM對■象或本機資源就釋放它們。這樣，其他請求就能夠使用

它們，并且最大限度地減少了因稍后請求垃圾回收器釋放它們所引起的性能問題。

12.在VisualBasic.NET或JScript代碼中使用早期綁定

以往,開發人員喜歡使用VisualBasic.VBScript和JScript的原因之一就是它們所

謂“無類型，，的性質。變量不需要顯式類型聲明，并能夠簡單地通過使用來創建它們。當從一

個類型到另一個類型進行分配時，轉換將自動執行。不過，這種便利會大大損害應用程序的

性能。

VisualBasic現在通過使用OptionStrict編譯器指令來支持類型安全編程。為了向后

兼容，默認情況下，ASP.NET不啟用該選項。但是，為了得到最佳性能，強烈建議在頁中

啟用該選項。若要啟用OptionStrict,請將Strict屬性包括在@Page指令中，或者，對

于用戶控件，請將該屬性包括在@Control指令中。下面的示例演示了如何設置該屬性，

并進行了四個變量調用以顯示使用該屬性是如何導致編譯器錯誤的。

<%@PageLanguage="VB"Strict="true"%>

<%

DimB

DimCAsString

'Thiswillcauseacompilererror.

A="Hello"

'Thiswillcauseacompilererror.

B="World"

'Thiswillnotcauseacompilererror.

C="mm"

'Butthiswillcauseacompilererror.

C=0

%>

JScript.NET也支持無類型編程，但它不提供強制早期綁定的編譯器指令。若發生下

面任何一種情況，則變量是晚期綁定的：

被顯式聲明為Object。

是無類型聲明的類的字段。

是無顯式類型聲明的專用函數或方法成員，并且無法從其使用推斷出類型。

最后一個差別比較復雜，因為如果JScript.NET編譯器可以根據變量的使用情況推斷

出類型，它就會進行優化。在下面的示例中，變量A是早期綁定的，但變量B是晚期綁

定的。

varA;

varB;

A=,,Hellon;

B='World";

B=0;

為了獲得最佳的性能，當聲明JScript.NET變量時，請為其分配一個類型。例如，var

A:Stringo

13.使請求管線內的所有模塊盡可能高效

請求管線內的所有模塊在每次請求中都有機會被運行。因此，當請求進入和離開模塊時

快速地觸發代碼至關重要，特別是在不使用模塊功能的代碼路徑里。分別在使用及不使用模

塊和配置文件時執行吞吐量測試，對確定這些方法的執行速度非常有用。

14.使用HttpServerUtility.Transfer方法在同一應用程序的頁面間重定向

采用Server.Transfer語法，在頁面中使用該方法可避免不必要的客戶端重定向。

15.必要時調整應用程序每個輔助進程的線程數

ASP.NET的請求結構試圖在執行請求的線程數和可用資源之間達到一種平衡。已知一

個使用足夠CPU功率的應用程序，該結構將根據可用于請求的CPU功率，來決定允許

同時執行的請求數。這項技術稱作線程門控。但是在某些條件下，線程門控算法不是很有效。

通過使用與ASP.NETApplications性能對象關聯的PipelineInstanceCount性能計數

器，可以在PerfMon中監視線程門控。

當頁面調用外部資源，如數據庫訪問或XMLWebservices請求時，頁面請求通常停

止并釋放CPUo如果某個請求正在等待被處理，并且線程池中有一個線程是自由的，那么

這個正在等待的請求將開始被處理。遺憾的是，有時這可能導致Web服務器上存在大量

同時處理的請求和許多正在等待的線程，而它們對服務器性能有不利影響。通常，如果門控

因子是外部資源的響應時間，則讓過多請求等待資源，對Web服務器的吞吐量并無幫助。

為緩和這種情況，可以通過更改Machine.config配置文件節點的

maxWorkerThreads和maxIOThreads屬性，手動設置進程中的線程數限制。

注意輔助線程是用是處理ASP.NET請求的，而10線程則是用于為來自文件、數據

庫或XMLWebservices的數據提供服務的。

分配給這些屬性的值是進程中每個CPU每類線程的最大數目。對于雙處理器計算機,

最大數是設置值的兩倍。對于四處理器計算機，最大值是設置值的四倍。無論如何，對于有

四個或八個CPU的計算機，最好更改默認值。對于有一個或兩個處理器的計算機，默認

值就可以，但對于有更多處理器的計算機的性能，進程中有一百或兩百個線程則弊大于利。

注意進程中有太多線程往往會降低服務器的速度，因為額外的上下文交換導致操作系

統將CPU周期花在維護線程而不是處理請求上。

16.適當地使用公共語言運行庫的垃圾回收器和自動內存管理

小心不要給每個請求分配過多內存，因為這樣垃圾回收器將必須更頻繁地進行更多的工

作。另外，不要讓不必要的指針指向對象，因為它們將使對象保持活動狀態，并且應盡量避

免含Finalize方法的對象，因為它們在后面會導致更多的工作。特別是在Finalize調用中

永遠不要釋放資源，因為資源在被垃圾回收器回收之前可能一直消耗著內存。最后這個問題

經常會對Web服務器環境的性能造成毀滅性的打擊，因為在等待Finalize運行時，很容

易耗盡某個特定的資源。

17.如果有大型Web應用程序，可考慮執行預批編譯

每當發生對目錄的第一次請求時都會執行批編譯。如果目錄中的頁面沒有被分析并編

譯，此功能會成批分析并編譯目錄中的所有頁面，以便更好地利用磁盤和內存。如果這需要

很長時間，則將快速分析并編譯單個頁面，以便請求能被處理。此功能帶給ASP.NET性

能上的好處，因為它將許多頁面編譯為單個程序集。從己加載的程序集訪問一頁比每頁加載

新的程序集要快。

批