每當應用程序連接資源時,如在另一個進程中運行的數據庫,您都應該重點考慮連接該資源所花時間、發送或檢索數據所花時間,以及往返的數量,從而進行優化。優化應用程序中任何種類的進程跳躍都是獲得更佳性能的首要一點。
應用層包含了連接數據層、將數據轉換為有意義類實例和業務流程的邏輯。例如社區服務器,您要在其中填充Forums 或 Threads集合,應用業務規則(如權限);最重要的是要在其中執行緩存邏輯。
================================
技巧 4 — ASP.NET 緩存 API
編寫應用程序代碼行之前,一個首要完成的操作是設計應用層的結構,以便最大化利用 ASP.NET 緩存功能。
如果您的組件要在 ASP.NET 應用程序中運行,則只需在該應用程序項目中包括一個 System.Web.dll 引用。當您需要訪問該緩存時,請使用 HttpRuntime.Cache 屬性(通過 Page.Cache 和 HttpContext.Cache 也可訪問這個對象)。
對于緩存數據,有幾個規則。首先,如果數據可能會多次使用時,則這是使用緩存的一個很好的備選情況。第二,如果數據是通用的,而不特定于某個具體的請求或用戶時,則也是使用緩存的一個很好的備選情況。如果數據是特定于用戶或請求的,但是壽命較長的話,仍然可以對其進行緩存,但是這種情況可能并不經常使用。第三,一個經常被忽略的規則是,有時可能您緩存得太多。通常在一個 x86 計算機上,為了減少內存不足錯誤出現的機會,您會想使用不高于 800MB 的專用字節運行進程。因此緩存應該有個限度。換句話說,您可能能夠重用某個計算結果,但是如果該計算采用 10 個參數的話,您可能要嘗試緩存 10 個排列,這樣有可能給您帶來麻煩。一個要求 ASP.NET 的最常見支持是由于過度緩存引起的內存不足錯誤,尤其是對于大型數據集。
圖 3 ASP.NET緩存
緩存有幾個極佳的功能,您需要對它們有所了解。首先,緩存會實現最近最少使用的算法,使得 ASP.NET 能夠在內存運行效率較低的情況下強制緩存清除 - 從緩存自動刪除未使用過的項目。第二,緩存支持可以強制失效的過期依賴項。這些依賴項包括時間、密鑰和文件。時間經常會用到,但是對于 ASP.NET 2.0,引入了一個功能更強的新失效類型:數據庫緩存失效。它指的是當數據庫中的數據發生變化時自動刪除緩存中的項。有關數據庫緩存失效的詳細信息,請參閱 MSDN?Magazine 2004 年 7 月的 Dino Esposito Cutting Edge 專欄。要了解緩存的體系結構,請參閱圖 3。
=======================
技巧 5 — 每請求緩存
在本文前面部分,我提到了經常遍歷代碼路徑的一些小改善可能會導致較大的整體性能收益。對于這些小改善,其中有一個絕對是我的最愛,我將其稱之為“每請求緩存”。
緩存 API 的設計目的是為了將數據緩存較長的一段時間,或者緩存至滿足某些條件時,但每請求緩存則意味著只將數據緩存為該請求的持續時間。對于每個請求,要經常訪問某個特定的代碼路徑,但是數據卻只需提取、應用、修改或更新一次。這聽起來有些理論化,那么我們來舉一個具體的示例。
在社區服務器的論壇應用程序中,頁面上使用的每個服務器控件都需要個性化的數據來確定使用什么外觀、使用什么樣式表,以及其他個性化數據。這些數據中有些可以長期緩存,但是有些數據卻只針對每個請求提取一次,然后在執行該請求期間對其重用多次,如要用于控件的外觀。
為了達到每請求緩存,請使用 ASP.NET HttpContext。對于每個請求,都會創建一個 HttpContext 實例,在該請求期間從 HttpContext.Current 屬性的任何位置都可訪問該實例。該 HttpContext 類具有一個特殊的 Items 集合屬性;添加到此 Items 集合的對象和數據只在該請求持續期間內進行緩存。正如您可以使用緩存來存儲經常訪問的數據一樣,您也可以使用 HttpContext.Items 來存儲只基于每個請求使用的數據。它背后的邏輯非常簡單:數據在它不存在的時候添加到 HttpContext.Items 集合,在后來的查找中,只是返回 HttpContext.Items 中的數據。
=====================
技巧 6 — 后臺處理
文章來源于領測軟件測試網 http://www.k11sc111.com/