這篇文章討論了：

·一般視頻教程'>asp.net性能的秘密

·能提高asp.net表現的有用的技巧和竅門

·在ASP.NET中使用數據庫的建議

·ASP.NET中的緩存和后臺處理

       使用ASP.NET編寫一個Web應用程序是難以置信的簡單的。太簡單了，以至于很多開發者都不花費時間來構建他們的應用程序來達到很好的表現。在這篇文章里，我將為編寫高性能的Web應用程序推薦10個技巧。我不會講我的論述局限于ASP.NET應用程序，因為ASP.NET應用程序只是Web應用程序的一個子集而已。這篇文章不會是針對優化Web應用程序的性能的權威性指導——一本完整的書可以很容易的做到這一點。相反，我們應該把這篇文章當成一個好的起點。

       在成為一個工作狂以前，我會經常去攀巖。在做任何攀巖活動之前，我更愿意看看旅行指南里面的路線，再讀讀那些曾經到過峰頂的人做的推薦。但是，不管旅行指南寫的有多好，在嘗試一個有挑戰性的目標之前，您都需要有實際的攀巖經驗。與之相似，當您面臨修復性能問題或者運行一個高吞吐量站點的問題時，您只能學習如何編寫高性能 Web 應用程序。

       我的個人經驗來自在微軟的ASP.NET團隊中擔任過一名基礎程序經理的經歷，維護和管理www.asp.net，還有幫助構架Community Server，它是幾個著名的ASP.NET應用程序（ASP.NET Forums，.Text，和連接到一個平臺的nGallery）的下一個版本。我相信這些曾經幫助過我技巧中的一些也會對您有用的。
    
       您應該考慮把您的應用程序分離為幾個邏輯層次。您可能已經聽說過3層（或者n層）體系結構。這些通常都是規定的結構模式，它們將業務和（或）硬件從物理上進行了功能劃分。如果系統需要更大的規模，更多的硬件可以輕松的加進來。然而，那會產生一個與業務和機器跳躍相關聯的性能下降，因此我們應該避免它。所以只要可能，盡量在同一個應用程序中運行ASP.NET頁面和頁面的相關組件。
 
       因為代碼的分離和層次之間的邊界，使用Web服務或者遠程處理會降低性能20%甚至更多。

       數據層有點與眾不同，因為通常情況下，最好具有專用于數據庫的硬件。然而，然而進程跳躍到數據庫的成本依然很高，因此在數據層的性能是您優化代碼時應該首先考慮的。

       在投入到修復您的應用程序的性能問題之前，確保您要先分析您的應用程序來發現問題的根源所在。關鍵性能計數器（例如那個指示在執行垃圾收集過程中花費的時間百分比的計數器）在找出應用程序在哪里花費了主要的時間時也是非常有用的。雖然那些花費時間的地方經常是不那么直觀的。

       在這篇文章中我討論了兩種改進性能的方法：大塊的優化，例如使用ASP.NET緩存，還有小塊的優化，它們經常重復出現。這些小塊的優化有時是最有意思的。您對代碼的一個小的修改會被調用成千上萬次。對大塊的優化，您可能會發現整個的性能有了一個大的飛躍。對小塊的優化，您可能會縮減了對一個給定請求的幾微秒的時間，但是如果把每天的所有的請求累積起來，性能就會得到一個意想不到的改進。

數據層中的性能
 
       當您要開始優化一個應用程序的性能的時候，有一個決定性的測試您可以優先考慮使用：代碼是否要訪問數據庫？如果是，多長時間訪問一次？注意這個測試也可以應用到那些使用Web服務或者遠程控制的代碼中，但是我不會在這篇文章中涉及那些內容。

       如果在您的代碼中的某個代碼路徑中要求一個數據庫請求，而您發現其他地方您想要優先優化，例如字符串操作，那么停下來然后先執行關鍵性的測試。除非您有一個性能實在糟糕的問題要處理，否則您的時間會得到更好的利用，如果您把時間花在優化數據庫連接的時間，返回的數據量，還有您作的往返數據庫的操作中。

       現在我已經總體介紹了相關的信息，下面讓我們看看10條幫您的應用程序表現更好的技巧。我會從那些對改善性能效果最明顯的地方開始說。

技巧 1——返回多個結果集

        查看一下您的數據庫代碼，看看您是否有訪問數據庫多于一次的請求路徑（request paths）。每個這樣的往返都回降低您的應用程序每秒可以服務的請求的數量。通過在一次數據庫請求中返回多個結果集，您可以減少數據庫通信消耗的總時間。在您減少了數據庫服務器管理的請求之后，您也會使您的系統更具可升級性。

       一般您可以使用動態sql語句來返回多個結果集，我更喜歡用存儲過程。是否應該把業務邏輯放在存儲過程中是存在爭議的，但我認為如果一個存儲過程中的邏輯可以限制返回的數據（減少數據集的大小，花在網絡連接上的時間，并且不需要過濾邏輯層的數據），那它就是好東西。

       使用一個SqlCommand實例和它的ExecuteReader方法來生成強類型的業務類，您可以通過調用NextResult讓結果集指針向前移動。圖1展示了一個使用定義的類生成幾個ArrayList的示例會話。只從數據庫返回您需要的數據會顯著地減少您服務器上的內存申請。

 1// read the first resultset
 2reader = command.ExecuteReader();
 3
 4// read the data from that resultset
 5while (reader.Read()) {
 6    suppliers.Add(PopulateSupplierFromIDataReader( reader ));
 7}
 8
 9// read the next resultset
10reader.NextResult();
11
12// read the data from that second resultset
13while (reader.Read()) {
14    PRoducts.Add(PopulateProductFromIDataReader( reader ));
15}
16
17


技巧 2——分頁數據訪問
 
       ASP.NET的DataGrid提供了一個非常棒的能力：對數據分頁的支持。當在DataGrid中設置了分頁，那么將一次顯示一個特定數目的結果。此外，用來在結果之間導航的分頁UI也會在DataGrid的底部顯示出來。分頁UI允許您在顯示的數據之間向前導航或者向后導航，每頁顯示特定數目的結果。

         但是有一個小問題。使用DataGrid分頁時需要所有的數據都綁定到表格。例如，您的數據層會需要返回所有數據，然后DataGrid要根據當前頁填充所有要顯示的記錄。如果當您在使用DataGrid分頁時返回了100，000條記錄，每次請求都會丟棄99，975條記錄（假設每頁的容量是25條記錄）。當記錄的數量不斷增長時，應用程序的性能會受到很大的影響，因為每次請求都必須返回越來越多的數據。

       一個寫出更好的分頁代碼的辦法是使用存儲過程。圖2顯示了一個示例存儲過程，它為Nothwind數據庫中的Orders數據表分頁?？偟膩碚f，在這里所有您需要做的就是傳入頁的索引和頁的容量。數據庫會計算出適當的結果集然后返回它們。

 1CREATE PROCEDURE northwind_OrdersPaged
 2(
 3    @PageIndex int, 
 4    @PageSize int
 5)
 6AS
 7BEGIN
 8DECLARE @PageLowerBound int
 9DECLARE @PageUpperBound int
10DECLARE @RowsToReturn int
11
12-- First set the rowcount
13SET @RowsToReturn = @PageSize * (@PageIndex + 1)
14SET ROWCOUNT @RowsToReturn
15
16-- Set the page bounds
17SET @PageLowerBound = @PageSize * @PageIndex
18SET @PageUpperBound = @PageLowerBound + @PageSize + 1
19
20-- Create a temp table to store the select results
21CREATE TABLE #PageIndex 
22(
23    IndexId int IDENTITY (1, 1) NOT NULL,
24    OrderID int
25)
26
27-- Insert into the temp table
28INSERT INTO #PageIndex (OrderID)
29SELECT 
30    OrderID
31FROM 
32    Orders
33ORDER BY 
34    OrderID DESC
35
36-- Return total count
37SELECT COUNT(OrderID) FROM Orders
38
39-- Return paged results
40SELECT 
41    O.*
42FROM 
43    Orders O,
44    #PageIndex PageIndex
45WHERE 
46    O.OrderID = PageIndex.OrderID AND
47    PageIndex.IndexID > @PageLowerBound AND
48    PageIndex.IndexID < @PageUpperBound
49ORDER BY 
50    PageIndex.IndexID
51
52END
53
54

      在社區服務期中，我們寫了一個分頁服務端控件來做這些數據分頁。您會發現我在使用技巧1中討論過的思想，從一個存儲過程返回兩個結果集：紀錄總數和請求的數據。

       返回的記錄總數可以根據執行的請求而有所不同。例如，一個WHERE分句可以用來約束返回的數據。我們必須知道要返回的記錄總數，以計算要在分頁UI中顯示的總的頁數。例如，如果有1，000，000條總的記錄數，而一個WHERE分句用來把這些記錄過濾為1，000條記錄，分頁邏輯需要知道總的記錄數來恰當的提交分頁UI。


技巧 3——連接池
 
       在您的Web應用程序和SQL Server之間建立TCP連接會是一個昂貴的操作。Microsoft的開發者們已經利用連接池有一段時間了，這允許他們重用與數據庫的連接。與其為每個請求建立一個新的TCP連接，還不如只有在連接池中沒有一個可用的連接的時候才建立一個新的連接。當連接關閉后，它返回到連接池中——它還保持著與數據庫的連接，而不是完全銷毀那個TCP連接。

         當然您需要小心泄露的連接?？偸顷P閉您的連接在您使用完它們時。我重復一遍：不管誰說了關于Microsoft .NET框架的垃圾回收機制的什么話，當您使用完時，您務必總是對您的連接顯式調用Close或者Dispose方法。不要相信通用語言運行時（CLR）會在一個預定的時間為您清理和關閉您的連接。CLR會最終銷毀類并且強迫連接關閉，但您不能保證什么時候在對象上的垃圾回收機制會真正執行。

       要想使用連接池達到最佳效果，您需要遵循幾條規則。第一，打開一個連接，完成工作，然后關閉連接。如果您不得不（最好應用技巧1）為每個請求打開和關閉幾次連接也是可以的，這比一直開著連接然后把它傳遞給幾個不同的方法要好得多。第二，使用同一個連接字符串（如果您在使用集成身份認證，當然還需要有相同的線程標識）。如果您不使用同一個連接字符串，例如基于登錄的用戶的不同自定義連接字符串，您就不能得到連接池提供的相同的最優值。而且如果您在模仿大量的用戶時使用了集成身份驗證，您的連接池的效率也會降低很多。在嘗試跟蹤任何與連接池有關的性能問題時，.NET CLR數據性能計數器會很有用的。

       不論何時您的應用程序連接一個資源，例如一個數據庫，或者在另一個進程中運行，您都應該通過把注意力集中到連接到資源所花費的時間上，發送和接受數據花費的時間，還有往返與數據庫的次數來進行優化。優化您的應用程序中的任何類型的進程跳轉（process hop）都是開始達到更好性能的第一步。

       應用層包含連接到您的數據層的邏輯，并且把數據轉換為有意義的類實例和邏輯過程。例如，在社區服務器中，這里是您生成一個論壇或者線程集合，并且應用業務規則例如許可的地方；更重要的是這里是執行緩沖邏輯的地方。

技巧 4——ASP.NET緩沖API

           在您開始編寫應用程序的第一行代碼之前要考慮的第一件事情是，架構應用層來最大化并且利用ASP.NET的緩存特性。

       如果您的組件運行在一個ASP.NET應用程序之中，您只需要在您的應用程序項目中簡單的引用System.Web.dll就可以了。當您需要訪問緩存時，使用HttpRuntime.Cache屬性（這個對象也可以通過Page.Cache和HttpContext.Cache來訪問）。

     使用緩存數據有幾條原則。第一，如果數據可以多次使用，那么緩存它就是一個好的選擇。第二，如果數據是通用的而不是給特定的請求或者用戶使用的，那么緩存它就是一個非常好的選擇。如果數據是用戶或者請求特定的，但是他的生存期是很長的，那么它也可以被緩存，但是可能不會經常使用到。第三，一個經常被忽視的原則是，有時候您可以緩存的太多了。通常在一臺x86計算機上，為了減少發生內存不足（out-of-memory）錯誤的可能性，您會希望運行一個使用不超過800MB私有字節的進程。因此，緩存應該受到限制。換句話說，您可能需要重新使用一次計算的結果，但是如果那個計算需要十個參數，您可能需要嘗試緩存10個排列，而這可能會給您帶來麻煩。由于過度緩存引起的內存不足錯誤是ASP.NET中最常見的，特別是對于大數據集的情況。
   
      緩存有幾個極佳的功能，您需要對它們有所了解。首先，緩存會實現最近最少使用的算法，使得 ASP.NET 能夠在內存運行效率較低的情況下強制緩存清除——從緩存自動刪除未使用過的項目。第二，緩存支持可以強制失效的過期依賴項。這些依賴項包括時間、鍵和文件。時間經常會用到，但是對于 ASP.NET 2.0，引入了一個功能更強的新失效類型：數據庫緩存失效。它指的是當數據庫中的數據發生變化時自動刪除緩存中的項。有關數據庫緩存失效的詳細信息，請參閱 MSDN Magazine 2004 年 7 月的 Dino Esposito Cutting Edge 專欄。要了解緩存的體系結構，請參閱圖 3。


技巧 5 — 每請求緩存
 
       在本文前面部分，我提到了對經常遍歷代碼路徑的一些小改善可以獲得較大的整體性能收益。對于這些小改善，其中有一個絕對是我的最愛，我將其稱之為“每請求緩存”。

       緩存 API 的設計目的是為了將數據緩存較長的一段時間，或者緩存至滿足某些條件時，但每請求緩存則意味著只將數據緩存為該請求的持續時間。對于每個請求，要經常訪問某個特定的代碼路徑，但是數據卻只需提取、應用、修改或更新一次。這聽起來有些理論化，那么我們來舉一個具體的示例。

       在社區服務器的論壇應用程序中，頁面上使用的每個服務器控件都需要個性化的數據來確定使用什么外觀、使用什么樣式表，以及其他個性化數據。這些數據中有些可以長期緩存，但是有些數據卻只針對每個請求提取一次，然后在執行該請求期間對其重用多次，如要用于控件的外觀。

       為了達到每請求緩存，請使用 ASP.NET HttpContext。對于每個請求，都會創建一個 HttpContext 實例，在該請求期間從 HttpContext.Current 屬性的任何位置都可訪問該實例。該 HttpContext 類具有一個特殊的 Items 集合屬性；添加到此 Items 集合的對象和數據只在該請求持續期間內進行緩存。正如您可以使用緩存來存儲經常訪問的數據一樣，您也可以使用 HttpContext.Items 來存儲只基于每個請求使用的數據。它背后的邏輯非常簡單：數據在它不存在的時候添加到 HttpContext.Items 集合，在后來的查找中，只是返回 HttpContext.Items 中的數據。
 

技巧 6 — 后臺處理
 
       通往代碼的路徑應該盡可能快速，是嗎？可能有時您會發現您正在執行的針對每個請求執行的或者每 n 個請求執行一次的任務所需資源非常多。發送電子郵件或者分析和驗證傳入數據就是這樣的一些例子。

       剖析 ASP.NET Forums 1.0 并重新構建組成社區服務器的內容時，我們發現發布新帖子的代碼路徑非常慢。每次發布新帖子的時候，應用程序首先需要確保沒有重復的帖子，然后必須使用“壞詞”篩選器分析該帖子，分析帖子的字符圖釋，對帖子添加標記并進行索引，請求時將帖子添加到合適的隊列，驗證附件，最終在帖子發布之后，立即向所有訂閱者發出電子郵件通知。很清楚，這涉及很多操作。

       經研究發現，大多數時間都花在了索引邏輯和發送電子郵件上。對帖子進行索引是一個非常耗時的操作，人們發現內置的 System.Web.Mail 功能要連接 SMTP 服務器，然后連續發送電子郵件。當某個特定帖子或主題領域的訂閱者數量增加時，執行 AddPost 功能所需的時間也越來越長。

       并不需要針對每個請求都進行電子郵件索引。理想情況下，我們想要將此操作進行批處理，一次索引 25 個帖子或者每五分鐘發送一次所有電子郵件。我們決定使用我曾經用于對數據緩存失效進行原型設計的代碼，這個失效是最終被包含進了Visual Studio 2005之中。

       System.Threading 命名空間中的 Timer 類非常有用，但是在 .NET Framework 中不是很有名，至少對于 Web 開發人員來說是這樣。創建之后，這個 Timer 類將以一個可配置的間隔針對 ThreadPool 中的某個線程調用指定的回調。這就表示，您可以對代碼進行設置，使其能夠在沒有對 ASP.NET 應用程序進行傳入請求的情況下得以執行，這是后臺處理的理想情況。您還可以在此后臺進程中執行如索引或發送電子郵件之類的操作。

       但是，這一技術有幾個問題。如果應用程序域卸載，該計時器實例將停止激發事件。另外，因為 CLR 對于每個進程的線程數量具有一個硬性標準，所以在負載很重的服務器可能會出現這樣的情形：其中的計時器可能不能保證線程繼續完成操作，并且在某種程度上可能會造成延遲。ASP.NET 通過在進程中保留一定數量的可用線程，并且僅使用總線程的一部分用于請求處理，試圖將上述情況發生的機會降到最低。但是，如果您具有很多異步操作時，這可能就是一個問題了。

       這里沒有足夠的空間來放置該代碼，但是您可以下載一個容易理解的示例，網址是www.rob-howard.net。請了解一下 Blackbelt TechEd 2004 演示中的幻燈片和演示。

技巧 7 — 頁輸出緩存和代理服務器
 
       ASP.NET 是您的表示層（或者說應該是您的表示層）；它由頁、用戶控件、服務器控件（HttpHandlers 和 HttpModules）以及它們生成的內容組成。如果您具有一個 ASP.NET 頁，它會生成輸出（HTML、xml、圖像或任何其他數據），并且您針對每個請求運行此代碼時，它都會生成相同的輸出，那么您就擁有一個可用于頁輸出緩存的絕佳備選內容。

       通過將下面這行內容添加頁的最上端： 

<%@ Page OutputCache VaryByParams="none" Duration="60" %> 
 
       您就可以高效地為此頁生成一次輸出，然后對它進行多次重用，時間最長為 60 秒，此時該頁將重新執行，輸出也將再一次添加到 ASP.NET 緩存。通過使用一些低級別可編程API 也可以完成此行為。對于輸出緩存有幾個可配置的設置，如剛剛講到的 VaryByParams 屬性。VaryByParams 剛好被請求到，但還允許您指定 HTTP GET 或 HTTP POST 參數來更改緩存項。例如，只需設置 VaryByParam="Report" 即可對 default.aspx?Report=1 或 default.aspx?Report=2 進行輸出緩存。通過指定一個以分號分隔的列表，還可以指定其他參數。 

       很多人還沒有意識到當使用了輸出緩存之后，ASP.NET 頁也會生成一些向下流到緩存服務器的 HTTP 標題頭，如 Microsoft Internet Security 和 Acceleration Server 或 Akamai 使用的標題頭。設置了 HTTP 緩存表題頭之后，可以在這些網絡資源上對文檔進行緩存，客戶端請求也可在不必返回原始服務器的情況下得以滿足。

       因此，使用頁輸出緩存不會使得您的應用程序效率更高，但是它可能會減少服務器上的負載，因為下行流緩存技術會緩存文檔。當然，這只能是匿名內容；一旦它成為下行流之后，您就再也不會看到這些請求，并且再也無法執行身份驗證以阻止對它的訪問了。



技巧 8 — 運行 IIS 6.0（哪怕只為了使用內核緩存也好）
 
       如果您未運行 IIS 6.0 (windows Server 2003)，那么您就錯過了 Microsoft Web 服務器中的一些很好的性能增強。在技巧 7 中，我討論了輸出緩存。在 IIS 5.0 中，請求是通過 IIS 然后進入 ASP.NET 的。涉及到緩存時，ASP.NET 中的 HttpModule 會接收該請求，并返回緩存中的內容。

       如果您正在使用 IIS 6.0，就會發現一個很好的小功能，稱為內核緩存，它不需要對 ASP.NET 進行任何代碼更改。當請求由 ASP.NET 進行輸出緩存時，IIS 內核緩存會接收緩存數據的一個副本。當請求來自網絡驅動程序時，內核級別的驅動程序（無上下文切換到用戶模式）就會接收該請求，如果經過了緩存，則會將緩存的數據刷新到響應，然后完成執行。這就表示，當您將內核模式緩存與 IIS 和 ASP.NET 輸出緩存一起使用時，就會看到令人不敢相信的性能結果。在 ASP.NET 的 Visual Studio 2005 開發過程中，我一度是負責 ASP.NET 性能的開發經理。開發人員完成具體工作，但是我要看到每天進行的所有報告。內核模式緩存結果總是最有意思的。最常見的特征是網絡充滿了請求/響應，而 IIS 運行時的 CPU 使用率只有大約 5%。這太令人震驚了！當然使用 IIS 6.0 還有一些其他原因，但是內核模式緩存是其中最明顯的一個。
 


技巧 9 — 使用 Gzip 壓縮
 
       雖然使用 gzip 并不一定是服務器性能技巧（因為您可能會看到 CPU 使用率的提高），但是使用 gzip 壓縮可以減少服務器發送的字節數量。這就使人們覺得頁速度加快了，并且還減少了帶寬的用量。根據所發送數據、可以壓縮的程度以及客戶端瀏覽器是否支持（IIS 只會向支持 gzip 壓縮的客戶端發送經過 gzip 壓縮的內容，如 Internet Explorer 6.0 和 Firefox），您的服務器每秒可以服務于更多的請求。實際上，幾乎每當您減少所返回數據的數量時，都會增加每秒請求數。

       Gzip 壓縮已經內置到 IIS 6.0 中，并且其性能比 IIS 5.0 中使用的 gzip 壓縮要好的多，這是好消息。但不幸的是，當嘗試在 IIS 6.0 中打開 gzip 壓縮時，您可能無法在 IIS 的屬性對話中找到該設置。IIS 小組在該服務器中置入了卓越的 gzip 功能，但是忘了包括一個用于啟用該功能的管理 UI。要啟用 gzip 壓縮，您必須深入到 IIS 6.0 的 XML 配置設置內部（這樣不會引起心臟虛弱）。順便提一句，這歸功于 OrcsWeb 的 Scott Forsyth，他幫助我提出了在 OrcsWeb 上宿主的 www.asp.net 服務器的這個問題。

       本文就不講述步驟了，請閱讀 Brad Wilson 的文章，網址是 IIS6 Compression。還有一篇有關為 ASPX 啟用壓縮的知識庫文章，網址是 Enable ASPX Compression in IIS。但是您應該注意，由于一些實施細節，IIS 6.0 中不能同時存在動態壓縮和內核緩存。


技巧 10 — 服務器控件視圖狀態
 
       視圖狀態是一個有趣的名稱，用于表示在所生成頁的隱藏輸出字段中存儲一些狀態數據的 ASP.NET。當該頁發回服務器時，服務器可以分析、驗證、并將此視圖狀態數據應用回該頁的控件樹。視圖狀態是一個非常強大的功能，因為它允許狀態與客戶端一起保持，并且它不需要 cookie 或服務器內存即可保存此狀態。很多 ASP.NET 服務器控件都使用視圖狀態來保持在與頁元素進行交互期間創建的設置，例如保存對數據進行分頁時顯示的當前頁。

       然而使用視圖狀態也有一些缺點。首先，當頁被服務或被請求時，它都會增加頁的總負載。對發回服務器的視圖狀態數據進行序列化或取消序列化時，也會發生額外的開銷。最后，視圖狀態會增加服務器上的內存分配。

       幾個服務器控件有過度使用視圖狀態的趨勢，即使在并不需要的情況下也要使用它，其中最著名的是 DataGrid。ViewState 屬性的默認行為是啟用，但是如果您不需要，則可以在控件或頁級別關閉。在控件內，只需將 EnableViewState 屬性設置為 false，或者在頁中使用下列設置即可對其進行全局設置： 

<%@ Page EnableViewState="false" %>
 
       如果您不發回頁，或者總是針對每個請求重新生成頁上的控件，則應該在頁級別禁用視圖狀態。 

 
小結
 
       我為您講述了一些我認為在編寫高性能 ASP.NET 應用程序時有所幫助的技巧。正如我在本文前面部分提到的那樣，這是一個初步指南，并不是 ASP.NET 性能的最后定論。（有關改善 ASP.NET 應用程序性能的信息，請參閱 Improving ASP.NET Performance。）只有通過自己的親身體驗才能找出解決具體性能問題的最好方法。但是，在您的旅程中，這些技巧應該會為您提供一些好的指南。在軟件開發中，幾乎沒有絕對的東西；每個應用程序都是唯一的。