26種提升ASP.NET網站訪問性能的優化方法

1. 數據庫訪問性能優化

數據庫的鏈接和關閉

　　訪問數據庫資源須要建立鏈接、打開鏈接和關閉鏈接幾個操做。這些過程須要屢次與數據庫交換信息以經過身份驗證，比較耗費服務器資源。 ASP.NET中提供了鏈接池（Connection Pool）改善打開和關閉數據庫對性能的影響。系統將用戶的數據庫鏈接放在鏈接池中，須要時取出，關閉時收回鏈接，等待下一次的鏈接請求。

　　鏈接池的大小是有限的，若是在鏈接池達到最大限度後仍要求建立鏈接，必然大大影響性能。所以，在創建數據庫鏈接後只有在真正須要操做時纔打開鏈接，使用完畢後立刻關閉，從而儘可能減小數據庫鏈接打開的時間，避免出現超出鏈接限制的狀況。

使用存儲過程

　　存儲過程是存儲在服務器上的一組預編譯的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方法返回操做結果。

其定義及操做語句以下所示：

int num;

System.Text.StringBuilder str = new System.Text.StringBuilder(); //建立字符串

str.Append(num.ToString()); //添加數值num

Response.Write(str.ToString); //顯示操做結果

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

　　默認狀況下，ASP.NET 配置被設置成啓用最普遍的功能並儘可能適應最多見的方案。所以，應用程序開發人員能夠根據應用程序所使用的功能，優化和更改其中的某些配置，以提升應用程序的性能。下面的列表是您應該考慮的一些選項。

　　僅對須要的應用程序啓用身份驗證。默認狀況下，身份驗證模式爲 Windows，或集成 NTLM。大多數狀況下，對於須要身份驗證的應用程序，最好在 Machine.config 文件中禁用身份驗證，並在 Web.config 文件中啓用身份驗證。

　　根據適當的請求和響應編碼設置來配置應用程序。ASP.NET 默認編碼格式爲 UTF-8。若是您的應用程序爲嚴格的 ASCII，請配置應用程序使用 ASCII 以得到稍許的性能提升。

　　考慮對應用程序禁用 AutoEventWireup。在 Machine.config 文件中將 AutoEventWireup 屬性設置爲 false，意味着頁面不將方法名與事件進行匹配和將二者掛鉤（例如 Page_Load）。若是頁面開發人員要使用這些事件，須要在基類中重寫這些方法（例如，須要爲頁面加載事件重寫 Page.OnLoad，而不是使用 Page_Load 方法）。若是禁用 AutoEventWireup，頁面將經過將事件鏈接留給頁面做者而不是自動執行它，得到稍許的性能提高。

　　從請求處理管線中移除不用的模塊。默認狀況下，服務器計算機的 Machine.config 文件中 <httpModules> 節點的全部功能均保留爲激活。根據應用程序所使用的功能，您能夠從請求管線中移除不用的模塊以得到稍許的性能提高。檢查每一個模塊及其功能，並按您的須要自 定義它。

　　例如，若是您在應用程序中不使用會話狀態和輸出緩存，則能夠從 <httpModules> 列表中移除它們，以便請求在不執行其餘有意義的處理時，沒必要執行每一個模塊的進入和離開代碼。

4. 必定要禁用調試模式

　　在部署生產應用程序或進行任何性能測量以前，始終記住禁用調試模式。若是啓用了調試模式，應用程序的性能可能受到很是大的影響。

5. 對於普遍依賴外部資源的應用程序，請考慮在多處理器計算機上啓用網絡園藝

　　ASP.NET 進程模型幫助啓用多處理器計算機上的可縮放性，將工做分發給多個進程（每一個 CPU 一個），而且每一個進程都將處理器關係設置爲其 CPU。此技術稱爲網絡園藝。若是應用程序使用較慢的數據庫服務器或調用具備外部依賴項的 COM 對象（這裏只是說起兩種可能性），則爲您的應用程序啓用網絡園藝是有益的。可是，在決定啓用網絡園藝以前，您應該測試應用程序在網絡園中的執行狀況。

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

　　ASP.NET 提供了一些簡單的機制，它們會在不須要爲每一個頁請求動態計算頁輸出或數據時緩存這些頁輸出或數據。另外，經過設計要進行緩存的頁和數據請求（特別是在站點 中預期將有較大通信量的區域），能夠優化這些頁的性能。與 .NET Framework 的任何 Web 窗體功能相比，適當地使用緩存能夠更好的提升站點的性能，有時這種提升是超數量級的。

　　使用 ASP.NET 緩存機制有兩點須要注意。首先，不要緩存太多項。緩存每一個項均有開銷，特別是在內存使用方面。不要緩存容易從新計算和不多使用的項。其次，給緩存的項分配 的有效期不要過短。很快到期的項會致使緩存中沒必要要的週轉，而且常常致使更多的代碼清除和垃圾回收工做。若關心此問題，請監視與 ASP.NET Applications 性能對象關聯的 Cache Total Turnover Rate 性能計數器。高週轉率可能說明存在問題，特別是當項在到期前被移除時。這也稱做內存壓力。

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

　　根據您選擇在 Web 窗體頁顯示數據的方式，在便利和性能之間經常存在着重要的權衡。例如，DataGrid Web 服務器控件多是一種顯示數據的方便快捷的方法，但就性能而言它的開銷經常是最大的。在某些簡單的狀況下，您經過生成適當的 HTML 本身呈現數據可能頗有效，可是自定義和瀏覽器定向會很快抵銷所得到的額外功效。Repeater Web 服務器控件是便利和性能的折衷。它高效、可自定義且可編程。

8. 將 SqlDataReader 類用於快速只進數據遊標

　　SqlDataReader 類提供了一種讀取從 SQL Server 數據庫檢索的只進數據流的方法。若是當建立 ASP.NET 應用程序時出現容許您使用它的狀況，則 SqlDataReader 類提供比 DataSet 類更高的性能。狀況之因此這樣，是由於 SqlDataReader 使用 SQL Server 的本機網絡數據傳輸格式從數據庫鏈接直接讀取數據。另外，SqlDataReader 類實現 IEnumerable 接口，該接口也容許您將數據綁定到服務器控件。有關更多信息，請參見 SqlDataReader 類。有關 ASP.NET 如何訪問數據的信息，請參見經過 ASP.NET 訪問數據。

9. 將 SQL Server 存儲過程用於數據訪問

　　在 .NET Framework 提供的全部數據訪問方法中，基於 SQL Server 的數據訪問是生成高性能、可縮放 Web 應用程序的推薦選擇。使用託管 SQL Server 提供程序時，可經過使用編譯的存儲過程而不是特殊查詢得到額外的性能提升。

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

　　默認狀況下，ASP.NET 不容許任何 STA COM 組件在頁面內運行。若要運行它們，必須在 .aspx 文件內將 ASPCompat=true 屬性包含在 @ Page 指令中。這樣就將執行用的線程池切換到 STA 線程池，並且使 HttpContext 和其餘內置對象可用於 COM 對象。前者也是一種性能優化，由於它避免了將多線程單元 (MTA) 封送到 STA 線程的任何調用。

　　使用 STA COM 組件可能大大損害性能，應儘可能避免。若必須使用 STA COM 組件，如在任何 interop 方案中，則應在執行期間進行大量調用並在每次調用期間發送儘量多的信息。另外，當心不要在構造頁面期間建立任何 STA COM 組件。例以下面的代碼中，在頁面構造時將實例化由某個線程建立的 MySTAComponent，而該線程並非將運行頁面的 STA 線程。這可能對性能有不利影響，由於要構造頁面就必須完成 MTA 和 STA 線程之間的封送處理。

<%@ Page Language="VB" ASPCompat="true" %> 
<script runat=server> 
Dim myComp as new MySTAComponent() 
Public Sub Page_Load() 
myComp.Name = "Bob" 
End Sub 
</script> 
<html> 
<% 
Response.Write(myComp.SayHello) 
%> 
</html>

首選機制是推遲對象的建立，直到之後在 STA 線程下執行上述代碼，以下面的例子所示。

<%@ Page Language="VB" ASPCompat="true" %> 
<script runat=server> 
Dim myComp 
Public Sub Page_Load() 
myComp = new MySTAComponent() 
myComp.Name = "Bob" 
End Sub 
</script> 
<html> 
<% 
Response.Write(myComp.SayHello) 
%> 
</html>

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

　　永遠不要將任何 STA COM 組件存儲在能夠由構造它的線程之外的其餘線程訪問的共享資源裏。這類資源包括像緩存和會話狀態這樣的資源。即便 STA 線程調用 STA COM 組件，也只有構造此 STA COM 組件的線程可以實際爲該調用服務，而這要求封送處理對建立者線程的調用。此封送處理可能產生重大的性能損失和可伸縮性問題。在這種狀況下，請研究一下使 COM 組件成爲 MTA COM 組件的可能性，或者更好的辦法是遷移代碼以使對象成爲託管對象。

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

　　.NET Framework 提供了一個簡單的方法與傳統的 COM 組件進行交互。其優勢是能夠在保留現有投資的同時利用新的平臺。可是在某些狀況下，保留舊組件的性能開銷使得將組件遷移到託管代碼是值得的。每一狀況都是 不同的，決定是否須要遷移組件的最好方法是對 Web 站點運行性能測量。建議您研究一下如何將須要大量調用以進行交互的任何 COM 組件遷移到託管代碼。

　　許多狀況下不可能將舊式組件遷移到託管代碼，特別是在最初遷移 Web 應用程序時。在這種狀況下，最大的性能障礙之一是將數據從非託管環境封送到託管環境。所以，在交互操做中，請在任何一端執行儘量多的任務，而後進行一個 大調用而不是一系列小調用。例如，公共語言運行庫中的全部字符串都是 Unicode 的，因此應在調用託管代碼以前將組件中的全部字符串轉換成 Unicode 格式。

　　另外，一處理完任何 COM 對象或本機資源就釋放它們。這樣，其餘請求就可以使用它們，而且最大限度地減小了因稍後請求垃圾回收器釋放它們所引發的性能問題。

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

　　以往，開發人員喜歡使用 Visual Basic、VBScript 和 JScript 的緣由之一就是它們所謂「無類型」的性質。變量不須要顯式類型聲明，並可以簡單地經過使用來建立它們。當從一個類型到另外一個類型進行分配時，轉換將自動執 行。不過，這種便利會大大損害應用程序的性能。

　　Visual Basic 如今經過使用 Option Strict 編譯器指令來支持類型安全編程。爲了向後兼容，默認狀況下，ASP.NET 不啓用該選項。可是，爲了獲得最佳性能，強烈建議在頁中啓用該選項。若要啓用 Option Strict，請將 Strict 屬性包括在 @ Page 指令中，或者，對於用戶控件，請將該屬性包括在 @ Control 指令中。下面的示例演示瞭如何設置該屬性，並進行了四個變量調用以顯示使用該屬性是如何致使編譯器錯誤的。

<%@ Page Language="VB" Strict="true" %> 
<% 
Dim B 
Dim C As String 
' This will cause a compiler error. 
A = "Hello" 
' This will cause a compiler error. 
B = "World" 
' This will not cause a compiler error. 
C = "!!!!!!" 
' But this will cause a compiler error. 
C = 0 
%>

　　JScript .NET 也支持無類型編程，但它不提供強制早期綁定的編譯器指令。若發生下面任何一種狀況，則變量是晚期綁定的：

　　被顯式聲明爲 Object。

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

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

　　最後一個差異比較複雜，由於若是 JScript .NET 編譯器能夠根據變量的使用狀況推斷出類型，它就會進行優化。在下面的示例中，變量 A 是早期綁定的，但變量 B 是晚期綁定的。

var A;

var B;

A = "Hello";

B = "World";

B = 0;

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

13.   使請求管線內的全部模塊儘量高效

　　請求管線內的全部模塊在每次請求中都有機會被運行。所以，當請求進入和離開模塊時快速地觸發代碼相當重要，特別是在不使用模塊功能的代碼路徑裏。分別在使用及不使用模塊和配置文件時執行吞吐量測試，對肯定這些方法的執行速度很是有用。

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

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

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

　　ASP.NET 的請求結構試圖在執行請求的線程數和可用資源之間達到一種平衡。已知一個使用足夠 CPU 功率的應用程序，該結構將根據可用於請求的 CPU 功率，來決定容許同時執行的請求數。這項技術稱做線程門控。可是在某些條件下，線程門控算法不是頗有效。經過使用與 ASP.NET Applications 性能對象關聯的 Pipeline Instance Count 性能計數器，能夠在 PerfMon 中監視線程門控。

　　當頁面調用外部資源，如數據庫訪問或 XML Web services 請求時，頁面請求一般中止並釋放 CPU。若是某個請求正在等待被處理，而且線程池中有一個線程是自由的，那麼這個正在等待的請求將開始被處理。遺憾的是，有時這可能致使 Web 服務器上存在大量同時處理的請求和許多正在等待的線程，而它們對服務器性能有不利影響。一般，若是門控因子是外部資源的響應時間，則讓過多請求等待資源， 對 Web 服務器的吞吐量並沒有幫助。

　　爲緩和這種狀況，能夠經過更改 Machine.config 配置文件 <processModel> 節點的 maxWorkerThreads 和 maxIOThreads 屬性，手動設置進程中的線程數限制。

　　注意 輔助線程是用來處理 ASP.NET 請求的，而 IO 線程則是用於爲來自文件、數據庫或 XML Web services 的數據提供服務的。

　分配給這些屬性的值是進程中每一個 CPU 每類線程的最大數目。對於雙處理器計算機，最大數是設置值的兩倍。對於四處理器計算機，最大值是設置值的四倍。不管如何，對於有四個或八個 CPU 的計算機，最好更改默認值。對於有一個或兩個處理器的計算機，默認值就能夠，但對於有更多處理器的計算機的性能，進程中有一百或兩百個線程則弊大於利。

　　注意 進程中有太多線程每每會下降服務器的速度，由於額外的上下文交換致使操做系統將 CPU 週期花在維護線程而不是處理請求上。

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

　　當心不要給每一個請求分配過多內存，由於這樣垃圾回收器將必須更頻繁地進行更多的工做。另外，不要讓沒必要要的指針指向對象，由於它們將使對象保持 活動狀態，而且應儘可能避免含 Finalize 方法的對象，由於它們在後面會致使更多的工做。特別是在 Finalize 調用中永遠不要釋放資源，由於資源在被垃圾回收器回收以前可能一直消耗着內存。最後這個問題常常會對 Web 服務器環境的性能形成毀滅性的打擊，由於在等待 Finalize 運行時，很容易耗盡某個特定的資源。

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

　　每當發生對目錄的第一次請求時都會執行批編譯。若是目錄中的頁面沒有被分析並編譯，此功能會成批分析並編譯目錄中的全部頁面，以便更好地利用磁 盤和內存。若是這須要很長時間，則將快速分析並編譯單個頁面，以便請求能被處理。此功能帶給 ASP.NET 性能上的好處，由於它將許多頁面編譯爲單個程序集。從已加載的程序集訪問一頁比每頁加載新的程序集要快。

　　批編譯的缺點在於：若是服務器接收到許多對還沒有編譯的頁面的請求，那麼當 Web 服務器分析並編譯它們時，性能可能較差。爲解決這個問題，能夠執行預批編譯。爲此，只需在應用程序激活以前向它請求一個頁面，不管哪頁都可。而後，當用戶 首次訪問您的站點時，頁面及其程序集將已被編譯。

　　沒有簡單的機制能夠知道批編譯什麼時候發生。需一直等到 CPU 空閒或者沒有更多的編譯器進程（例如 csc.exe（C# 編譯器）或 vbc.exe（Visual Basic 編譯器））啓動。

　　還應儘可能避免更改應用程序的 /bin 目錄中的程序集。更改頁面會致使從新分析和編譯該頁，而替換 /bin 目錄中的程序集則會致使徹底從新批編譯該目錄。

　　在包含許多頁面的大規模站點上，更好的辦法多是根據計劃替換頁面或程序集的頻繁程度來設計不一樣的目錄結構。不常更改的頁面能夠存儲在同一目錄中並在特定的時間進行預批編譯。常常更改的頁面應在它們本身的目錄中（每一個目錄最多幾百頁）以便快速編譯。

　　Web 應用程序能夠包含許多子目錄。批編譯發生在目錄級，而不是應用程序級。

18.   不要依賴代碼中的異常

　　由於異常大大地下降性能，因此您不該該將它們用做控制正常程序流程的方式。若是有可能檢測到代碼中可能致使異常的狀態，請執行這種操做。不要在 處理該狀態以前捕獲異常自己。常見的方案包括：檢查 null，分配給將分析爲數字值的 String 一個值，或在應用數學運算前檢查特定值。下面的示例演示可能致使異常的代碼以及測試是否存在某種狀態的代碼。二者產生相同的結果。

try

{

       result = 100 / num;

}

catch (Exception e)

{

       result = 0;

}

// ...to this.

if (num != 0)

       result = 100 / num;

else

       result = 0;

19.   使用 HttpResponse.Write 方法進行字符串串聯

　　該方法提供很是有效的緩衝和鏈接服務。可是，若是您正在執行普遍的鏈接，請使用多個 Response.Write 調用。下面示例中顯示的技術比用對 Response.Write 方法的單個調用鏈接字符串更快。

Response.Write("a"); 
Response.Write(myString); 
Response.Write("b"); 
Response.Write(myObj.ToString()); 
Response.Write("c"); 
Response.Write(myString2); 
Response.Write("d");

20.   除非有特殊的緣由要關閉緩衝，不然使其保持打開

禁用 Web 窗體頁的緩衝會致使大量的性能開銷。

21.   只在必要時保存服務器控件視圖狀態

　　自動視圖狀態管理是服務器控件的功能，該功能使服務器控件能夠在往返過程上從新填充它們的屬性值（您不須要編寫任何代碼）。可是，由於服務器控 件的視圖狀態在隱藏的窗體字段中往返於服務器，因此該功能確實會對性能產生影響。您應該知道在哪些狀況下視圖狀態會有所幫助，在哪些狀況下它影響頁的性 能。例如，若是您將服務器控件綁定到每一個往返過程上的數據，則將用從數據綁定操做得到的新值替換保存的視圖狀態。在這種狀況下，禁用視圖狀態能夠節省處理 時間。

　　默認狀況下，爲全部服務器控件啓用視圖狀態。若要禁用視圖狀態，請將控件的EnableViewState 屬性設置爲 false，以下面的 DataGrid 服務器控件示例所示。

<asp:datagrid EnableViewState="false" datasource="..." runat="server"/>

　　您還能夠使用 @ Page 指令禁用整個頁的視圖狀態。當您不從頁回發到服務器時，這將十分有用：

<%@ Page EnableViewState="false" %>

　　注意 @ Control 指令中也支持 EnableViewState 屬性，該指令容許您控制是否爲用戶控件啓用視圖狀態。

　　若要分析頁上服務器控件使用的視圖狀態的數量，請（經過將 trace="true" 屬性包括在 @ Page 指令中）啓用該頁的跟蹤並查看 Control Hierarchy 表的 Viewstate 列。有關跟蹤和如何啓用它的信息，請參見 ASP.NET 跟蹤。

22.   避免到服務器的沒必要要的往返過程

　　雖然您極可能但願儘可能多地使用 Web 窗體頁框架的那些節省時間和代碼的功能，但在某些狀況下卻不宜使用 ASP.NET 服務器控件和回發事件處理。

　　一般，只有在檢索或存儲數據時，您才須要啓動到服務器的往返過程。多數數據操做可在這些往返過程間的客戶端上進行。例如，從 HTML 窗體驗證用戶輸入常常可在數據提交到服務器以前在客戶端進行。一般，若是不須要將信息傳遞到服務器以將其存儲在數據庫中，那麼您不該該編寫致使往返過程的 代碼。

　　若是您開發自定義服務器控件，請考慮讓它們爲支持 ECMAScript 的瀏覽器呈現客戶端代碼。經過以這種方式使用服務器控件，您能夠顯著地減小信息被沒必要要的發送到 Web 服務器的次數。

　　使用 Page.IsPostBack 避免對往返過程執行沒必要要的處理

　　若是您編寫處理服務器控件回發處理的代碼，有時可能須要在首次請求頁時執行其餘代碼，而不是當用戶發送包含在該頁中的 HTML 窗體時執行的代碼。根據該頁是不是響應服務器控件事件生成的，使用 Page.IsPostBack 屬性有條件地執行代碼。例如，下面的代碼演示如何建立數據庫鏈接和命令，該命令在首次請求該頁時將數據綁定到 DataGrid 服務器控件。

void Page_Load(Object sender, EventArgs e)

{

       // Set up a connection and command here.

       if (!Page.IsPostBack)

       {

              String query = "select * from Authors where FirstName like '%JUSTIN%'";

              myCommand.Fill(ds, "Authors");

              myDataGrid.DataBind();

       }

}

　　因爲每次請求時都執行 Page_Load 事件，上述代碼檢查 IsPostBack 屬性是否設置爲 false。若是是，則執行代碼。若是該屬性設置爲 true，則不執行代碼。

　　注意 若是不運行這種檢查，回發頁的行爲將不更改。Page_Load 事件的代碼在執行服務器控件事件以前執行，但只有服務器控件事件的結果纔可能在輸出頁上呈現。若是不運行該檢查，仍將爲 Page_Load 事件和該頁上的任何服務器控件事件執行處理。

23.   當不使用會話狀態時禁用它

　　並非全部的應用程序或頁都須要針對於具體用戶的會話狀態，您應該對任何不須要會話狀態的應用程序或頁禁用會話狀態。

　　若要禁用頁的會話狀態，請將 @ Page 指令中的 EnableSessionState 屬性設置爲 false。例如，<%@ Page EnableSessionState="false" %>。

　　注意 若是頁須要訪問會話變量，但不打算建立或修改它們，則將 @ Page 指令中的 EnableSessionState 屬性設置爲 ReadOnly。

　　還能夠禁用 XML Web services 方法的會話狀態。有關更多信息，請參見使用 ASP.NET 和 XML Web services 客戶端建立的 XML Web services。

　　若要禁用應用程序的會話狀態，請在應用程序 Web.config 文件的 sessionstate 配置節中將 mode 屬性設置爲 off。例如，<sessionstate mode="off" />。

24.   仔細選擇會話狀態提供程序

　　ASP.NET 爲存儲應用程序的會話數據提供了三種不一樣的方法：進程內會話狀態、做爲 Windows 服務的進程外會話狀態和 SQL Server 數據庫中的進程外會話狀態。每種方法都有本身的優勢，但進程內會話狀態是迄今爲止速度最快的解決方案。若是隻在會話狀態中存儲少許易失數據，則建議您使用 進程內提供程序。進程外解決方案主要用於跨多個處理器或多個計算機縮放應用程序，或者用於服務器或進程從新啓動時不能丟失數據的狀況。有關更多信息，請參 見 ASP.NET 狀態管理。

25.   不使用沒必要要的Server Control

　　ASP.net中，大量的服務器端控件方便了程序開發，但也可能帶來性能的損失，由於用戶每操做一次服務器端控件，就產生一次與服務器端的往返過程。所以，非必要，應當少使用Server Control。

26.   ASP.NET應用程序性能測試

　　在對ASP.NET應用程序進行性能測試以前，應確保應用程序沒有錯誤，並且功能正確。具體的性能測試能夠採用如下工具進行：Web Application Strees Tool (WAS)是Microsoft發佈的一個免費測試工具，能夠從http://webtool.rte.microsoft.com/上下載。它能夠模擬成百上千個用戶同時對web應用程序進行訪問請求，在服務器上造成流量負載，從而達到測試的目的，能夠生成平均TTFB、平均TTLB等性能彙總報告。

　　Application Center Test (ACT) 是一個測試工具，附帶於Visual Studio.NET的企業版中，是Microsoft正式支持的web應用程序測試工具。它可以直觀地生成圖表結果，功能比WAS多，但不具有多個客戶 機同時測試的能力。

　　如今寫一個asp.net的web應用程序變得很是的簡單,許多的程序員都不肯花時間去構建一個性能良好的應用程序。本文將要討論提升web應 用程序性能的十大方法。我將不限於只討論asp.net應用程序的內容，由於它們只是web應用程序的一個子集。本文也不能提供一個完整提升web應用程 序性能的指南，由於這須要一本書的篇幅。本文只提供一個提升web應用程序性能的良好的開端。（剩下的只有咱們本身慢慢研究了）。

　　在工做這外，我常常去攀巖，在每次攀巖以前，我都會重溫一下攀巖線路圖及看一下前面的成功的攀巖者的建議。由於咱們須要它們的成功經驗。一樣的，當你須要修改某個有性能問題的程序或者是要開發一個高性能的站點時，你也須要學習怎麼樣寫一個高性能的web應用程序。

　　我我的的經驗主要來源於在微軟的ASP.NET組擔任程序經理，運行和管理www.asp.net網站，和協助開發Community Server（它是ASP.NET Forums，.Text, 和 nGallery的集成升級版本軟件）。我想這些經驗能我讓來幫助你們。

　　你也許會想到把你的應用程序劃分紅不一樣的邏輯層。你也可能聽過三層物理架構或N層架構，這是最經常使用的架構模式，它把不一樣的程序功能物理的分配給 各個硬件來執行。這樣，若是咱們想提升應用程序的性能的話，加一些硬件就能夠達到目的了。按理說這種方法能提升應用程序的性能,可是咱們應該避免使用這種 方法。因此，只要有可能，咱們都應該把ASP.NET頁面和它用到的組件放到一個應用程序中運行。

　　由於分佈式的佈署，要用到Web Services或者Remoting，它將使應用程序的性能降低20%或者更多。

　　對於數據層有點不一樣，最好仍是把它獨立出來佈署，用一個單獨的硬件來運行它。雖然這樣，可是數據庫仍然是應用程序性能的瓶頸。所以，當你想優化你的程序的時候，首先想到的地方就應該是優化數據層了。

　　在修改應用程序的出現性能問題的地方以前，你要先確認出問題的地方的程序看起來很嚴密，性能分析器對於查找應用程序哪些地方花費了多長時間很是有用。這些地方是咱們用直覺感受不到的。

　　本文討論兩種類型的性能優化：一種是大的性能優化(big optimizations)，如用ASP.NET的Cache；另外一種是小的性能優化（tiny optimizations）。小幅的性能優化有時候很是有用。你只對你的代碼做一個小的改到，而後一次調用它一千或一萬次。做一次大的性能優化，你會發 生你的應用程序的速度會有一個很大的提高。做一次小的性能優化，也許每次請求只能提升一微秒，可是若是天天的請求量很大的話，那麼應用程序就有很顯著的性能提高。

　　數據層的性能

　　當你要優化一個應用程序的性能的時候，你能夠按下面的順序工做：你的代碼要訪問數據庫？若是要，訪問數據庫頻率怎麼樣？一樣，這種測試方法也可 以用在用Web Service或.NET Remoting的程序代碼中。本文將不討論用Web Services和Remoting的程序優化的問題。

　　若是在你的代碼中有一段必須訪問數據庫的請求，而你在其它的地方又看到實現一樣的功能 的代碼，那麼你首先要優化它。修改和完善繼續測試，除非你有一個很是大的性能問題，你的時間最好花在優化查詢，鏈接數據庫，返回數據集的大小，以及一次查詢往返回的時間上。

　　根據經驗的總結，讓咱們來看看十個能幫助你提高你的應用程序性能的經驗，我將按將它們提高效率的多少從大到小小依次說明。

　　1、返回多個數據集

　　檢查你的訪問數據庫的代碼，看是否存在着要返回屢次的請求。每次往返下降了你的應用程序的每秒可以響應請求的次數。經過在單個數據庫請求中返回多個結果集，能夠減小與數據庫通訊的時間，使你的系統具備擴展性，也能夠減小數據庫服務器響應請求的工做量。

　　若是你是用動態的SQL語句來返回多個數據集，那我建議你用存儲過程來替代動態的SQL語句。是否把業務邏輯寫到存儲過程當中，這個有點爭議。但 是我認爲，把業務邏輯寫到存儲過程裏面能夠限制返回結果集的大小，減少網絡數據的流量，在邏輯層也不用在過濾數據，這是一個好事情。

　　用SqlCommand對象的ExecuteReader方法返回一個強類型的業務對象，再調用NextResult方法來移動數據集指針來定 位數據集。示例一演示了一個返回多個ArrayList強類型對象的例子。只從數據庫中返回你須要的數據能夠大大的減少你的服務器所耗用的內存。

　　2、對數據進行分頁

　　ASP.NET的DataGrid有一個很是有用的功能：分頁。若是DataGrid容許分頁，在某一時刻它只下載某一頁的數據，另外，它有一個數據分頁的瀏覽導航欄，它讓你能夠選擇瀏覽某一頁，並且每次只下載一頁的數據。

　　可是它有一個小小的缺點，就是你必須把全部的數據都綁定到DataGrid中。也就是說，你的數據層必須返回全部的數據，而後DataGrid 再根據當前頁過濾出當前頁所須要的數據顯示出來。若是有一個一萬條記錄的結果集要用DataGrid進行分頁，假設DataGrid每頁只顯示25條數 據，那就意味着每次請求都有9975條數據都是要丟棄的。每次請求都要返回這麼大的數據集，對應用程序的性能影響是很是大的。

　　一個好的解決方案是寫一個分頁的存儲過程，例子2是一個用於對Northwind數據庫orders表的分頁存儲過程。你只須要傳當前頁碼，每頁顯示的條數兩個參數進來，存儲過程會返回相應的結果。

　　在服務器端，我專門寫了一個分頁的控件來處理數據的分頁，在這裏，我用了第一個方法，在一個存儲過程裏面返回了兩個結果集：數據記錄總數和要求的結果集。

　　返回的記錄總數取決於要執行查詢，例如，一個where條件能夠限制返回的結果集的大小。由於在分頁界面中必需要根據數據集記錄的大小來計算總 的頁數，因此必需要返回結果集的記錄數。例如，若是一共有1000000條記錄，若是用where條件就能夠過濾成只返回1000條記錄，存儲過程的分頁 邏輯應該知道返回那些須要顯示的數據。

　　3、鏈接池

　　用TCP來鏈接你的應用程序與數據庫是一件昂貴的事情（很費時的事情），微軟的開發者能夠經過用鏈接池來反覆的使用數據庫的鏈接。比起每次請求 都用TCP來連一次數據庫，鏈接池只有在不存在有效的鏈接時才新建一個TCP鏈接。當關閉一個鏈接的時候，它會被放到池中，它仍然會保持與數據庫的鏈接， 這樣就能夠減小與數據庫的TCP鏈接次數。

　　固然，你要注意那些忘記關的鏈接，你應在每次用完鏈接後立刻關閉它。我要強調的是：不管什麼人說.NET Framework中的GC(垃圾收集器)總會在你用完鏈接對象後調用鏈接對象的Close或者Dispose方法顯式的關閉你的鏈接。不要指望CLR會 在你想象的時間內關掉鏈接，雖然CLR最終都要銷燬對象和關閉邊接，可是咱們並不能肯定它到底會在何時作這些事情。

　　要用鏈接池優化，有兩條規則，第一，打開鏈接，處理數據，而後關閉鏈接。若是你必須在每次請求中屢次打開或關閉鏈接，這好過一直打開一個邊接， 而後把它傳到各個方法中。第二，用相同的鏈接字符串（或者用相同的用戶標識，當你用集成認證的時候）。若是你沒有用相同的鏈接字符串，如你用基於登陸用戶 的鏈接字符串，這將不能利用鏈接池的優化功能。若是你用的是集成的論證，由於用戶不少，因此你也不能充分利用鏈接池的優化功能。.NET CLR提供了一個數據性能計數器，它在咱們須要跟蹤程序性能特性的時候很是有用，固然也包括鏈接池的跟蹤了。

　　不管你的應用程序何時要連在另外一臺機子的資源，如數據庫，你都應該重點優化你連資源所花的時間，接收和發送數據的時間，以及往返回之間的次數。優化你的應用程序中的每個處理點（process hop），它是提升你的應用的性能的出發點。

　　應用程序層包含與數據層鏈接，傳送數據到相應的類的實例以及業務處理的邏輯。例如，在Community Server中，要組裝一個Forums或者Threads集合，而後應用業務邏輯，如受權，更重要的，這裏要完成緩存邏輯。

　　4、 ASP.NET緩存API

　　在寫應用程序以前,你要作的第一件事是讓應用程序最大化的利用ASP.NET的緩存功能。

　　若是你的組件是要在Asp.net應用程序中運行，你只要把System.Web.dll引用到你的項目中就能夠了。而後用HttpRuntime.Cache屬性就可訪問Cache了（也能夠經過Page.Cache或HttpContext.Cache訪問）。

　　有如下幾條緩存數據的規則。第一，數據可能會被頻繁的被使用，這種數據能夠緩存。第二，數據的訪問頻率很是高，或者一個數據的訪問頻率不高，但 是它的生存週期很長，這樣的數據最好也緩存起來。第三是一個經常被忽略的問題，有時候咱們緩存了太多數據，一般在一臺X86的機子上，若是你要緩存的數據 超過800M的話，就會出現內存溢出的錯誤。因此說緩存是有限的。換名話說，你應該估計緩存集的大小，把緩存集的大小限制在10之內，不然它可能會出問 題。在Asp.net中，若是緩存過大的話也會報內存溢出錯誤，特別是若是緩存大的DataSet對象的時候。

　　這裏有幾個你必須瞭解的重要的緩存機制。首先是緩存實現了「最近使用」原則（ a least-recently-used algorithm），當緩存少的時候，它會自動的強制清除那些無用的緩存。其次 「條件依賴」強制清除原則（expiration dependencies），條件能夠是時間，關鍵字和文件。以時間做爲條件是最經常使用的。在asp.net2.0中增長一更強的條件，就是數據庫條件。當 數據庫中的數據發生變化時，就會強制清除緩存。要更深刻的瞭解數據庫條件依賴請看Dino Esposito 在MSDN雜誌2004年七月刊的Cutting Edge專欄文章。

　　5、 預請求緩存

　　在前面，我提到過即便咱們只對某些地方做了一個小小的性能改進也能夠得到大的性能提高，我很是喜歡用預請求緩存來提高程序的性能。

　　雖然Cache API設計成用來保存某段時間的數據，而預請求緩存只是保存某個時期的某個請求的內容。若是某個請求的訪問頻率高，並且這個請求只須要提取，應用，修改或者更新數據一次。那麼就能夠預緩存該請求。咱們舉個例子來講明。

　　在CS的論壇應用程序中，每個頁面的服務器控件都要求獲得用於決定它的皮膚（skin）的自定義的數據，以決定用哪一個樣式表及其它的一些個性 化的東西。這裏面的某些數據可能要長時間的保存，有些時間則否則，如控件的skin數據，它只須要應用一次，然後就能夠一直使用。

　　要實現預請求緩存，用Asp.net 的HttpContext類，HttpContext類的實例在每個請求中建立，在請求期間的任何地方均可以經過 HttpContext.Current屬性訪問。HttpContext類有一個Items集合屬性，在請求期間全部的對象和數據都被添加到這個集合中 緩存起來。和你用Cache緩存訪問頻率高數據同樣，你能夠用HttpContext.Items緩存那些每一個請求都要用到的基礎數據。它背後的邏輯很簡 單：咱們向HttpContext.Items中添加一個數據，而後再從它裏面讀出數據。

　　6、 後臺處理

　　經過上面的方法你的應用程序應該運行得很快了，是否是？可是在某些時候，程序中的一次請求中可能要執行一個很是耗時的任務。如發送郵件或者是檢查提交的數據的正確性等。

　　當咱們把asp.net Forums 1.0集成在CS中的時侯，發現提交一個新的帖子的時候會很是的慢。每次新增一個帖子的時侯，應用程序首先要檢查這個帖子是否是重複提的，而後用 「badword」過濾器來過濾，檢查圖片附加碼，做帖子的索引，把它添加到合適的隊列中，驗證它的附件，最後，發郵件到它的訂閱者郵件箱中。顯然，這個 工做量很大。

　　結果是它把大量的時間都花在作索引和發送郵件中了。作帖子的索引是一項很耗時的操做，而發郵件給訂閱都須要鏈接到SMTP服務，而後給每個訂閱者都發一封郵件，隨着訂閱用戶的增長，發送郵件的時間會更長。

　　索引和發郵件並不須要在每次請求時觸發，理想狀態下，咱們想要批量的處理這些操做，每次只發25封郵件或者每隔5分鐘把全部的要發的新郵件發一次。咱們決定使用與數據庫原型緩存同樣的代碼，可是失敗了，因此又不得不回到VS.NET 2005。

　　咱們在System.Threading命名空間下找到了Timer類，這個類很是有用，但卻不多有人知道，Web開發人員則更少有人知道了。 一旦他建了該類的實例，每隔一個指定的時間，Timer類就會從線程池中的一個線程中調用指定的回調函數。這意味着你的asp.net應用程序能夠在沒有 請求的時候也能夠運行。這就是後以處理的解決方案。你就可讓作索引和發郵件工做在後臺運行，而不是在每次請求的時候必須執行。

　　後臺運行的技術有兩個問題，第一是，當你的應用程序域卸載後，Timer類實例就會中止運行了。也就是不會調用回調方法了。另外，由於CLR的 每一個進程中都有許多的線程在運行，你將很難讓Timer得到一個線程來執行它，或者能執行它，但會延時。Asp.net層要儘可能少的使用這種技術，以減小 進程中線程的數量，或者只讓請求用一小部分的線程。固然若是你有大量的異步工做的話，那就只能用它了。

　　這裏沒有足夠的空間有貼代碼，你能夠從http://www.rob-howard.net/中下載示例程序，請下載Blackbelt TechEd 2004的示例程序。

　　7、 頁面輸出緩存和代理服務

　　Asp.net是你的界面層（或者說應該是），它包含頁面，用戶控件，服務器控件（HttpHandlers 和HttpModules）以及它們生成的內容。若是你有一個Asp.net頁面用來輸出html，xml,imgae或者是其它的數據，對每個請求你 都用代碼來生成相同的輸出內容，你就頗有必要考慮用頁面輸出緩存了。

　　你只要簡單的把下面的這一行代碼複製到你的頁面中就能夠實現了：

　　你就能夠有效的利用第一次請求裏生成的頁面輸出緩存內容，60秒後從新生成一道頁面內容。這種技術其實也是運用一些低層的Cache API來實現。用頁面輸出緩存有幾個參數能夠配置，如上面所說的VaryByParams參數，該參數表示何時觸發重輸出的條件，也能夠指定在 Http Get或Http Post 請求模式下緩存輸出。例如當咱們設置該參數爲VaryByParams=」Report」的時候，default.aspx?Report=1或者 default.aspx?Report=2請求的輸出都會被緩存起來。參數的值能夠是多個用分號隔開參數。

　　許多人都沒有意識到當用頁面輸出緩存的時候，asp.net也會生成HTTP頭集（HTTP Header）保存在下游的緩存服務器中，這些信息能夠用於Microsoft Internet安全性中以及加速服務器的響應速度。當HTTP緩存的頭被重置時，請求的內容會被緩在網絡資源中，當客戶端再次請求該內容時，就不會再從 源服務器上得到內容了，而直接從緩存中得到內容。

　　雖然用頁面輸出緩存不提升你的應用程序性能，可是它能減小了從的服務器中加載已緩存頁面內容的次數。固然，這僅限於緩存匿名用戶能夠訪問的頁面。由於一旦頁面被緩存後，就不能再執行受權操做了。

　　8、 用IIS6.0的Kernel Caching

　　若是你的應用程序沒用運行在IIS6.0(windows server 2003)中，那麼你就失去了一些很好的提升應用程序性能的方法。在第七個方法中，我講了用頁面輸出緩存提升應用程序的性能的方法。在IIS5.0中，當 一個請求到來到IIS後，IIS會把它轉給asp.net，當應用了頁面輸出緩存時，ASP.NET中的HttpHandler會接到該請求， HttpHandler從緩存中把內容取出來並返回。

　　若是你用的是IIS6.0，它有一個很是好的功能就是Kernel Caching，並且你沒必要修改asp.net程序中任何代碼。當asp.net接到一個已緩存的請求，IIS的Kernel Cache會從緩存中獲得它的一份拷貝。當從網絡中傳來一個請求的時，Kernel層會獲得該請求，若是該請求被緩存起來了，就直接把緩存的數據返回，這 樣就完工了。這就意味着當你用IIS的Kernel Caching來緩存頁面輸出時，你將得到不可置信的性能提高。在開發VS.NET 2005的 asp.net時有一點，我是專門負asp.net性能的程序經理，個人程序員用了這個方法，我看了全部日報表數據，發現用kernel model caching的結果老是最快的。它們的一個共同的特徵就是網絡的請求和響應量很大,但IIS只佔用了5%的CPU資源。這是使人驚奇的。有許多讓你使用 用IIS6.0的理由，但kernel cashing是最好的一個。

　　9、 用Gzip壓縮數據

　　除非你的CPU佔用率過高了，纔有必要用提高服務器性能的技巧。用gzip壓縮數據的方法能夠減小你發送到服務端的數據量，也能夠提升頁面的運 行速度，同時也減小了網絡的流量。怎麼樣更好的壓縮數據取決於你要發送的數據，還有就是客戶端的瀏覽器支不支持（IIS把用gzip壓縮後的數據發送到客 戶端，客戶端要支持gzip才能解析，IE6.0和Firefox都支持）。這樣你的服務器每秒能多響應一些請求，一樣，你也減小了發送響應的數據量，也 就能多發送一些請求了。

　　好消息，gzip壓縮已經被集成在IIS6.0中了，它比IIS5.0中gzip更好。不幸的是，在IIS6.0中啓用gzip壓縮，你不能在 IIS6.0的屬性對話中設置。IIS開發團隊把gzip壓縮功能開發出來了，但他們卻忘了在管理員窗口中讓管理員能很方便的啓用它。要啓用gzip壓 縮，你只能深刻IIS6.0的xml配置文件中修改它的配置。

　　除了閱讀本文之外，只好再看看Brad Wilson寫的《IIS6 壓縮》一文（http://www.dotnetdevs.com/articles/IIS6compression.aspx）；另外還有一篇介紹aspx壓縮基礎知識的文章，Enable ASPX Compression in IIS。可是要注意，在IIS6中動態壓縮和kernel cashing是互斥的。

　　10、 服務器控件的ViewState

　　ViewState是asp.net中的一個特性，它用於把生成頁面要用的一狀態值保存在一個隱藏域中。當頁面被回傳到服務器時，服務器要解 析，校驗和應用ViewState中的數據以還原頁面的控件樹。ViewState是一個很是有用的特性，它能持久化客戶端的狀態而不用cookie或者 服務器的內存。大部分的服務器控件都是用ViewState來持久化那些在頁面中與用戶交互的元素的狀態值。例如，用以保存用於分頁的當前頁的頁碼。

　　用ViewState會帶來一些負面的影響。首先，它加大的服務器的響應和請求的時間。其次，每次回傳時都增長了序列化和反序列化數據的時間。最後，它還消耗了服務器更多的內存。

　　許多的服務器控件很趨於使用ViewState，如衆所周知的DataGrid，而有時候是沒有必須使用的。默認狀況下是容許使用 ViewState的，若是你不想使用ViewState的話，你能夠在控件或頁面級別把關閉它。在控件中，你只要把EnableViewState屬性 設爲False就能夠了；你也能夠在頁面中設置，使它的範圍擴展到整個頁面中：

　　若是頁面無需回傳或者每次請求頁面只是呈現控件。你就應該在頁面級別中把ViewState關掉。

　　總結

　　我只是提供我幾個我認爲有助於提升寫高性能的asp.net應用程序的技巧，本文提到的提升asp.net性能的技巧只是一個起步，更多的信息 請參考《Improving ASP.NET Performance》一書。只有經過本身的實踐，你才能找到對你的項目最有幫助的技巧。然而，在你的開發旅程中，這些技巧能夠起一些指導性的做用。在 軟件開發中，這些都不是絕對有用的，由於各個項目都不同。

　　服務器操做系統"管理工具"中的"性能"計數器，能夠對服務器進行監測以瞭解應用程序性能。