asp.net資料最佳化方法

使用預存程序 　
　
預存程序是儲存在伺服器上的一組先行編譯的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 檔案中 節點的所有功能均保留為啟用。根據應用程式所使用的功能，您可以從請求管線中移除不用的模組以獲得稍許的效能提升。檢查每個模組及其功能，並按您的需要自訂它。例如，如果您在應用程式中不使用工作階段狀態和輸出緩衝，則可以從 列表中移除它們，以便請求在不執行其他有意義的處理時，不必執行每個模組的進入和離開代碼。

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 設定檔節點的 maxWorkerThreads 和 maxIOThreads 屬性，手動設定進程中的線程數限制。 　　

注意：輔助線程是用來處理 ASP.NET 請求的，而 IO 線程則是用於為來自檔案、資料庫或 XML Web services 的資料提供服務的。分配給這些屬性的值是進程中每個 CPU 每類線程的最大數目。對於雙處理器電腦，最大數是設定值的兩倍。對於四處理器電腦，最大值是設定值的四倍。無論如何，對於有四個或八個 CPU 的電腦，最好更改預設值。對於有一個或兩個處理器的電腦，預設值就可以，但對於有更多處理器的電腦的效能，進程中有一百或兩百個線程則弊大於利。注意進程中有太多線程往往會降低伺服器的速度，因為額外的上下文交換導致作業系統將 CPU 週期花在維護線程而不是處理請求上。