IIS 7.0での動的圧縮の設定

以降の各バージョンのインターネットインフォメーションサービス（IIS）では、出力のキャッシュと圧縮を制御するためのオプションが増えています。たとえば、IIS 7.0が最初にインストールされると、圧縮された静的ファイルは既定で有効になり、動的に生成されたファイル圧縮は無効になります。特に.ASPまたは.ASPX Webページは無効になります。したがって、動的に生成されたコンテンツの圧縮にはいくつかの問題がある可能性があるため、IIS 7ではこの機能を手動で有効にする必要があります。 IIS 7.0での変更により、静的コンテンツはデフォルトで圧縮されるようになり、プロセッサの効率が向上しました。動的圧縮を使用するときに設定できるオプションの1つは、プリキャッシュ動的圧縮と呼ばれるASP.NETアプリケーションディレクティブです。これは、urlCompression要素の一部です。 urlCompressionを使用して静的および動的圧縮を設定することもできますが、ほとんどの場合は、アプリケーションのIISコントロールパネルからしか設定できません。したがって、キャッシュ前の動的圧縮オプション（または単にForeCache）では、IISが動的に生成されたコンテンツをどのように圧縮してキャッシュするかについて説明します。このオプションの値をTRUEに設定すると、コンテンツが生成され、圧縮され、キャッシュに追加されてから、キャッシュからクライアントに順番に出力されます。値がFALSEに設定されている場合、生成されたコンテンツフォーマットは圧縮されず、要求を受信した後に再圧縮されます。 BeforeCacheをTRUEに設定するのは良い考えのようです。動的に生成された同じコンテンツの多くを圧縮する必要がある場合は、それらを1回圧縮してから複数回圧縮するのが合理的です。あなたは多くの帯域幅と多くのCPUサイクルを節約するでしょう。ただし、場合によってはBeforeCacheが機能せず、説明する必要があります。まず、BeforeCacheに対するMicrosoftのコメントによると、「出力キャッシュのレスポンスが更新されると、レスポンスが出力キャッシュに入るまで動的圧縮は実行されません」。 'つまり、専用の出力キャッシュ処理方法を使用しているサイトでは、期限切れのコンテンツを提供したり、他のユーザー向けにカスタマイズしたコンテンツをユーザーに提供するなど、BeforeCacheの使用時に問題が発生します。もう1つ注意すべきことは、さまざまな種類の圧縮がキャッシュ機能にどのように影響するかです。 IIS 7.0は、GNU圧縮とdeflate圧縮をサポートしています。これらは、ネットワーククライアント圧縮の2つの一般的な種類です。さらに、これらはより確実に実行されるようになり、IIS 5.0では圧縮処理が失敗したようです。クライアントが受け入れるコードを明示的に指定していない場合や、アプリケーションが異なる方法でエンコードされたページ要求を処理できない場合は、状況が複雑になる可能性があります。最後に、Webページは自動的にキャッシュされません。代わりに、IISは頻繁に要求されるコンテンツを自動的にキャッシュします。デフォルトでは、10秒以内に2回以上要求されるページは、FrequentHitThresholdおよびFrequentHitTimePeriodサーバーパラメータで制御されるため、このタイプのページです。 Webページが5分ごとに要求されても、自動的にキャッシュされません。システム上でキャッシング機能をテストしているが、当初はキャッシュを起動するための適切な負荷が生成されていませんでした。