サイトのパフォーマンスを向上させる試みに関する以前の投稿から、HTTP 圧縮について調べてきました。IIS での設定について読んだことがありますが、それはすべての IIS アプリケーション プールにとってグローバルなことのようです。別のサイトも実行されているため、これを行うことは許可されていない可能性があります。次に、web サイトごとに同じことを達成するために、global.asax に入れるコードを見ました。
ここを参照 http://www.stardeveloper.com/articles/display.html?article=2007110401&page=1] 1
これは IIS のセットアップと同じくらい良いですか? その効果はどれほど劇的ですか？既知の問題はありますか?
これを進める場合は、HttpModuleとglobal.asaxを実装することをお勧めします。HttpModuleを使用すると、構成を変更して再構築するのではなく、圧縮を無効にすることができ、Webアプリとは別に圧縮アセンブリを使用することができます。
Rich Craneには、非常に優れた2.0モジュールがあります：http ：//www.codeplex.com/httpcompression/起動して高速に実行したい場合は、
スティーブンロジャースが言及したブローリープロジェクトもHttpModuleです。
そうでなければ、あなた自身を書くことはかなり簡単です。HttpModuleは、global.asaxと同じイベント（BeginRequest、EndRequest、およびPostReleaseRequestStateやPreSendRequestHeadersなどのより細かいイベント）を提供します。これらのイベントでは、すべてのしわを取り除く必要があります。
IIS圧縮とHttpModuleに関する限り、IISは、さらに別のアセンブリに煩わされる必要がないため、間違いなく簡単です。私はビジネスアプリで両方の方法を使用しましたが、どちらも負荷テストでほぼ同等に機能します。IISが利用可能な場合は、それを使用すると思います。
HTML、JS、CSS、およびXMLファイルの60〜80％の圧縮は、gzipで一般的です。ペイロードの多くは、圧縮がはるかに難しい画像やマルチメディアオブジェクトである可能性があることに注意してください。
http://blowery.org/httpcompress/
仕事でこの圧縮ユーティリティをしばらく使用しています。かなり良い。
JavaScriptとVBScriptに問題があります。JavaScriptの問題は、 codinghorrorの記事に対するxxldanielのコメントで確認されており、JSONのような「Scripting.Dictionary」と「Microsoft.XMLHTTP」リクエストを使用したVBScript（M $ Officeオートメーション用）で問題が発生しました。
IIS 圧縮と本質的に同じことを実現します。どちらも最終的には gzip 圧縮で応答を送信します。私は最近この方法を実装しましたが、心配する価値のあるパフォーマンスへの影響なしに、一貫して応答サイズを 60% 削減しています。
考えられる問題がいくつかあります。まず、出力キャッシュに注意する必要があります。カスタム VaryBy を使用して、異なる Accept-Encoding ヘッダーを持つリクエストに対して異なるバージョンがキャッシュされるようにする必要があります。それ以外の場合、圧縮されたバージョンがキャッシュされると、ブラウザーが受け入れられるかどうかに関係なく、すべてのユーザーがそれを受け取ります。
次に、Response.End または Response.Flush を使用すると、GZipStream は応答の最後の数文字を切り捨てることがあります。これは、ストリームが手遅れになるまで閉じられないためです。私はこれに対する良い解決策を知りません。
最後に、これは HTML のみを圧縮します。CSS または Javascript ファイルは通常どおり提供されます。たとえば、これらのファイルを圧縮するには、カスタム IHttpHandler を介してこれらのファイルを提供する必要があります。
たとえば、IIS 構成にアクセスできない共有ホスティング環境にいる場合は、Global.asax オプションが適していると思います。
IIS 6 は基本的な圧縮サポートを提供しますが、既に IIS 7 を使用している場合は、優れたHTTP 圧縮サポートを提供します。構成ファイルの MIME タイプに基づいて圧縮するファイルを定義できます...