ASP.NET緩衝 方法和最佳實務

相比 ASP.NET 的所有其他特性，緩衝對應用程式的效能具有最大的潛在影響，利用緩衝和其他機制，ASP.NET 開發人員可以接受使用開銷很大的控制項（例如，DataGrid）構建網站時的額外開銷，而不必擔心效能會受到太大的影響。為了在應用程式中最大程度地利用緩衝，您應該考慮在所有程式層級上都實現緩衝的方法。
　　實現　　
　　要實現網頁輸出快取，只要將一條 OutputCache 指令添加到頁面即可。　　
　　＜%@ OutputCache Duration="60" VaryByParam="*" %＞　　
　　如同其他頁面指令一樣，該指令應該出現在 ASPX 頁面的頂部，即在任何輸出之前。它支援五個屬性（或參數），其中兩個是必需的。　
　　Duration
　　必需屬性。頁面應該被緩衝的時間，以秒為單位。必須是正整數。　
　　Location
　　指定應該對輸出進行緩衝的位置。如果要指定該參數，則必須是下列選項之一：Any、Client、Downstream、None、Server 或 ServerAndClient。　
　　VaryByParam
　　 必需屬性。Request 中變數的名稱，這些變數名應該產生單獨的緩衝條目。"none" 表示沒有變動。"*" 可用於為每個不同的變數數組建立新的緩衝條目。變數之間用 ";" 進行分隔。　　
　　VaryByHeader
　　 基於指定的標題中的變動改變緩衝條目。　　
　　VaryByCustom
　　 允許在 global.asax 中指定自訂變動（例如，"Browser"）。　　
　　利用必需的 Duration 和 VaryByParam 選項的組合可以處理大多數情況。例如，如果您的產品目錄允許使用者基於 categoryID 和頁變數查看目錄頁，您可以用參數值為 "categoryID;page" 的 VaryByParam 將產品目錄緩衝一段時間（如果產品不是隨時都在改變，一小時還是可以接受的，因此，期間是 3600 秒）。這將為每個種類的每個目錄頁建立單獨的緩衝條目。每個條目從其第一個請求算起將維持一個小時。　
　　VaryByHeader 和 VaryByCustom 主要用於根據訪問頁面的用戶端對頁面的外觀或內容進行自訂。同一個 URL 可能需要同時為瀏覽器和行動電話用戶端轉譯輸出，因此，需要針對不同的用戶端緩衝不同的內容版本。或者，頁面有可能已經針對 IE 進行了最佳化，但需要能針對 Netscape 或 Opera 完全降低最佳化（而不僅僅是破壞頁面）。後一個例子非常普遍，我們將提供一個說明如何?此目標的樣本：　
　　樣本：VaryByCustom 用於支援瀏覽器自訂　　
　　為了使每個瀏覽器都具有單獨的緩衝條目，VaryByCustom 的值可以設定為 "browser"。此功能已經內建在緩衝模組中，並且將針對每個瀏覽器名稱和主要版本插入單獨的頁面緩衝版本。　
　　＜%@ OutputCache Duration="60" VaryByParam="None" VaryByCustom="browser" %＞　
　　片段快取，使用者控制項輸出緩衝
　　緩衝整個頁面通常並不可行，因為頁面的某些部分是針對使用者定製的。不過，頁面的其他部分是整個應用程式共有的。這些部分最適合使用片段快取和使用者控制項進行緩衝。菜單和其他布局元素，尤其是那些從資料來源動態產生的元素，也應該用這種方法進行緩衝。如果需要，可以將緩衝的控制項配置為基於對其控制項（或其他屬性）的更改或由頁面級輸出緩衝支援的任何其他變動進行改變。使用同一組控制項的幾百個頁面還可以共用那些控制項的緩衝條目，而不是為每個頁面保留單獨的緩衝版本。　

　　實現　　
　　片段快取使用的文法與頁面級輸出緩衝一樣，但其應用於使用者控制項（.ascx 檔案）而不是 Web Form（.aspx 檔案）。除了 Location 屬性，對於 OutputCache 在 Web Form上支援的所有屬性，使用者控制項也同樣支援。使用者控制項還支援名為 VaryByControl 的 OutputCache 屬性，該屬性將根據使用者控制項（通常是頁面上的控制項，例如，DropDownList）的成員的值改變該控制項的緩衝。如果指定了 VaryByControl，可以省略 VaryByParam。最後，在預設情況下，對每個頁面上的每個使用者控制項都單獨進行緩衝。不過，如果一個使用者控制項不隨應用程式中的頁面改變，並且在所有頁面都使用相同的名稱，則可以應用 Shared="true" 參數，該參數將使使用者控制項的緩衝版本供所有引用該控制項的頁面使用。
　　樣本　　
　　＜%@ OutputCache Duration="60" VaryByParam="*" %＞　　
　　該樣本將緩衝使用者控制項 60 秒，並且將針對查詢字串的每個變動、針對此控制項所在的每個頁面建立單獨的緩衝條目。　　
　　＜%@ OutputCache Duration="60" VaryByParam="none"
　　VaryByControl="CategoryDropDownList" %＞　　
　　該樣本將緩衝使用者控制項 60 秒，並且將針對 CategoryDropDownList 控制項的每個不同的值、針對此控制項所在的每個頁面建立單獨的緩衝條目。　　
　　＜%@ OutputCache Duration="60" VaryByParam="none" VaryByCustom="browser"
　　Shared="true %＞　　
　　最後，該樣本將緩衝使用者控制項 60 秒，並且將針對每個瀏覽器名稱和主要版本建立一個緩衝條目。然後，每個瀏覽器的緩衝條目將由引用此使用者控制項的所有頁面共用（只要所有頁面都用相同的 ID 引用該控制項即可）。　　
　　頁面級和使用者控制項級輸出緩衝的確是一種可以迅速而簡便地提高網站效能的方法，但是在 ASP.NET 中，緩衝的真正靈活性和強大功能是通過 Cache 對象提供的。使用 Cache 對象，您可以儲存任何可序列化的資料對象，基於一個或多個依賴項的組合來控制緩衝條目到期的方式。這些依賴項可以包括自從項被緩衝後經過的時間、自從項上次被訪問後經過的時間、對檔案和/或檔案夾的更改以及對其他快取項目的更改，在略作處理後還可以包括對資料庫中特定表的更改。　
　　在 Cache 中儲存資料　　
　　在 Cache 中儲存資料的最簡單的方法就是使用一個鍵為其賦值，就像 HashTable 或 Dictionary 對象一樣：　　
　　Cache["key"] = "value";　　
　　這種做法將在緩衝中儲存項，同時不帶任何依賴項，因此它不會到期，除非緩衝引擎為了給其他快取資料提供空間而將其刪除。要包括特定的緩衝依賴項，可使用 Add() 或 Insert() 方法。其中每個方法都有幾個重載。Add() 和 Insert() 之間的唯一區別是，Add() 返回對已緩衝對象的引用，而 Insert() 沒有傳回值（在 C# 中為空白，在 VB 中為 Sub）。　　
　　樣本　
　　Cache.Insert("key", myXMLFileData, new
　　System.Web.Caching.CacheDependency(Server.MapPath("users.xml")));　　
　　該樣本可將檔案中的 xml 資料插入緩衝，無需在以後請求時從檔案讀取。 CacheDependency 的作用是確保緩衝在檔案更改後立即到期，以便可以從檔案中提取最新資料，重新進行緩衝。如果緩衝的資料來自若干個檔案，還可以指定一個檔案名稱的數組。　　
　　Cache.Insert("dependentkey", myDependentData, new
　　System.Web.Caching.CacheDependency(new string[] {}, new string[]
　　{"key"}));　　
　　該樣本可插入索引值為 "key" 的第二個資料區塊（取決於是否存在第一個資料區塊）。如果緩衝中不存在名為 "key" 的鍵，或者如果與該鍵相關聯的項已到期或被更新，則 "dependentkey" 的緩衝條目將到期。　　
　　Cache.Insert("key", myTimeSensitiveData, null,
　　DateTime.Now.AddMinutes(1), TimeSpan.Zero);　　
　　絕對到期：此樣本將對受時間影響的資料緩衝一分鐘，一分鐘過後，緩衝將到期。注意，絕對到期和滑動到期（見下文）不能一起使用。　　
　　Cache.Insert("key", myFrequentlyAccessedData, null,
　　System.Web.Caching.Cache.NoAbsoluteExpiration,
　　TimeSpan.FromMinutes(1));　　
　　滑動到期：此樣本將緩衝一些頻繁使用的資料。資料將在緩衝中一直保留下去，除非資料未被引用的時間達到了一分鐘。注意，滑動到期和絕對到期不能一起使用。　

　　更多選項　　
　　除了上面提到的依賴項，我們還可以指定項的優先順序（依次為 low、high、NotRemovable，它們是在 System.Web.Caching.CacheItemPriority 枚舉中定義的）以及當緩衝中的項到期時調用的 CacheItemRemovedCallback 函數。大多數時候，預設的優先順序已經足夠了 — 緩衝引擎可以正常完成任務並處理緩衝的記憶體管理。CacheItemRemovedCallback 選項考慮到一些很有趣的可能性，但實際上它很少使用。不過，為了說明該方法，我將提供它的一個使用樣本：　　
　　CacheItemRemovedCallback 樣本
　
　　System.Web.Caching.CacheItemRemovedCallback callback = new System.Web.Caching.CacheItemRemovedCallback (OnRemove);
　　Cache.Insert("key",myFile,null,
　　System.Web.Caching.Cache.NoAbsoluteExpiration,
　　TimeSpan.Zero,
　　System.Web.Caching.CacheItemPriority.Default, callback);
　　. . .
　　public static void OnRemove(string key,
　　object cacheItem,
　　System.Web.Caching.CacheItemRemovedReason reason)
　　{
　　AppendLog("The cached value with key '" + key +
　　"' was removed from the cache. Reason: " +
　　reason.ToString());
　　}　　
　　該樣本將使用 AppendLog() 方法（這裡不討論該方法，請參閱 Writing Entries to Event Logs）中定義的任何邏輯來記錄緩衝中的資料到期的原因。通過在從緩衝中刪除項時記錄這些項並記錄刪除的原因，您可以確定是否在有效地使用緩衝或者您是否可能需要增加伺服器上的記憶體。注意，callback 是一個靜態（在 VB 中為 Shared）方法，建議使用該方法的原因是，如果不使用它，儲存回呼函數的類的執行個體將保留在記憶體中，以支援回調（對 static/Shared 方法則沒有必要）。　　
　　該特性有一個潛在的用處 — 在後台重新整理緩衝的資料，這樣使用者永遠都不必等待資料被填充，但資料始終保持相對較新的狀態。但實際上，此特性並不適用於目前的版本的緩衝 API，因為在從緩衝中刪除緩衝的項之前，不觸發或不完成回調。因此，使用者將頻繁地發出嘗試訪問緩衝值的請求，然後發現緩衝值為空白，不得不等待緩衝值的重新填充。我希望在未來的 ASP.NET 版本中看到一個附加的回調，可以稱為 CachedItemExpiredButNotRemovedCallback，如果定義了該回調，則必須在刪除快取項目之前完成執行。　　
　　快取資料參考模式　　
　　每當我們嘗試訪問緩衝中的資料時，都應該考慮到一種情況，那就是資料可能已經不在緩衝中了。因此，下面的模式應該普遍適用於您對緩衝的資料的訪問。在這種情況下，我們假定已緩衝的資料是一個資料表。　　 複製代碼 代碼如下:　　public DataTable GetCustomers(bool BypassCache)
　　{
　　string cacheKey = "CustomersDataTable";
　　object cacheItem = Cache[cacheKey] as DataTable;
　　if((BypassCache) 　　 (cacheItem == null))
　　{
　　cacheItem = GetCustomersFromDataSource();
　　Cache.Insert(cacheKey, cacheItem, null,
　　DateTime.Now.AddSeconds(GetCacheSecondsFromConfig(cacheKey),
　　TimeSpan.Zero);
　　}
　　return (DataTable)cacheItem;
　　}　　

　　關於此模式，有以下幾點需要注意： 　　
　　? 某些值（例如，cacheKey、cacheItem 和緩衝期間）是一次定義的，並且只定義一次。　
　　? 可以根據需要跳過緩衝 — 例如，當註冊一個新客戶並重新導向到客戶列表後，最好的做法可能就是跳過緩衝，用最新資料重新填充緩衝，該資料包括新插入的客戶。 　　
　　? 緩衝只能訪問一次。這種做法可以提高效能，並確保不會發生 NullReferenceExceptions，因為該項在第一次被檢查時是存在的，但第二次檢查之前就已經到期了。 　　
　　? 該模式使用強型別檢查。C# 中的 "as" 運算子嘗試將對象轉換為類型，如果失敗或該對象為空白，則只返回 null（空）。 　　
　　? 期間儲存在設定檔中。在理想的情況下，所有的緩衝依賴項（無論是基於檔案的，或是基於時間的，還是其他類型的依賴項）都應該儲存在設定檔中，這樣就可以變更並輕鬆地測量效能。我還建議您指定預設緩衝期間，而且，如果沒有為所使用的 cacheKey 指定期間，就讓 GetCacheSecondsFromConfig() 方法使用該預設期間。 　　
　　相關的程式碼範例是一個 helper 類，它將處理上述所有情況，但允許通過一行或兩行代碼訪問緩衝的資料。請下載 CacheDemos.msi。　　
　　小結
　　緩衝可以使應用程式的效能得到很大的提高，因此在設計應用程式以及對應用程式進行效能測試時應該予以考慮。應用程式總會或多或少地受益於緩衝，當然有些應用程式比其他應用程式更適合使用緩衝。對 ASP.NET 提供的緩衝選項的深刻理解是任何 ASP.NET 開發人員應該掌握的重要技巧。　

　　儘早緩衝；經常緩衝　　
　　您應該在應用程式的每一層都實現緩衝。向資料層、商務邏輯層、UI 或輸出層添加緩衝支援。記憶體現在非常便宜 — 因此，通過以智能的方式在整個應用程式中實現緩衝，可以獲得很大的效能提高。
　　緩衝可以掩蓋許多過失　　
　　緩衝是一種無需大量時間和分析就可以獲得"足夠良好的"效能的方法。這裡再次強調，記憶體現在非常便宜，因此，如果您能通過將輸出緩衝 30 秒，而不是花上一整天甚至一周的時間嘗試最佳化代碼或資料庫就可以獲得所需的效能，您肯定會選擇緩衝解決方案（假設可以接受 30 秒的舊資料）。緩衝正是那些利用 20% 付出獲得 80% 回報的特性之一，因此，要提高效能，應該首先想到緩衝。不過，如果設計很糟糕，最終卻有可能帶來不良的後果，因此，您當然也應該盡量正確地設計應用程式。但如果您只是需要立即獲得足夠高的效能，緩衝就是您的最佳選擇，您可以在以後有時間的時候再儘快重新設計應用程式。　　
　　頁面級輸出緩衝
　　作為最簡單的緩衝形式，輸出緩衝只是在記憶體中保留為響應請求而發送的 HTML 的副本。其後再有請求時將提供緩衝的輸出，直到緩衝到期，這樣，效能有可能得到很大的提高（取決於需要多少開銷來建立原始頁面輸出 - 發送緩衝的輸出總是很快，並且比較穩定）。