從一篇關於嘗試提高我的網站性能的文章中，我一直在研究HTTP壓縮。我已閱讀關於在IIS中設置它，但它似乎是所有IIS應用程序池的全局事物，我可能不允許這樣做，因爲還有另一個站點在運行。然後，我看到一些代碼放在global.asax中，以在每個網站的基礎上實現相同的事情。ASP.NET壓縮
See Herehttp://www.stardeveloper.com/articles/display.html?article=2007110401&page=1]1
這是因爲在IIS中設置爲好？效果如何顯着？任何已知的問題？
如果你繼續這樣做，我會建議實施一個HttpModule與global.asax。 HttpModule允許您通過配置更改與重建來禁用壓縮功能，並允許您將獨立於Web應用程序的壓縮程序集與猴子配合使用。
富起重機在這裏有一個相當不錯的2.0模塊：http://www.codeplex.com/httpcompression/如果你想快速起牀和運行。
blowery項目史蒂文羅傑斯提到的也是一個HttpModule。
否則，編寫自己的代碼非常簡單。 HttpModule爲您提供與global.asax相同的事件 - BeginRequest，EndRequest和PostReleaseRequestState和PreSendRequestHeaders等更細粒度的事件，您可能需要消除所有的皺紋。
就IIS壓縮verus HttpModule而言，IIS絕對容易一些，因爲您不必擔心另一個Assembly。我已經將這兩種方法與業務應用程序一起使用，並且都在負載測試下同樣執行。如果IIS可用，我會說使用它。
針對HTML，JS，CSS和XML文件的60％到80％壓縮對gzip來說很常見。請記住，您的許多有效負載可能是圖像和多媒體對象，這些對象很難壓縮。
我認爲如果您處於共享主機環境（例如，您無權訪問IIS配置）的情況下，Global.asax選項將非常有用。
IIS 6提供基本的壓縮支持，但如果你在IIS 7中是已經，它爲您提供了很大的支持HTTP compression，您可以定義哪些文件會根據他們的MIME類型的配置文件壓縮...
它實現了與IIS壓縮基本相同的功能 - 兩者最終都會使用gzip壓縮發送響應。我最近實現了這種方法，並且它始終將響應大小減少了60％，沒有性能影響值得擔心。
有幾個可能的問題。首先，你需要注意輸出緩存。您需要使用自定義的VaryBy來確保爲具有不同Accept-Encoding標頭的請求緩存不同的版本。否則，如果壓縮版本被緩存，則所有用戶都會收到它，無論他們的瀏覽器是否可以接受它。
其次，如果您使用Response.End或Response.Flush，GZipStream有時會截斷響應中的最後幾個字符，因爲流遲遲不會關閉。我不知道有什麼好的解決方案。
最後，這隻會壓縮你的HTML。任何CSS或Javascript文件將正常提供。例如，您需要通過自定義IHttpHandler來提供這些文件來壓縮它們。
http://blowery.org/httpcompress/
我們已經在我的工作了一段時間使用這個壓縮實用程序。非常好。
JavaScript和VBScript存在問題。 JavaScript問題已在codinghorror article的xxldaniel評論中得到確認，並且我使用帶有「Microsoft.XMLHTTP」請求的類似JSON的「Scripting.Dictionary」與VBScript（用於M $ Office自動化）有問題。
您可以嘗試mod_gzip模塊。它使用託管的ZLib版本並允許高度可調的配置。語法與同一個已命名的Apache模塊兼容，甚至可以擴展。因此，例如，您可以爲不同的MIME類型設置不同的壓縮級別等等。