白皮書
Tony Northrup
本頁內容
- ASP.NET應用程序和javascript:;" onClick="javascript:tagshow(event, 'Web');" target="_self">Web服務
摘要
同先前的ASP程序相比，ASP.NET在性能上提供了極大的改進。雖然ASP.NET的標準配置
也可以提供遠遠超出先前環境的優異性能，但是管理員可能仍然需要對系統配置進行一些
調整，以實現最佳的性能表現和伸縮性。本白皮書面向系統管理員，介紹了調校構建于
.NET Framework之上的應用程序的性能所需掌握的技術，并且討論了ASP.NETWeb應用程
序、ASP.NET Web服務以及.NET遠程應用程序。
ASP.NET應用程序和Web服務
與其它類型的應用程序相比，Web程序和Web服務的性能調整工作應當引起更多的重視
和注意。這些應用程序一般面向外部用戶，而一個糟糕的Web站點肯定會給公司形象造
成十分惡劣的影響。和面向企業內部的應用程序不同，定位于外部用戶的公眾Web服務
可能會被數以百萬計的用戶所訪問，而內部應用程序的用戶數量則受公司員工規模的限制。
ASP.NET為系統管理員賦予了更多能力，使他們能夠對Web程序和Web服務的性能和規模
施加更有力的控制。新的會話狀態管理能力可以將有關用戶訪問的信息從應用程序之中完
全分離出來，管理員可以選擇將信息存儲在Web服務器的動態RAM中，存儲在狀態服務器
上，或者是存儲在一個數據庫中。內置的跟蹤功能則允許管理員將性能問題同某段具體的應
用程序代碼聯系起來--決定性地指出問題是由應用程序而不是系統配置問題引起的。
特別針對ASP.NET的新的性能計數器提供了有關應用程序性能的各個細節，為管理員解決系
統瓶頸提供了所需的信息�，F有的實用工具，例如Microsoft Web Application Stress（WAS）
工具可以用來產生站點流量，在真正的用戶發現站點存在的問題之前就將這些問題徹底解決。
由于ASP.NET既可以用來開發Web程序，也可以用來構建Web服務，管理員可以直接深入到下
一代Web商業的內部。本部分的內容將為管理員分析和調整各種ASP.NET應用程序的提供詳細
的分布指導。
調整會話狀態
對Web應用程序和Web服務進行伸縮所需面臨的最大挑戰之一便是：用戶狀態是由多個服務器
進行維護的。無論Web農場采用何種配置方式，在一個會話中，針對某個用戶的請求總是有可
能被轉發到兩個不同的系統上。如果所有的站點內容都是靜態的，那么將不會存在任何問題。
但是，現在大多數的Web站點都會對用戶會話進行跟蹤以保存同此用戶有關的特定信息，例如
喜好、個性化參數和購物車等。
先前版本的ASP允許開發人員訪問會話狀態信息，并且允許他們將有關用戶的信息存儲在這個
會話對象的內部。這些信息可以從站點的任何一個其它的頁面上進行訪問。但是，ASP會將
這些信息保存在Web服務器的內存之中。因此，如果使用多臺Web服務器，用戶的請求可能就
會被發送到一個與發起會話的服務器不同的其它服務器上，有關會話的信息將無法獲得。如果
某個Web服務器重新進行了啟動，它保存的所有會話信息都將丟失，這對站點的正常運轉會造
成不可估量的影響--尤其是在您使用該會話保存用戶購物車信息的時候。
ASP.NET提供傳統的單服務器會話信息，這和ASP的以前版本非常類似。此外，它還為會話信
息的集中提供了兩個方法，這使得用戶可以從Web農場或Web花園的很多不同服務器上獲得這
些會話數據。具體使用兩種方法中的哪一種完全由系統管理員來決定 -- 它并沒有以代碼形式固
定在程序之中。所以，對于那些不是針對Web農場進行設計的ASP .NET Web程序或Web服務，
系統管理員可以對其進行衡量和分等。
ASP.NET可以使用三種方法存儲會話狀態信息：存儲在進程中；存儲在一臺中央狀態服務器上；
或者存儲在SQL Server數據庫中。將會話信息保存在進程中這種方法與傳統的ASP會話類似，因
為會話狀態信息也保存在Web服務器的內存之中，不和其它系統進行共享。這種配置方法具有
最佳的執行性能，因為ASP.NET不需要同網絡中的其它系統通信以取得會話信息。但是，這種做
法限制了系統的伸縮性--會話不能跨越多臺服務器，而且如果用戶從一臺Web服務器移動到了另一
臺服務器上，他們的會話信息將被丟失。
狀態服務器是運行一種特殊服務的中央服務器，該服務內置在.NET Framework之中。狀態服務器
存儲狀態信息供Web農場中的多臺服務器使用。用戶可以從一臺Web服務器移動到另一臺，而
不會丟失狀態信息。狀態服務器引入了一些額外的工作負載，因為在每次用戶請求一個頁面的時候，
會話信息必須能夠通過從Web服務器發送到狀態服務器的網絡請求被檢索和被更新。雖然需要花費
一些額外工作來處理用戶請求，但是系統的伸縮性和可靠性卻因此得到了極大的提高，因為Web應
用程序可以伸縮到多個多臺服務器上。
存儲會話狀態信息的第三種方法是使用一個SQL Server數據庫。這種方法具有與使用中央狀態服務
器相同的好處 -- 會話可以跨越多臺Web服務器進行跟蹤。但是，同使用中央狀態服務器相比，使
用SQL Server服務器跟蹤會話產生的工作負載更大。SQL Server服務器能夠配置成群集的形式，從
而提供最大限度的冗余。此外，SQL Server可以伸縮到配備4顆處理器的高端硬件上，從而實現更
多會話的并發存儲。
以下部分針對存儲會話狀態信息的三種不同方法討論了相應的性能調整措施。所有三種方法可以使
用同一套配置參數，并且不會對系統性能造成不良影響。用戶可以使用一種“無需Cookie”的方式
來管理用戶狀態，這種方法將狀態信息作為URL的一部分，而不是將它們保存在一個Cookie當中。
ASP.NET將會話信息插入到給定頁面上所有鏈接的URL之中 --并且僅僅修改相對URL。因此，這種
無需Cookie的狀態管理不能工作在那些在一個ASP.NET應用程序的內部超鏈接上使用絕對URL地址
的站點上。
調整存儲在進程中（In Process）的會話狀態�！俺瑫r”設置定義了會話狀態在用戶進行上一次
請求后能夠存留的時間。默認情況下，該時間被設置為20分鐘。所以，如果用戶等上20分鐘后再向
服務器發送一個請求，服務器將創建一個新的會話。該設置不會影響系統，特別是在使用存儲在進
程中的會話的時候。超時時間定義的越長，在用戶不主動訪問您的站點期間會話中所存儲信息的存
活時間也就越長。但是，會話狀態在進程中進行維護會占用Web服務器的內存。
如果你的站點用戶較少，但是他們的停留時間比較長，或者他們每天都定期多次訪問你的站點，那么
你可以定義一個較長時間的超時設置。如果你的站點有成千上萬的用戶，而且這些用戶一般僅僅瀏覽
一兩個頁面就離開，那么你可以設置一個較短時間的超時設置。然后，請仔細監視Web服務器的運行
情況，以確定對會話狀態的維護是否會對系統性能造成不良影響。
為了調整超時設置，請監視“ASP.NET應用程序”對象中的“活動會話”（Sessions Active）計數器。
該計數器指出了當前活動會話的數目，一般來說，該數目會隨著超時時間的增加而增多。Web服務器
所能夠處理的最大會話數量隨存儲在會話中的信息應用程序數量不同而發生變化。但是，保有過多的
并發會話將消耗大量的服務器內存。因此，你還應該監視服務器的內存使用情況。如果在提高了會話
的超時時間設置之后，內存的分頁操作也隨之增加了，那么你應該減少會話的超時時間，或者在服務
器上增加更多的內存。能夠對內存的分頁操作進行較好表述的計數器是“內存”對象中的“每秒讀取
頁面的次數”（Page Reads/sec）計數器。
會話狀態選擇在machine.config或者web.config文件中定義。默認情況下，
中被定義為 “InProc”，這樣可以為運行在單臺Web服務器上的Web應用程序提供最佳的性能。
machine.config中的默認設置為：
sqlConnectionString="data source=127.0.0.1;user id=sa;password=" stateNetworkTimeout="10" stateConnectionString="tcpip=127.0.0.1:42424" mode="InProc" />
使用狀態服務器時的會話狀態配置。當你使用一臺狀態服務器管理會話狀態的時候， 可以通過
stateNetworkTimeout配置設置超時時間，時間單位為秒，ASP.NET Web應用程序將等待狀態服務
器對網絡請求做出響應。默認情況下，此時間被設為10秒鐘。有幾種原因會導致狀態服務器在10
秒鐘內不能做出響應--狀態服務器過載，Web服務器過載，或者狀態服務器處于離線狀態。如果
狀態服務器或者Web服務器上的流量很高（接近100%的處理器利用率），并且會話狀態對于
ASP.NET應用程序非常重要，你可以將此超時時間提高到20秒鐘。
通常，在和狀態服務器取得聯系之前，ASP.NET應用程序不會將用戶請求的Web頁面發送給用戶。
所以，如果狀態服務器沒有響應，最終用戶可能必須等到網絡超時之后才會接收到一條錯誤信息。
提高stateNetworkTimeout的值可以降低流量高峰期時發生錯誤的次數；但是，在獲知狀態服務器
離線之前，它會增加用戶被迫等待的時間。如果你的Web和狀態服務器的超時時間得到了正確配
置，你的應用程序應該可以對會話狀態錯誤進行妥善的處理。如果你的用戶在看到一個頁面之前
沒有等待10秒鐘的耐心，你可以將stateNetworkTimeout從10秒鐘減少到5秒鐘。如果你的Web和狀
態服務器經常以近乎100%的CPU利用率運行，并且會話狀態信息對于你的ASP.NET Web應用程序
很重要，你可以將stateNetworkTimeout提高到20秒。
狀態服務器的性能監視可以使用狀態服務器上的“性能”（Performance）控制臺和“事件查看器”
（Event Viewer）。您可以使用“性能”控制臺對“ASP.NET”對象中的“活動的狀態服務器會話”
（State Server Sessions Active）計數器加以監視。此外，您還可以監視處理器的利用率--既包括整
體利用率（“處理器”對象中的“% Processor Time”計數器，也包括每個會話狀態的利用率
（“進程”對象中“% Processor Time”計數器內的aspnet_state.ex實例） 。如果處理器利用率
達到了100%，Web服務器將對接收到的會話狀態信息請求進行排隊，從而損害Web站點的性能。
如果狀態服務器變得非常忙，以至于發生請求超時現象而不能提供狀態信息，將發生ID號從1072
到1076的錯誤事件，這些事件會被記錄在狀態服務器的應用程序事件（Application Event）日志中。
為了解決上述問題，您可以對狀態服務器上的處理器進行升級。
為了讓ASP.NET Web應用程序能夠使用中央狀態服務，您可以在應用程序的web.config文件中的
小節中加入以下信息。請特別注意stateConnectionString元素，它定義了狀態服務器的IP地址和端
口號--您應該根據您自己狀態服務器的實際情況修改這些屬性。sqlConnectionString屬性不是一個
必需的屬性，因為該設置僅僅在使用SQL Server存儲會話狀態信息時才發揮作用。
使用SQL Server時的會話狀態配置。Web農場的會話狀態可以使用一臺SQL Server服務器進行管理，
如果會話狀態信息的重要性足以使您考慮使用冗余服務器，那么使用SQL Server是您最佳的選擇。
ASP.NET State Service（狀態服務）不能進行冗余配置--只能使用單臺狀態服務器，所以如果該狀
態服務器發生故障變得不可用，ASP.NET Web應用程序將無法跟蹤用戶會話。對這臺SQL Server服
務器的性能監視同其它SQL Server服務器一樣。有關SQL Server性能監視方面的更多信息，請參閱
Microsoft Press出版的《SQL Server 2000 性能調整技術指南》一書。
說明：如果您決定使用SQL Server數據庫來保存會話狀態信息，您應該按照本文“SQL Profiler和Index
Tuning Wizard”一節中的介紹對ASPState數據庫進行調整。
為了讓某個ASP.NET Web應用程序使用SQL Server數據庫存儲狀態信息，請將以下信息添加到該程序
的web.config文件的
式，此外，您至少需要提供一個SQL Server的名稱或者IP地址，以及一個合法的用戶名和口令。為了
改善系統的安全性，您應該在SQL Server上創建一個具有最小權限的賬戶，而不是使用SA賬戶完成
這一切。
Web應用程序的壓力測試工具
Microsoft WAS工具是Microsoft 發布的一個免費工具，可以在Web服務器上產生流量負載。該工具
可以模擬數百個或數千個用戶同時對您的站點進行的訪問，然后生成一個帶有性能信息的匯總報告。
通過在Web服務器上施加額外負載并監視其性能的變化，你可以確定如何對應用程序進行伸縮，以
及哪些資源會對系統的伸縮性造成限制。WAS工具可以從以下地址免費下載：
http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&
DisplayLang=en. 本節內容將介紹使用WAS工具為ASP.NET頁面的呈現建立一個基準和加載測試用
ASP.NET Web服務的具體方法。如需獲得使用WAS工具的更詳細指導，請參閱：wast_2.asp">http://msdn.micro
soft.com/library/en-us/dnduwon/html/d5wast_2.asp.
WAS可以用來測試任何類型的Web服務器。測試ASP.NET Web程序和測試其它Web程序沒有什
么太大的不同--但是系統管理員在調整ASP.NET程序的性能時應該對WAS報告中的幾個關鍵部分
加以特別的重視。WAS報告中的“頁面摘要”（Page Summary）部分列出了測試期間被請求的
所有頁面、頁面被請求的次數、傳送首字節的時間（Time To First Byte ，TTFB）和傳送末字節
的時間（Time To Last Byte，TTLB）。TTFB指標可以用來斷定Web服務器提交一個ASP.NET頁
面所需花費的時間。為了獲得該時間，您可以：
- 在ASP.NET Web服務器所在局域網中的一臺計算機上安裝WAS。
- 創建一個WAS腳本，該腳本可以對站點上您希望測量的所有.ASPX頁面進行查詢。
- 選擇腳本設置，然后將“壓力級別”（Stress Level）和“壓力倍數”（Stress Multiplier）
設置為1，如圖1所示。這將迫使WAS使用單個客戶端請求所有頁面，以確保不會同時請
求多個頁面。
圖1 將WAS配置為只使用一個客戶端是創建ASP.NET Web程序性能基準測試的一種優秀方法。
- 接下來，在“測試時間”（Test Run Time）下，將時間值設定為5分鐘。這樣可以獲得一個數量合
理的取樣點數目。 - 在“暫�！保⊿uspend）下，將“預熱”（Warmup）時間設定為1分鐘，以確保在您開始測量之前
每個頁面均被請求了數次。ASP.NET頁面在初次請求時需要進行編譯--因此，第一次獲得所請求頁
面的時間特別長，您不應該使用這些時間來建立性能基準。預熱期還會產生各種緩存，這些緩存將
在以后的時間發揮效力。 - 點擊工具欄“運行腳本”（Run Script）按鈕。腳本將被執行。
- 在腳本完成之后，請點擊“報告”（Reports）選項卡，然后選擇新的報告。向下滾動內容直到
“頁面摘要”（Page Summary）部分，如圖2所示。每個頁面的TTFB數值是以毫秒為單位的時
間值，在輕負載的情況下，您的ASP.NET應用程序需要花費這些時間為用戶提交頁面。
圖2 TTFB Average指標指出了提交ASP.NET頁面所需花費的時間。
在輕負載情況下測量TTFB可以建立一個基準。將輕負載下的TTFB值與重負載情況下的TTFB值相比較，
您便可以了解到應該如何對Web應用程序進行伸縮，以及這種伸縮將會對最終用戶的Web體驗產生何種
影響。如果TTFB值高于1000毫秒（即1秒鐘），在正常流量情況下，產生ASP.NET頁面所需的時間便有
可能對用戶的瀏覽體驗產生影響。通過升級Web服務器的處理器、調整數據庫訪問方式以及采取本文介
紹的其它方法，這個時間可以被降低。
在你打開WAS報告的時候，請注意該報告的“結果代碼”（Result Codes）部分。唯一應該被列出的結
果代碼是“200”--表明所有的請求都已經成功完成。隨后，當你在更高的負載下運行此測試的時候，你
將可以看到一些錯誤，這表明該ASP.NET已經到達了它的能力上限。為了提高服務器的工作負載，你可以選擇“設置”（Settings），然后增加“壓力級別”（Stress Level）和“壓力倍數”（Stress Multiplier）的數值。你可以逐步提高這些設置，并且將得到的結果同第一次測試得到的基準結果進行對比，了解站點性能是如何隨著流量增加而變慢的。應用程序瓶頸的識別方法，請遵照本文“識別系統瓶頸”部分中的指導進行操作。
WAS還可以用來測試ASP.NET Web服務。默認情況下，當瀏覽器請求一個.ASMX文件時，ASP.NET Web服務會生成一個可視的頁面。用戶可以在表單域中輸入信息，然后請求會被調用的Web服務進行處理。這些自動生成的頁面使用HttpGet Web服務協議，該協議是ASP.NET Web服務默認使用的協議。WAS可以使用該接口模擬由多個并發客戶端發出的Web服務請求，如圖3所示。針對現有的Web服務生成WAS腳本的最容易方法是使用WAS記錄你在瀏覽器中手動輸入的這些請求，然后刪除請求路徑中的“？”字符后面不包括參數的任何步驟。如果你的Web服務客戶端使用了HttpSoap方法，結果將不是一種完美的模擬。但是，對于識別性能瓶頸來說，它仍然不失為一種有用的手段。
圖3 通過創建一個腳本，利用合適的參數發出對.ASMX文件的請求，WAS可以對使用HTTPGet方法的Web服務進行測試。
識別系統瓶頸
無論您是采用Microsoft WAS工具來人為地產生一些流量，或者是已經擁有了一個繁忙的站點，對負載情況下Web服務器的性能進行監視均是很重要的。監視服務器資源利用率的最佳工具是性能控制臺。在Windows 2000中，您可以點擊“開始”按鈕、將鼠標指向“程序”，選擇“管理工具”，然后點擊“性能”，以啟動該控制臺。在Windows Server 2003中，您可以點擊“開始”按鈕，指向“所有程序”，選擇“管理工具”，然后點擊“性能”。表1給出了識別ASP.NET應用程序瓶頸所需的最重要性能計數器。
表1 識別系統瓶頸所用到的性能計數器
| 對象 | 計數器 | 描述 |
|---|---|---|
| 處理器 | % 利用率百分比 | 本指標指出了Web服務器上處理器的總體利用率。處理器是ASP.NET Web服務器上最為常見的瓶頸所在。如果當Web處理負載時該計數器的峰值數值接近100% ，您就應該添加“進程”對象中的“% Processor Time”計數器，以確定出究竟是哪一個進程拖累了服務器的性能。 |
| 進程 | % 處理器時間百分比 | 本計數器提供的信息與“% CPU Utilization”計數器類似，但是它可以識別出具體是哪一個進程耗用了大部分的CPU時間。為了確保能夠收集到所需的全部信息，您應該在添加該計數器時，選中“添加計數器”（Add Counters）對話框中的“所有實例”（All Instances）單選按鈕。如果aspnet_wp 進程占用了大部分處理器時間，這就清楚地說明了ASP.NET頁面的呈現是系統的瓶頸所在。如果inetinfo進程出現問題，說明是IIS引起的問題。這些問題可以通過升級Web服務器的CPU、增加多個CPU或者添加更多Web服務器得到解決。如果你的ASP.NET應用程序是由數據庫驅動的，并且你在相同系統上運行一個Microsoft SQL Server，你很可能會發現名為sqlservr的進程是引起CPU瓶頸的罪魁禍首。對這種情況的最佳補救方法便是將SQL Server移動到另一臺服務器上�；蛘�，升級處理器或者增添更多的處理器也有助于改善這種情況。 |
| ASP.NET應用程序 | 每秒的請求數 | 本計數器可以測量ASP.NET請求的接收速度，對于在過載情況下測量Web應用程序的峰值處理能力來說，它也是一種有用的手段。該計數器只會報告針對特定文件的請求數目，這些傳遞給ASP.NET的文件的擴展名在IIS中進行配置，大多數情況下，它們是一些.ASPX和.ASMX文件。為了查看總的請求數，包括對圖像文件的請求，您可以使用“Web服務”對象中的“Get Requests/sec”計數器代替本計數器。 |
| ASP.NET應用程序 | 活動會話的數目 | 此計數器用來測量當前處于活動狀態的ASP.NET會話的數目。會話是在新的用戶發出第一次請求時由ASP.NET程序建立的。會話一直存活，直到：1) 當用戶退出登錄時，程序明確地放棄了該會話，或者2)在會話超時時間內沒有從用戶處接收到任何請求。默認情況下，ASP.NET的會話將在20分鐘后超時。用戶可以修改web.config或machine.config文件中元素的sessionState屬性來調整該設置。有關會話和超時時間設置的更多信息，請參看本文的“調整會話狀態”一節。 |
| ASP.NET | 隊列中請求的數目 | 本計數器指出了當呈現一個頁面所需的時間超過了所接受的兩個客戶端請求之間的時間間隔之后，在隊列中進行排隊的請求數目。在正常的Web流量下，用戶發出請求的速度是不確定的，在最繁忙的時刻，幾秒鐘內就會發生排隊現象。這使得提交頁面的時間臨時性地增加了，但是在接下來的空閑時段，隊列又會很快被消除。負載測試工具（例如WAS）產生的流量一般比較穩定，所以可能引起ASP.NET的“Requests Queued”計數器持續攀升，盡管在實際的應用情境之中，這種情況可能并不會出現。為了模擬這些隨機出現的流量高峰和低谷，您可以在WAS的“腳本設置”頁中選中“使用隨機延遲”（Use Random Delay）復選框。如果在啟用了該設置之后，該計數器的數值仍然繼續增加，說明該服務器當前的工作負載已經超出了它的能力范圍，它將成為一個系統瓶頸，您應該在繼續測試之前解決這個瓶頸問題。默認情況下，ASP.NET的隊列長度最大可以容納100個請求。您可以修改web.config或machine.config文件中httpRunTime元素的appRequestQueueLimit屬性來改變這一限制。 |
| ASP.NET | 被拒絕的請求數 | 在ASP.NET請求隊列被充滿之后，新的請求將被拒絕。對于極高負載的情況，這種處理方法對于ASP.NET一般都是正確的，因為它會立即向用戶返回一個錯誤，并且從Web服務器的隊列之中刪除該請求，而不是強迫用戶等待，直到瀏覽器超時。對本計數器進行監視可以獲知在隊列長度達到最大之后，Web服務器所接受到請求總數是多少。 |
使用跟蹤
ASP.NET Web程序和Web服務能夠對請求和響應進行強有力的跟蹤。雖然跟蹤工具面向開發人員，主要是為他們解決程序錯誤和優化程序性能提供的，但是它也可以被系統管理員用來向開發人員提供有關程序性能的特定反饋意見。啟用跟蹤會增加系統的性能負載，并且可能會暴露一些私人信息，所以只有在對一個程序進行主動分析時，才應該啟用跟蹤。為了啟用程序跟蹤，您可以在該程序的web.config文件的
必須進行修改的關鍵屬性是enabled=”true”。如果您直接連接到Web服務器的桌面，請設置localOnly=”true”屬性。該設置確保了遠程用戶不能訪問有關應程序的細節信息。您也可以通過使用localOnly=”false”設置讓遠程系統能夠查看跟蹤信息，但是這樣做具有一些潛在的安全風險，可能會把跟蹤信息暴露給外界。pageOutput=”false” 設置是針對生產用服務器的唯一安全設置；但是，你可以在開發服務器上使用pageOutput=”true” 設置，以在每一個ASP.NET頁面的底部查看跟蹤信息。requestLimit=”10” 的默認設置規定了只有同前10個ASP.NET請求有關的信息會被存儲。如果需要，你可以提高此數值；但是，這樣做會增加跟蹤工作的工作量。
在對某個程序進行跟蹤的時候，你可以從一個應用程序的根目錄那里請求一個特殊的頁面，即trace.axd。為了在Web服務器上的瀏覽器中查看該頁面，您可以打開如下URL地址： http://localhost/trace.axd。你會看到一個主跟蹤頁面，如圖4所示。請注意：trace.axd文件實際上并沒有真的存在于應用程序的根目錄下--該請求被ASP.NET截取了，并且進行了動態處理。
圖4 應用程序跟蹤是深入應用程序邏輯，揭開性能瓶頸根源的有用方法。
當你點擊請求的“查看詳細信息”（View Details）連接時，你將會看到“請求詳細信息”（Request Details）頁面。該頁面提供了有關ASP.NET頁面組成和它的底層組件的非常詳盡的信息。在“跟蹤信息”（Trace Information）部分，如圖5所示，展示了頁面呈現的每個階段所需花費的時間。應用程序開發人員還可以在此部分中插入特定于應用程序的信息，以允許管理員發現開發人員代碼中存在的性能問題。在跟蹤信息部分，請檢查“From Last(s)”列以確定完成哪一個階段需要花費的時間最長。
說明：默認情況下，ASP.NET Web程序（.ASPX文件）會產生很多有用的跟蹤信息。管理員還可以跟蹤ASP.NET Web服務（.ASMX文件），但是除非開發人員在Web服務中明確地整合進了跟蹤能力，否則“Trace Information”和“Control Tree”（控件樹）部分將是一片空白。
圖5 “請求詳細信息”的“跟蹤信息”部分使得管理員能夠將問題原因縮小到某個特定的頁面上。
“請求詳細信息”頁面的下一個部分是“控件樹”（Control Tree），如圖6所示�？丶䴓淞谐隽隧撁嬲{用的每一個控件的名稱、類型、控件生成的HTML字符數量以及viewstate的字節大小。ASP.NET頁面一般由不同的控件組成。一個ASP.NET控件可以是一個表格、一個超鏈接、一個工具欄或者能夠包括在Web頁面中的其它任何東西。
圖6 “控件樹”展示了給定頁面上每個控件的細節。
Viewstate是一個插入到HTML之中的隱藏字段，ASP.NET用它來跟蹤頁面的當前設置。程序開發人員經常在不需要它的控件上啟用viewstate，這會造成頁面產生不必要的臃腫，而控件樹則有助于解決這些問題。在控件樹的下方，“請求詳細信息”頁面顯示了同頁面和請求有關的每一件事情。這些信息對于解決程序錯誤和分析性能問題十分有用。
說明：在完成所有工作之后，不要忘記在
配置設置
系統管理員能夠對ASP.NET程序施加強有力的控制。決定應用程序性能的很多方面都可以通過machine.config和web.config文件進行配置。有關ASP.NET配置的一般性信息，請參閱http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q307626&. 在本節之中，我們將介紹三種可以極大影響ASP.NET性能的配置設置：調試、進程模型以及數據源配置。
禁用調試。ASP.NET包括了一個特殊的調試模式，來幫助開發人員解決程序中存在的問題。調試模式會增加系統負載，并降低系統的整體性能，在投入實際生產應用的ASP.NET Web服務上，應該禁用調試模式。調試模式在machine.config文件的
vb" explicit="true" debug="false">
配置進程模型。如果ASP.NET運行在Windows 2000環境下的IIS 5.0 Server上，machine.config文件的
說明：machine.config文件中的大多數元素都可以通過在web.config文件中放置元素內容而被取代。默認情況下，
tdownTimeout="0:00:05" idleTimeout="Infinite" enable="true" />
表2 屬性
| 屬性名稱 | 默認設置 | 描述 |
|---|---|---|
| cpuMask | 0xffffffff。本設置會導致ASP.NET為Web服務器上的每一顆處理器啟動一個單獨的ASP.NET進程。 | 用來將ASP.NET限制到多處理器系統中的某些特定處理器上。只有在webGarden屬性設置為“false”之后，該屬性才會起作用。如果ASP.NET和SQL Server運行在同一個系統上，并且SQL Server使用了相反的cpuMask設置，設置本屬性可能會改善系統的性能表現為了計算出需要的cpuMask值，您可以使用附件中的計算器，并且將其設置為科學模式。然后選擇二進制計算模式，為ASP.NET將要使用的每一顆處理器輸入一個“1”。為每一顆不會被用到的處理器輸入一個“0”。然后，將這個數字轉換成16進制，并且據此修改machine.config文件中的本元素值。請確信你輸入的數字是以 ‘0x’ 開頭的，以表明你輸入的是一個16進制的數。 |
| webGarden | false | 本設置會導致ASP.NET使用cpuMask屬性來識別應該為ASP.NET使用哪些處理器。如果將本屬性設置為“true”，ASP.NET將使用Windows操作系統自身的調度機制。 |
| requestQueueLimit | 5000 | 如果ASP.NET接受請求的速度大于它響應請求的速度，那么，這些請求將進入隊列排隊，直到有空閑的處理能力對它們進行處理為止。如果隊列的增長超過了特定的規模，ASP.NET將使用一個“服務器過于繁忙”的錯誤響應用戶的請求。根據應用程序的不同，發送這樣的一個錯誤可能要比強迫用戶等待服務器響應要好很多。 |
| serverErrorMessageFile | 沒有設定- 交由ASP.NET進行動態處理 | 如果發生一個錯誤，文件的絕對路徑將會發送給用戶，例如，在requestQueueLimit屬性達到設定值的時候。管理員應該使用本設置為用戶提供友好的錯誤信息，通知他們發生了什么問題，并且提醒他們在稍候的時間再次進行嘗試。 |
配置數據源。 某些應用程序允許管理員定義數據源。如果一個ASP.NET程序既可以使用OLEDB數據源，也可以使用固有的SQL數據源，那么您應該盡可能地使用SQL數據源。與使用在ODBC數據源管理器中進行配置的數據源名稱（DSN）相比，使用ASP.NET內置的SQL客戶端可以將系統性能提高50%之多。不幸的是，在指示應用程序應該以何種方式訪問數據方面，目前還沒有一種連續一致方法可供使用，所以，請參考該應用程序的文檔。
構建于.NET Framework之上的其它應用程序
專為ASP.NET基礎結構設計的應用程序為系統管理員調整程序性能賦予了更多的控制能力。但是，還有很多應用程序不使用ASP.NET。例如，.NET 遠程Web服務便沒有利用ASP.NET，因此，如果希望分析這些應用程序的性能表現，監視ASP.NET性能計數器并不是一個好的辦法。此外，.NET遠程應用程序不支持HttpGet Web服務協議，所以也不能使用WAS為這些程序產生負載。事實上，對于.NET遠程程序，系統管理員必須依靠程序開發人員才能完成大量的性能分析和調整工作。但是，通用語言運行時（Common Language Runtime，CLR）卻提供了幾個有用的性能計數器，如表3所示。 表3 CLR提供的性能計數器
| 對象 | 計數器 | 描述 |
|---|---|---|
| .NET CLR Remoting | Remote Calls/sec | 用來測量接收遠程請求的當前速度。本計數器使得管理員能夠精確地測量出應用程序的當前負載。 |
| Process | % Processor Time | 該計數器可以測量某個特定進程消耗的處理器百分比。每一個.NET遠程程序都有一個唯一的進程名稱，該名稱同程序可執行文件的名稱相匹配。對“Remote Calls/sec”計數器和“% Processor Time”計數器進行監視可以幫助系統管理員更好地理解每個遠程調用所需花費的處理時間。 |
| .NET CLR Networking | Bytes Sent, Bytes Received | “Bytes Sent”和“Bytes Received”計數器可以測量由所有的.NET CLR應用程序產生的網絡流量，這對于測量程序產生的流量大小很有幫助。它并不包括ASP.NET Web應用程序和Web服務產生的流量。 |
| .NET CLR LocksAndThreads | Total # of Contentions, Current Queue Length | 運行在CLR中的所有應用程序所發生爭用的數目。對于健康的應用程序，發生系統資源的爭用是一件正常的事情。但是，如果在發生間歇性的性能問題期間，該數字保持上升，就說明某個關鍵的系統資源被某一個程序鎖定了。這可能是某個應用程序低效使用系統資源的標志，可以由程序開發人員來糾正這一問題。 |
| .NET CLR Data | SqlClient: Current # pool and nonpooled connections | 測量.NET程序的活動SQL連接的數目，包括ASP.NET程序。 |
Internet信息服務
IIS是ASP.NET Web程序、ASP.NET Web服務和很多.NET遠程程序的重要組成部分。理解IIS性能調整的重要性是實現高性能.NET程序的關鍵。對IIS進行的調整并不僅僅針對ASP.NET一家，而且已經有大量的相關文檔可供學習。因此，這一部分的內容不是本文的講述重點。有關IIS性能調整的更詳細信息，請閱讀題為“利用IIS5.0對Web服務器進行性能調整的藝術和科學”的白皮書，該白皮書可從以下地址獲得。
SQL Server
構建于.NET Framework之上的大部分應用程序都連接到SQL Server上檢索數據。在很多情況下，數據庫或者數據庫連接會成為程序的性能瓶頸。對于由數據驅動的程序，理解SQL Server的性能問題對程序整體性能的調整有著不言而喻的重要意義。程序開發人員對使用何種方法從SQL Server數據庫中取得數據有著很大的發言權，而他們所做出的選擇對程序的整體性能有著極其重要的影響。雖然程序進行的某個特定查詢一般不能由系統管理員進行修改，但是你可以分析一個.NET程序對數據庫所發出請求的類型，并且據此對索引方式加以調整。本節內容將給出有關SQL Server索引調整的一個詳細的分布指導-- 一種可能會迅速提高程序性能的方法。有關SQL Server性能的詳細信息，請閱讀Microsoft Press出版發行的SQL Server 2000性能調整技術指南一書。
改善SQL Server性能的一種容易方法是結合使用索引調整向導（Index Tuning Wizard）和SQL Profiler。Profiler可以記錄SQL Server接收到的查詢，并且將它們記錄在一個文件或者數據庫的一個表中。索引調整向導能夠分析這些文件，找出應該對數據庫設計進行的修改，以改善數據庫性能，同時允許系統管理員選擇最為適合的修改方式。這些工具的運行會增加數據庫的工作負載，所以您不應該在負荷已經接近最大處理能力的生產系統中運行這些工具。為了使用Profiler和Index Tuning Wizard優化您的數據庫設計，您應該：
- 登錄到SQL Server的控制臺中。
- 點擊“開始”按鈕，指向“程序”，指向“Microsoft SQL Server”，然后點擊“Profiler”。
- 打開“文件”菜單，點擊“新建”，選擇“跟蹤”，以創建一個新的跟蹤。
- 在“連接到SQL Server”對話框中，選擇您的SQL Server和身份驗證方法，然后點擊“確定”。
- 在“跟蹤屬性”對話框中，從模板名稱下拉列表中選擇“SQLProfilerTuning”。選中“保存到文件”復選框，然后在“另存為”對話框中輸入一個新的文件名。點擊“保存”。
- 點擊“運行”按鈕開始記錄發送給SQL Server的請求，如圖7所示。如果你的程序當前處于活動狀態，請讓優化器運行足夠長的時間，以便至少能夠收集到100行的數據。如果您的程序當前沒有在運行，請以一種最為典型的方式啟動該程序以產生數據請求。
圖7 Profiler收集SQL請求供Index Tuning Wizard分析使用。
- 在收集到足夠的請求之后，點擊工具欄上的“停止”按鈕。從“工具”菜單中，選擇“Index Tuning Wizard”（索引調整向導）。該向導將出現，如圖8所示。點擊“下一步”按鈕，然后在接到提示時選擇你的數據庫服務器。
圖8 Index Tuning Wizard分析由Profiler產生的工作負載文件，并且對如何修改索引以改善性能提出建議。
- 在Index Tuning Wizard頁中，從“數據庫”列表中選擇應用程序最常使用的數據庫。如果你的應用程序需要同一個以上的數據庫展開通信，你應該在每一個數據庫上重復上述過程。然后點擊“下一步”按鈕。
- 在“指定工作負載”頁中，選擇“我的工作負載文件”（My Workload File）單選按鈕。在“打開”對話框中，選擇你在步驟5中指定的文件。點擊“打開”按鈕，然后點擊“下一步”。
- 在“選擇需要調整的數據表”（Select Tables To Tune）頁上，點擊“選擇所有數據庫”（Select All Tables）按鈕。點擊“下一步”。此時，Index Tuning Wizard將試著找出現有索引存在的問題以及解決辦法，以改善數據庫性能。這個過程將持續數分鐘。
- 在完成分析之后，你將看見“索引建議”（Index Recommendations）頁。如果Index Tuning Wizard找到了可以改善性能的方法，它將把這些方法在本頁面中羅列出來，并且對可能產生的性能改進做出評估。一般來說，你可以安全地接受這些修改。點擊“下一步”繼續。
- 在“完成索引調整向導”（Completing the Index Tuning Wizard）頁上，點擊“完成”按鈕關閉向導，然后在收到提示時點擊“確定”按鈕。另外，你可能還需要關閉SQL Profiler。
結論
系統管理員可以對以.NET Framework.為基礎構建的程序性能進行深入的剖析和控制。例如， ASP.NET便具有會話狀態跟蹤能力，可以對每個應用程序進行單獨跟蹤。這些功能使得管理員可以調整一個應用程序的工作，使其滿足他們的工作環境對性能、伸縮性和可靠性的獨特需要。本白皮書介紹了監視.NET Framework程序性能、模擬繁忙條件和配置主要性能參數的方法。如果希望獲得更多有關程序性能調整的信息，請訪問以下地址： http://msdn.microsoft.com/library/en-us/dnduwon/html/d5dplyover.asp.
