提高ASP.Net應用程序性能的十大方法

一、返回多個數據集

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

  如果你是用動態的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專欄文章。Asp.net的緩存架構如下圖所示：
　　
五、預請求緩存

  在前面，我提到過即使我們只對某些地方作了一個小小的性能改進也可以獲得大的性能提升，我非常喜歡用預請求緩存來提升程序的性能。

  雖然Cache API設計成用來保存某段時間的數據，而預請求緩存只是保存某個時期的某個請求的內容。如果某個請求的訪問頻率高，而且這個請求只需要提取，應用，修改或者更新數據一次。那么就可以預緩存該請求。我們舉個例子來說明。

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

原文轉自：http://www.anti-gravitydesign.com