關於緩衝剩下的問題是資料的隱私性以及在級聯緩衝中資料應該在何處儲存的問題。
通常使用者將會面對兩種緩衝: 他或她自己的瀏覽器緩衝(私人緩衝)以及他或她的提供者緩衝(公用緩衝)。 公用緩衝由多個使用者使用,而受其他某人的控制。 這就產生了你不想遇到的敏感性資料的問題,比如說你的銀行帳號被儲存在公眾緩衝中。 因此,Web 應用程式需要以某種方式告訴緩衝那些資料是私人的,哪些是公用的。
解決方案是標示出某個頁面緩衝應當是私人的。 要在 Django 中完成此項工作,可使用 cache_control 視圖修飾器: 例如:
from django.views.decorators.cache import cache_control@cache_control(private=True)def my_view(request): # ...
該修飾器負責在後台發送相應的 HTTP 頭部。
還有一些其他方法可以控制緩衝參數。 例如, HTTP 允許應用程式執行如下操作:
- 定義頁面可以被緩衝的最大時間。
- 指定某個緩衝是否總是檢查較新版本,僅當無更新時才傳遞所緩衝內容。 (一些緩衝即便在伺服器頁面發生變化的情況下仍然會傳送所緩衝的內容,只因為緩衝拷貝沒有到期。)
在 Django 中,可使用 cache_control 視圖修飾器指定這些緩衝參數。 在本例中, cache_control 告訴緩衝對每次訪問都重新驗證緩衝並在最長 3600 秒內儲存所緩衝版本:
from django.views.decorators.cache import cache_control@cache_control(must_revalidate=True, max_age=3600)def my_view(request): # ...
在 cache_control() 中,任何合法的Cache-Control HTTP 指令都是有效。下面是完整列表:
public=True private=True no_cache=True no_transform=True must_revalidate=True proxy_revalidate=True max_age=num_seconds s_maxage=num_seconds
緩衝中介軟體已經使用 CACHE_MIDDLEWARE_SETTINGS 設定設定了緩衝頭部 max-age 。 如果你在cache_control修飾器中使用了自訂的max_age,該修飾器將會取得優先權,該頭部的值將被正確地被合并。
如果你想用頭部完全禁掉緩衝,django.views.decorators.cache.never_cache裝飾器可以添加確保響應不被緩衝的頭部資訊。 例如:
from django.views.decorators.cache import never_cache@never_cachedef myview(request): # ...
其他最佳化
Django 帶有一些其它中介軟體可協助您最佳化應用程式的效能:
- django.middleware.http.ConditionalGetMiddleware 為現代瀏覽器增加了有條件的,基於 ETag 和 Last-Modified 頭標的GET響應的相關支援。
- django.middleware.gzip.GZipMiddleware 為所有現代瀏覽器壓縮響應內容,以節省頻寬和傳送時間。
MIDDLEWARE_CLASSES 的順序
如果使用緩衝中介軟體,注意在MIDDLEWARE_CLASSES設定中正確配置。 因為緩衝中介軟體需要知道哪些頭部資訊由哪些緩衝區來區分。 中介軟體總是儘可能得想Vary回應標頭中添加資訊。
UpdateCacheMiddleware在相應階段運行。因為中介軟體是以相反順序啟動並執行,所有列表頂部的中介軟體反而last在相應階段的最後運行。 所有,你需要確保UpdateCacheMiddleware排在任何可能往Vary頭部添加資訊的中介軟體之前。 下面的中介軟體模組就是這樣的:
- 添加 Cookie 的 SessionMiddleware
- 添加 Accept-Encoding 的 GZipMiddleware
- 添加Accept-Language的LocaleMiddleware
另一方面,FetchFromCacheMiddleware在要求階段運行,這時中介軟體循序執行,所以列表頂端的項目會首先執行。 FetchFromCacheMiddleware也需要在會修改Vary頭部的中介軟體之後運行,所以FetchFromCacheMiddleware必須放在它們後面。