【帯域対策】Apacheのモジュールmod_deflateで転送量を大幅削減！

Apacheのモジュール、mod_deflateを利用して転送量を軽減させて転送量対策します。
このモジュールは転送前にコンテンツをgzipにて圧縮転送する事で転送量の減少を計ります。
圧縮されたコンテンツはクライアントのブラウザにて展開されて表示されます。



導入に際して、本当にこのモジュールが自サイトに適しているものかを考える必要があります。
なぜなら、圧縮する度にCPU消費する事になり、結果CPU消費率は上がるからです。
CPUの使用率は余裕があるが、帯域はできるだけ抑えたい場合等には最適でしょう。

しかし、低速な回線などの場合に100kbのhtmlファイルを転送すると
転送が終了するまでその接続はCPUを占有します。
こうした場合はmod_deflateにて圧縮を行う事で結果的に低速な回線の使用者が
CPUを占有する時間が短くなり、CPU消費率は変わらずに
転送量の削減と体感レスポンスがアップ！といった素晴らしい事になることもあります。

アクセスログ等を使用したり、自サイトのコンテンツと照らし合わせて
使用するか否か。またはどのように設定していくかをよく考慮した上で使用すると
非常に効果を発揮するモジュールです。

テキストは圧縮された場合のサイズが圧縮前と大きく差がある為、
テキスト中心のサイトには最適なモジュールだと思います。

mod_deflateの組み込みを確認

このサイトのApacheのインストール方法でApacheのインストールを進めていただけたなら
すでにApacheのモジュールとして組み込まれています。

/usr/local/apache2/conf/httpd.conf

にて以下の行がある事を確認してください

LoadModule deflate_module modules/mod_deflate.so

まだモジュールのインストールがされていない場合は場合によってはApacheの再コンパイルが必要かもしれません。
また、動作実験はApache2.2.13にておこなってみました。

/usr/local/apache2/conf/httpd.confにて設定をする

httpd.confに以下のように設定してみました。

SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI\.(?:gif|jpe?g|png)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary

追記が終わったらapacheの再起動します。

(2009/12/09日追記！)
コメントより、SetOutputFilter DEFLATEで全てを指定しているのだから
AddOutputFilterByTypeは必要ないのでは？と指摘を頂きました。
実際にその通りで、希望通りに動く事は間違いないのですが、
二重で指定してる事になりまったく意味のない設定になっていました。
コメントで指摘して下さった匿名様、ありがとうございます。

/usr/local/apache2/bin/apachectl restart

SetOutputFilter DEFLATEの部分

圧縮を有効にします。

BrowserMatchの部分

ブラウザによって圧縮をするか、しないかの判別を行っています。
IEやFireFox等の主要なブラウザは当然のように対応していますが、
圧縮されたコンテンツを解凍できないブラウザの場合は
文字化けしてしまう、など、うまくページを表示できない不具合が出てしまいます。

ですのでこの部分で　IEとMozilla系のみ圧縮を行うよう設定しています。

SetEnvIfNoCaseの部分

ここではjpg png gifの画像ファイルの場合は圧縮しない設定をしています。
jpg png gifはもともと圧縮されていて、圧縮しても数バイトほどしか減らない事が多く
その数バイトの為に圧縮する為のCPUリソースを割り当てる事は非常に非効率だからです。

動作の確認

実際にgzip圧縮にて転送が行われているかを確認します。
firebugなどのアドオンとYSlow等のアドオンを組み合わせ、
実際にどれくらい転送量が減ったを確認してみました。

gzip前


総転送量207KB　（９２KBはキャッシュから ）
メインのindexファイルが96KBもあります。
(時間はレスポンス待ちのタイムがほとんどなので今回だけここまで遅かった感じですｗ)

gzip後


総転送量127KB　（９２KBはキャッシュから ）
メインのindexファイルが96KBから17KBまでに削減され、転送量が大幅に減りました。

参考までに、同時アクセス100人ほどの状態で、このモジュールをON、OFFしてみた時の
転送量の違いです。



モジュールをOFFした18時40分くらい？から２倍近くに転送量が増えました。
その後、19時10分くらいにモジュールをONする事で1/2以上転送量が下がっています。

その時のCPU


ONにした瞬間100％超えてます…
しかしその後はだんだんと下がってきてますね。
１日使ってみましたが、このモジュールによってCPU負荷が高い！という状況にはなってないです。
(圧縮対象のファイルが少ないからかもしれません)

キャッシュ等とうまく組み合わせる事で除々に最適化していくといいと思います！

問題と対策

実際に使用してみたところ、
画像まで圧縮されている！といった現象を確認しました。

よく調べてみると、静的な画像ファイルは圧縮は行われていませんでしたが
動的に画像を表示している場合は圧縮されちゃっている事が確認できました。

動的に画像を読み込むようなサイトの場合、
そのプログラムに、すでに何らかのヘッダが出力されており
MIME/Typeによらず強制的に圧縮させられるという事が原因のようです。

これはプログラム側のHTTPヘッダを出力をいじくる事で解決できました。
テストで使用していた環境はpukiwikiの1.4.7なのですが、
pukiwikiの場合は、画像を表示させるプラグインである
ref.inc.phpにヘッダを出力する部分が存在していたので
ここに

header(‘Content-Encoding: none’);

のように明示的にnoneとする事で、deflate側で正常に画像と認識されて
非圧縮状態となりました。

参考

参考にさせていただきました
http://blog.katsuma.tv/2007/07/yslow_apache_mod_deflate.html