lighty の mod_compress について

This entry was posted by on Thursday, 19 July, 2007

www.jmuk.org は lighttpd でやってるけど、 lighttpd には mod_compress というのがあるのにいまごろ気付いた。というかあるのは知ってたけど単に Apache の mod_deflate と同じようなものだと思っていたのだが違うことに気付いた。

lighty の mod_compress では、最初にアクセスしてきたときにファイルを圧縮し、圧縮されたファイルをどこかローカルなディレクトリに保存する。そして次のリクエストには保存されたディレクトリを使いまわす。ようはhttp://www.onflow.jp/blog/archives/2007/06/javascriptcssdeflatecpu.htmlでやってるような機能を組込みで持ってると言うことができる。楽でいいよね。

しかも設定はわずか2行(+server.modules に mod_compress を追加する1行)。書くのは次の2行で、これは lighttpd.conf のテンプレートにある。

compress.cache-dir = "/tmp/lighttpd/cache/compress/"; compress.filetype = ("text/plain", "text/html", "text/javascript", "text/css")

なお cache-dir で指定したディレクトリは lighty を動かすプロセスで書き込み可能でなければならない(とーぜん)。

というわけでお手軽でいいですね、ということでおしまいなら良かったんだけど、残念ながら問題がある。

まず、上でリンクした先に書いてあるように、 Apache でこのテの処理をするには一部のブラウザを省くのが常道のようだ。一部のブラウザは Accept-Encoding に表示するくせに正しく処理できないらしい。ところが mod_compress の設定はサーバ全体に効くので、そういう設定が効かないわけだ。

いまどき Netscape の4系なんて使っている人がいるだろうかという気もするけど、けっこういる。PCももちろんあるけど PSP とか PDA とかで閲覧している方々だな。こういうアクセスを捨てるのは偲びない。ちなみにどれくらいいるかというと、

% cat /var/log/lighttpd.access.log | ruby -ne 'puts $_.split[0]' | uniq | sort | uniq | wc -l 4618 % cat /var/log/lighttpd.access.log | grep 'Mozilla/4' | grep -v '\bMSIE' | ruby -ne 'puts $_.split[0]' | uniq | sort | uniq | wc -l 37

ホスト名だと 0.8% くらい。下位8ビットを無視すると、

% cat /var/log/lighttpd.access.log | ruby -ne 'puts $_.split[0].split(/\./)[0,3].join(".")' | uniq | sort | uniq | wc -l 1852 % cat /var/log/lighttpd.access.log | grep 'Mozilla/4' | grep -v '\bMSIE' | ruby -ne 'puts $_.split[0].split(/\./)[0,3].join(".")' | uniq | sort | uniq | wc -l 27

1.5%くらいだ。この割合をどう考えるかによるけど、やっぱ気にはなる。

あとそれから、 mod_compress には不要なファイルを削除する機能がなく、ファイルごとに圧縮するしないを判断することもできない(上の設定のように mime-type で圧縮するしないの設定はできる)。とにかく問答無用に圧縮ファイルを作成するから容量は増大し続けると考えられるので、何らかのスクリプトでたまに削除するといった手間がかかる。 Apache の mod_deflate と違って、その場で(メモリ内で)圧縮してファイルに残さない動的圧縮もできない。

てことで、こういったのを解消するために mod_deflate というのが新しく用意されていて、こっちだとそういった処理は可能なようだ(ユーザエージェントは $HTTP["useragent"] で取得できるから、マッチさせて deflate.enabled をスイッチすればいいのだろう)。ただ現在の stable である lighttpd 1.4.x にはなく、先端の 1.5.x にしか存在していない。 1.4.x の lighttpd で使う場合はパッチを充てる必要があり、いささか面倒くさい。

そういうわけで今いきなりこれを使っていいものかちょっと悩んでるところ。とりあえず問題がありそうなのがどれくらいあるかというのが気になるので、アクセスログに Accept-Encoding を書き出すようにしてみた。問題ありそうなクライアントが Accept-Encoding を使ってないようなら、楽でいいんだけどね。

Comments are closed.