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組擔任程序經理，運行和管理http://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的程序優化的問題。
如果在你的代碼中有一段必須訪問數據庫的請求，而你在其它的地方又看到實現同樣的功能 的代碼，那麼你首先要優化它。修改和完善繼續測試，除非你有一個非常大的性能問題，你的時間最好花在優化查詢，連接數據庫，返回數據集的大小，以及一次查詢往返回的時間上。
根據經驗的總結，讓我們來看看十個能幫助你提升你的應用程序性能的經驗，我將按將它們提升效率的多少從大到小小依次說明。
一、返回多個數據集
檢查你的訪問數據庫的代碼，看是否存在着要返回多次的請求。每次往返降低了你的應用程序的每秒能夠響應請求的次數。通過在單個數據庫請求中返回多個結果集，可以減少與數據庫通信的時間，使你的系統具有擴展性，也可以減少數據庫服務器響應請求的工作量。
如果你是用動態的SQL語句來返回多個數據集，那我建議你用存儲過程來替代動態的SQL語句。是否把業務邏輯寫到存儲過程中，這個有點爭議。但是我認爲，把業務邏輯寫到存儲過程裏面可以限制返回結果集的大小，減小網絡數據的流量，在邏輯層也不用在過濾數據，這是一個好事情。
用SqlCommand對象的ExecuteReader方法返回一個強類型的業務對象，再調用NextResult方法來移動數據集指針來定位數據集。示例一演示了一個返回多個ArrayList強類型對象的例子。只從數據庫中返回你需要的數據可以大大的減小你的服務器所耗用的內存。
二、對數據進行分頁
ASP.NET的DataGrid有一個非常有用的功能：分頁。如果DataGrid允許分頁，在某一時刻它只下載某一頁的數據，另外，它有一個數據分頁的瀏覽導航欄，它讓你可以選擇瀏覽某一頁，而且每次只下載一頁的數據。
但是它有一個小小的缺點，就是你必須把所有的數據都綁定到DataGrid中。也就是說，你的數據層必須返回所有的數據，然後DataGrid再根據當前頁過濾出當前頁所需要的數據顯示出來。如果有一個一萬條記錄的結果集要用DataGrid進行分頁，假設DataGrid每頁只顯示25條數據，那就意味着每次請求都有9975條數據都是要丟棄的。每次請求都要返回這麼大的數據集，對應用程序的性能影響是非常大的。
一個好的解決方案是寫一個分頁的存儲過程，例子2是一個用於對Northwind數據庫orders表的分頁存儲過程。你只需要傳當前頁碼，每頁顯示的條數兩個參數進來，存儲過程會返回相應的結果。
在服務器端，我專門寫了一個分頁的控件來處理數據的分頁，在這裏，我用了第一個方法，在一個存儲過程裏面返回了兩個結果集：數據記錄總數和要求的結果集。
返回的記錄總數取決於要執行查詢，例如，一個where條件可以限制返回的結果集的大小。因爲在分頁界面中必須要根據數據集記錄的大小來計算總的頁數，所以必須要返回結果集的記錄數。例如，如果一共有1000000條記錄，如果用where條件就可以過濾成只返回1000條記錄，存儲過程的分頁邏輯應該知道返回那些需要顯示的數據。
三、連接池
用TCP來連接你的應用程序與數據庫是一件昂貴的事情（很費時的事情），微軟的開發者可以通過用連接池來反覆的使用數據庫的連接。比起每次請求都用TCP來連一次數據庫，連接池只有在不存在有效的連接時才新建一個TCP連接。當關閉一個連接的時候，它會被放到池中，它仍然會保持與數據庫的連接，這樣就可以減少與數據庫的TCP連接次數。
當然，你要注意那些忘記關的連接，你應在每次用完連接後馬上關閉它。我要強調的是：無論什麼人說.NET Framework中的GC(垃圾收集器)總會在你用完連接對象後調用連接對象的Close或者Dispose方法顯式的關閉你的連接。不要期望CLR會在你想象的時間內關掉連接，雖然CLR最終都要銷燬對象和關閉邊接，但是我們並不能確定它到底會在什麼時候做這些事情。
要用連接池優化，有兩條規則，第一，打開連接，處理數據，然後關閉連接。如果你必須在每次請求中多次打開或關閉連接，這好過一直打開一個邊接，然後把它傳到各個方法中。第二，用相同的連接字符串（或者用相同的用戶標識，當你用集成認證的時候）。如果你沒有用相同的連接字符串，如你用基於登錄用戶的連接字符串，這將不能利用連接池的優化功能。如果你用的是集成的論證，因爲用戶很多，所以你也不能充分利用連接池的優化功能。.NET CLR提供了一個數據性能計數器，它在我們需要跟蹤程序性能特性的時候非常有用，當然也包括連接池的跟蹤了。
無論你的應用程序什麼時候要連在另一臺機子的資源，如數據庫，你都應該重點優化你連資源所花的時間，接收和發送數據的時間，以及往返回之間的次數。優化你的應用程序中的每一個處理點（process hop），它是提高你的應用的性能的出發點。
應用程序層包含與數據層連接，傳送數據到相應的類的實例以及業務處理的邏輯。例如，在Community Server中，要組裝一個Forums或者Threads集合，然後應用業務邏輯，如授權，更重要的，這裏要完成緩存邏輯。
四、 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專欄文章。
五、 預請求緩存
在前面，我提到過即使我們只對某些地方作了一個小小的性能改進也可以獲得大的性能提升，我非常喜歡用預請求緩存來提升程序的性能。
雖然Cache API設計成用來保存某段時間的數據，而預請求緩存只是保存某個時期的某個請求的內容。如果某個請求的訪問頻率高，而且這個請求只需要提取，應用，修改或者更新數據一次。那麼就可以預緩存該請求。我們舉個例子來說明。
在CS的論壇應用程序中，每一個頁面的服務器控件都要求得到用於決定它的皮膚（skin）的自定義的數據，以決定用哪個樣式表及其它的一些個性化的東西。這裏面的某些數據可能要長時間的保存，有些時間則不然，如控件的skin數據，它只需要應用一次，而後就可以一直使用。
要實現預請求緩存，用Asp.net 的HttpContext類，HttpContext類的實例在每一個請求中創建，在請求期間的任何地方都可以通過HttpContext.Current屬性訪問。HttpContext類有一個Items集合屬性，在請求期間所有的對象和數據都被添加到這個集合中緩存起來。和你用Cache緩存訪問頻率高數據一樣，你可以用HttpContext.Items緩存那些每個請求都要用到的基礎數據。它背後的邏輯很簡單：我們向HttpContext.Items中添加一個數據，然後再從它裏面讀出數據。
六、 後臺處理
通過上面的方法你的應用程序應該運行得很快了，是不是？但是在某些時候，程序中的一次請求中可能要執行一個非常耗時的任務。如發送郵件或者是檢查提交的數據的正確性等。
當我們把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的示例程序。
七、 頁面輸出緩存和代理服務
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緩存的頭被重置時，請求的內容會被緩在網絡資源中，當客戶端再次請求該內容時，就不會再從源服務器上獲得內容了，而直接從緩存中獲得內容。
雖然用頁面輸出緩存不提高你的應用程序性能，但是它能減少了從的服務器中加載已緩存頁面內容的次數。當然，這僅限於緩存匿名用戶可以訪問的頁面。因爲一旦頁面被緩存後，就不能再執行授權操作了。
八、 用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是最好的一個。
九、 用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是互斥的。
十、 服務器控件的ViewState
ViewState是asp.net中的一個特性，它用於把生成頁面要用的一狀態值保存在一個隱藏域中。當頁面被回傳到服務器時，服務器要解析，校驗和應用ViewState中的數據以還原頁面的控件樹。ViewState是一個非常有用的特性，它能持久化客戶端的狀態而不用cookie或者服務器的內存。大部分的服務器控件都是用ViewState來持久化那些在頁面中與用戶交互的元素的狀態值。例如，用以保存用於分頁的當前頁的頁碼。
用ViewState會帶來一些負面的影響。首先，它加大的服務器的響應和請求的時間。其次，每次回傳時都增加了序列化和反序列化數據的時間。最後，它還消耗了服務器更多的內存。
許多的服務器控件很趨於使用ViewState，如衆所周知的DataGrid，而有時候是沒有必須使用的。默認情況下是允許使用ViewState的，如果你不想使用ViewState的話，你可以在控件或頁面級別把關閉它。在控件中，你只要把EnableViewState屬性設爲False就可以了；你也可以在頁面中設置，使它的範圍擴展到整個頁面中：
如果頁面無需回傳或者每次請求頁面只是呈現控件。你就應該在頁面級別中把ViewState關掉。
總結
我只是提供我幾個我認爲有助於提高寫高性能的asp.net應用程序的技巧，本文提到的提高asp.net性能的技巧只是一個起步，更多的信息請參考《Improving ASP.NET Performance》一書。只有通過自己的實踐，你才能找到對你的項目最有幫助的技巧。然而，在你的開發旅程中，這些技巧可以起一些指導性的作用。在軟件開發中，這些都不是絕對有用的，因爲各個項目都不一樣。
服務器操作系統"管理工具"中的"性能"計數器，可以對服務器進行監測以瞭解應用程序性能。