我正在開發一個ASP.NET MVC項目，並且我已經開始考慮我的緩存策略。我試圖讓我的框架儘可能開放，以便在緩存中使用。緩存策略，輸出緩存vs數據緩存還是兩者兼而有之？
從我在Scott Hanselman的播客中聽到的內容StackOverflow.com使用頁面輸出緩存和拉鍊內容並將其放入RAM中。這聽起來像是對用戶範圍的緩存很好，但對於像個性化頁面這樣的東西，你必須爲每個用戶緩存一個版本，並且可能會很快失去控制。
因此，對於緩存策略。應該使用哪個，輸出緩存，數據緩存還是組合？我的第一個想法都是，但就緩存依賴而言，它聽起來可能會有點複雜。
請注意過度激進的緩存。雖然緩存是幫助性能的工具，但如果使用不當，實際上可能會使性能變差。
我無法回答輸出緩存或數據緩存是否能更好地爲您工作，而無需瞭解有關項目的更多細節。 我可以幫助提供幾個關於何時使用另一個的示例。
如果你有一個特定的數據集，你會經常在許多不同的視圖中使用，你最好使用數據緩存。如果您的數據提取操作相對於數據呈現而言非常普遍且昂貴，則可以使用此操作。如果您有多個使用相同數據的視圖，則可以節省數據獲取時間。
如果你有一個視圖使用了一個非常特定的數據集，並且視圖的渲染很複雜，並且這個視圖經常被請求（例如，堆棧溢出的主頁），那麼你將從輸出緩存中受益匪淺。
所以最終，它確實取決於您的需求，並且要小心使用不正確的緩存。
我們正在大規模（每天3千萬次訪問）網站（新聞門戶網站）進行API和輸出緩存。該網站主要由匿名用戶使用，但由於網站的某些個性化部分，我們確實已對用戶進行了身份驗證，並且爲他們緩存了一個完整的網站，我必須承認，我們完全沒有任何內存壓力問題。
因此，我的建議是緩存API緩存中的所有內容，以便輸出緩存重建速度更快。
當然，密切關注性能計數器中的緩存比率值。您應該看到數字> 95％的緩存命中。
需要注意的另一件事是緩存失效，如果你有很多相關的內容，這是一個大問題。例如，您可以緩存音樂內容，並且可以顯示和緩存幾百頁上的有關一張專輯或歌曲的信息。如果該歌曲中有任何改變，則必須使所有這些可能有問題的頁面失效。底線，緩存是ASP.NET的最佳功能之一，它的表現非常好，你可以依靠它。
它基本上是一個digg克隆。 – 2009-02-17 22:16:01
查看Kigg（http://www.codeplex.com/Kigg），瞭解作爲digg克隆的ASP.NET MVC應用程序的示例。 如果你的應用程序完全像一個digg克隆，那麼我會輸出緩存故事頁面和主頁。根據數據結構的外觀，緩存用戶信息可能是必要的。 – ajma 2009-02-17 22:52:30