注意！ASP.NET MVC 3 的一個 OutputCache 問題

在用 ASP.NET MVC 3 重寫博客園網站首頁時，特地留意了一下這個緩存問題，通過這篇博文分享一下。

在 ASP.NET MVC 3 中如果使用了 OutputCache，一定要在 Action 中添加下面的代碼，切記！

Response.Cache.SetOmitVaryStar(true);

這是一個伴隨ASP.NET從1.0到4.0的OutputCache Bug，ASP.NET MVC 3 是基於 ASP.NET 4.0 的，所以也躲不過。

 

問題演示

下面先來體驗一下不加 Response.Cache.SetOmitVaryStar(true); 的情況。

示例Action代碼：

[OutputCache(Duration = 120)]
public ActionResult SiteHome(int? pageIndex)
{
    ...
}

注：OutputCache.Location的默認值是OutputCacheLocation.Any（服務端、客戶端、代理服務器端等都進行緩存）

第一次請求：

第二次請求（F5刷新瀏覽器）：

第三次請求（F5刷新瀏覽器）：

接着第四次請求會返回304，第五次請求又返回200。。。

 

再體驗一下加 Response.Cache.SetOmitVaryStar(true); 的情況。

[OutputCache(Duration = 120)]
public ActionResult SiteHome(int? pageIndex)
{
    Response.Cache.SetOmitVaryStar(true);
    ...
}

第一次請求：

第二次請求（F5刷新瀏覽器）：

第三次請求（F5刷新瀏覽器）：

注：只要在緩存有效期內，服務器一直返回304。

 

問題分析

1. 200與304的區別

當返回狀態碼是200時，服務器端會將當前請求的整個頁面全部發送給客戶端（消耗下行帶寬）。

當返回狀態碼是304時，由於客戶端瀏覽器提供的 Last-Modified 時間在服務器端的緩存有效期內，服務器端只發送這個狀態碼，不發送頁面的任何內容（幾乎不消耗下行帶寬），瀏覽器直接從本地緩存中獲取內容。

所以，304的好處就是節約帶寬，響應速度更快。

2. 對服務端緩存的影響

加不加 Response.Cache.SetOmitVaryStar(true)，服務端的緩存情況都是一樣的。只是不加 SetOmitVaryStar(true) 時，對於同一個客戶端瀏覽器，每隔一次請求，服務器端就不管客戶端瀏覽器的緩存，重新發送頁面內容，但是只要在緩存有效期內，內容還是從服務器端緩存中讀取。

 

問題危害

ASP.NET 緩存的這個詭異行為，讓你在不知不覺中浪費了帶寬資源。

 

感想

用 ASP.NET 開發多年，這個伴隨 ASP.NET 從 1.0 到 4.0 的 OutputCache Bug 自己竟然在去年才發現。之前測試時第一次請求后按F5看返回304就以為沒問題，而問題恰恰就在下一下F5，偶爾多按一下F5出現200也沒特別留意。由此可見，細心對程序員來說是多么重要，很多bug、很多性能問題往往不是水平不夠，而是不夠細心。

優秀的程序員都是細心的人，不僅在寫代碼的時候細心，在生活中也同樣細心。別看他木訥的樣子，你對他所做的一切，他都會細心地觀察到、體會到。做細心的程序員，珍惜細心的程序員！