在IIS 7.0中配置動態壓縮
互聯網信息服務（IIS）的每個后續版本都會引入更多的選項來控制輸出的緩存和壓縮。比如，IIS 7.0***安裝時會默認啟用壓縮靜態文件，而禁用動態產生的文件壓縮功能，尤其是.ASP或者.ASPX網頁。
推薦專題：IIS服務“講武堂”
因此，這個功能必須在IIS 7.0中手動啟用，因為壓縮動態產生的內容可能會出現幾個問題。由于IIS 7.0的某些變化，靜態內容現在是默認壓縮的，這讓處理器的壓縮效率更高。
使用動態壓縮時，可以設置的選項之一是一個叫做緩存前動態壓縮的ASP.NET應用程序指令，它是urlCompression元素的一部分。請注意，你也可以通過urlCompression來設定靜態和動態壓縮，但是絕大多數時間你只能通過應用程序的IIS控制面板來設定。
所以緩存前動態壓縮選項（或者簡稱BeforeCache）描述了IIS如何壓縮并緩存動態生成內容。當把這個選項的值設成TRUE時，內容會被生成、壓縮、添加到一個緩存，然后按順序從該緩存輸出到客戶端。當把值設成FALSE時，生成的內容格式不是壓縮的，得到請求之后再重新壓縮。
把BeforeCache設成TRUE似乎是一個好主意。如果你需要壓縮許多相同的動態生成內容，把它們提前壓縮一次然后再多次使用還是有意義的。你會節省大量的帶寬以及大量的CPU周期。不過，在有些情況下BeforeCache不會起作用，應該加以說明。
首先，根據微軟對BeforeCache的評論，“當輸出緩存響應刷新后，在該響應進入輸出緩存之前動態壓縮不會執行。”這就意味著那些擁有專用輸出緩存處理方式的網站在使用BeforeCache時可能會出現問題，比如說提供過時內容、或者給一個用戶提供其他用戶的定制內容等。
另一件需要注意的事情是：不同類型的壓縮形式對緩存功能會有什么樣的影響。IIS 7.0支持GNU壓縮和deflate壓縮，它們是兩種常用的網絡客戶端壓縮類型。此外，他們現在的運行更可靠，在IIS5.0中，壓縮活動明顯失敗。當一個客戶端沒有明確指定它可以接受什么代碼時，或者當你的應用程序不能處理不同編碼的頁面請求時，事情會變的很復雜。
***，網頁不會自動緩存。相反，對于那些頻繁請求的內容，IIS會進行自動緩存。默認情況下，10秒鐘內請求兩次或者兩次以上的網頁都屬于這種類型，就像frequentHitThreshold 和 frequentHitTimePeriod服務器參數控制的那樣。如果一個網頁每隔五分鐘才請求一次，那么它將不會被自動緩存。如果人們正在一個系統上測試緩存功能，但是開始的時候他們沒有生成合適的負載來激發緩存。
【編輯推薦】
