上下文
實現策略
測試考慮事項
結果上下文
變體
相關模式
您要在 ASP.NET 中構建一個 Web 應用程式，並且希望對頁面進行緩衝以提高效能。您已經評估了 Page Cache （頁面緩衝）中提出的備用選擇方案，並且已決定採用絕對到期的策略。
返回頁首 實現策略頁面緩衝通過對從動態網頁產生的內容進行緩衝來提高請求響應的輸送量。預設情況下，在 ASP.NET 中支援頁面緩衝，但除非定義有效到期策略，否則，不會對來自任何給定響應的輸出進行緩衝。要定義到期策略，可以使用低級 OutputCache API 或進階 @OutputCache 指令。
啟用頁面緩衝後，對頁面的第一個 GET 請求將建立一個頁面緩衝條目。該頁面緩衝條目用於響應隨後的 GET 或 HEAD 請求，直到緩衝的響應到期。
頁面緩衝遵循頁面的到期策略。如果對到期策略為 60 秒的頁面進行緩衝，經過 60 秒之後，該頁面將從輸出緩衝中刪除。如果緩衝在該時間之後收到另一個請求，它將執行網頁代碼並重新整理緩衝。這種到期策略稱為"絕對到期"，它意味著在某個時間之前頁面一直是有效。
下面的樣本說明了使用@OutputCache指令對響應進行緩衝的方式：
<%@ OutputCache Duration="60" VaryByParam="none" %> <html> <script language="C#" runat="server"> void Page_Load(Object sender, EventArgs e) { TimeMsg.Text = DateTime.Now.ToString("G"); } </script> <body> <h3>Using the Output Cache</h3> <p>Last generated on: <asp:label id="TimeMsg" runat="server"/> </body> </html>
該樣本顯示了產生響應的時間。要瞭解輸出緩衝的作用，請調用該網頁，並注意產生響應的時間。然後重新整理網頁，您會注意到時間沒有更改，這說明第二個響應是從緩衝提供的。
下面的程式碼啟用對響應的頁面緩衝：
<%@ OutputCache Duration="60" VaryByParam="none" %>
此指令只說明，頁面應該緩衝 60 秒，頁面不會因任何 GET 或 POST 參數而改變。在第一個 60 秒內收到的請求是從緩衝提供的。經過 60 秒之後，該頁面從緩衝中刪除；下一個請求再次緩衝該頁面。
返回頁首 測試考慮事項頁 面緩衝使測試變得更加困難。例如，如果您更改了網頁，然後在瀏覽器中查看該網頁，您可能不會看到更新的網頁，因為瀏覽器顯示的是從緩衝提供的頁面，而不是 最新產生的頁面。在理想情況下，您可以關閉頁面緩衝，然後運行不需要緩衝的測試。當這些測試成功運行後，您可以啟用緩衝，然後運行需要緩衝的測試。
返回頁首 結果上下文在 ASP.NET 中使用絕對到期模式來實現 Page Cache 具有以下優缺點：
優點
這是到目前為止 ASP.NET 中最簡單的頁面緩衝方法。如果您要分析 Web 應用程式的使用模式來確定緩衝哪些頁面，那麼，在許多情況下絕對到期可能已經足夠了，而且無疑是一個很好的開端。另外，還要考慮到網頁上動態內容的變動性。例如，天氣網頁的到期策略可以是 60 分鐘，因為天氣不會變得很快。不過，顯示股票報價的網頁可能根本不能緩衝。為了確定正確的到期時間，必須知道哪些是最頻繁查看的網頁，並理解網頁所包含的資料的變動性。
您可以為不同的網頁設定不同的到期策略。通過這種做法，您可以只對頻繁訪問的網頁進行緩衝，而不會將緩衝空間浪費在很少訪問的網頁上。您還可以重新整理包含的資料比其他資料更經常變動的網頁。
缺點
緩衝的頁面上的動態內容可能是無效的。這是因為頁面到期基於時間而不是內容。在前面描述的樣本中，時間在幾秒鐘之後才顯示在網頁上。因為該網頁每 60 秒構建一次，秒欄位在頁面構建後的瞬間內是無效的。此樣本中的無效資料部分是很小的。例如，如果您要顯示對時間非常敏感的金融報價，並且需要很高的準確性，請考慮採用可確保您決不會顯示無效資料的緩衝策略。（請參閱"Page Data Caching"。）
此策略不支援將參數傳遞到網頁。動態網頁常常由參數來確定。例如，天氣網頁可能用郵遞區號作為參數。除非您希望為數千個郵遞區號（例如，美國有 42,000 個郵遞區號）建立不同的網頁和 URL，否則，您不能使用絕對到期對該網頁進行緩衝。Vary-By-Parameter Caching 解決了這個問題。
只有整個網頁保持不變時才適用絕對到期。在許多應用程式中，網頁的大部分很少發生更改（非常適用緩衝），但與經常更改的其他部分（不能進行緩衝）是耦合在一起的。因為絕對到期模式只緩衝整個網頁，它不能利用像這樣的局部更改。在這些情況下，Page Fragment Caching 可能是一個更好的選擇，因為它可以對網頁的一部分進行緩衝。HTML 架構為類比頁面分段提供了另一個選擇。不過，架構在 Web 瀏覽器中有一些已知問題，例如，導航和列印問題。
無法重新整理緩衝的頁面。 網頁在到期或重新啟動伺服器之前，一直保留在緩衝中。這就使測試成了問題。另外，在資料很少發生更改、可一旦發生更改決不能延遲的情況下，緩衝也有很大的 問題。例如，每兩小時更新天氣預報在大多數時間可能已經足夠了。不過，如果颶風正在逼近，您也許不希望等兩小時後再更新天氣預報。
必須修改每頁的代碼才能更改到期策略。因為到期策略只能在代碼中更改，所以沒有關閉整個應用程式的緩衝的機制。
在緩衝中儲存網頁需要伺服器上的磁碟空間。在前面描述的樣本中，較小的網頁不會需要很多磁碟空間。不過，隨著每個網頁上的內容以及緩衝中網頁數目的增加，要求 Web 伺服器提供更多的磁碟空間。
下面的模式解釋了 Page Cache 的其他實現方法：
Vary-By-Parameter Caching
Sliding Expiration Caching
有關相關頁面緩衝設計和實現策略，請參閱以下模式：
Page Data Caching
Page Fragment Caching
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
