MT3.2をapacheのハンドラとして動かす

MT3.2のユーザーインターフェースが秀逸だと聞いて、どうしても見たくなり、hori-uchi.comのMTを3.2へバージョンアップしてみました。


すると、数回アクセスすると、502 Proxy Errorが出るように。。

hori-uchi.comはフロントにApache2.0を置きここでhtmlなどの静的なコンテンツを処理し、バックエンドのapache1.3＋mod_perlでApache::Registryを使ったCGIのエミュレート環境でMovableTypeを動かしています。
バックエンドへのリクエストの受け渡しはmod_proxyを使って行っています。

この構成の構築方法は
Techknow Movable Type: Apache 2.0 mod_proxy によるリバース・プロキシの構築
に詳しく解説されています。


502のエラーが出たときのapacheのログを見ると、バックエンドは正常にレスポンスを返していますが、それを受け取るフロントがおかしなレスポンスだと判断し、502をクライアントに返しているようです。


そこで「MT3.2 mod_perl」でググってみると次のようなエントリが見つかりました。

Movable Type 3.2 User Manual: Running Movable Type With mod_perl

MT3.2のマニュアルの一部です。
内容はMT3.2をmod_perlで動かして高速化ってな話ですが、MTをapacheのハンドラとして動かしてより高速化するという内容まで書いてあります。
apacheのハンドラとして動かせばApache::Registryを使ったCGIのエミュレート環境より高速に動きますし、これで502のエラーもなくなるかもと思い、早速実践。


上記エントリの内容をそのまま実践しました。ただ一点、mt.cfgのCGIPathは
http://my.server.com/mt/でなく、http://my.server.com/mt/appにする必要がありました。
訂正：上記マニュアルの内容に加えて、mt.cfgに
>

AdminScript app

<
の一行を追加する必要がありました。


設定を完了し、apacheを再起動すると、MTの動作が高速なったうえ、502のProxyErrorもでなくなりました。めでたしめでたし。

でもなんでProxyErrorが出たのか納得のいく答えがわからず、ちょっと消化不良ぎみ。。

mod_perl + encodingプラグマでサイト全体が文字化け

perl5.8から導入されたencodingプラグマを利用してSTDOUTの文字コードを透過的にエンコーディングして出力するようなスクリプトをmod_perl環境で実行すると、encodingプラグマの影響がそれを実行したapacheプロセスに残ってしまい、それ以降に実行されるすべてのスクリプトもこの影響を受けてしまうようです。

仮にEUCでサイトを構築していた場合、
>

#!/usr/bin/env perl
use strict;
use encoding 'euc-jp', STDOUT => 'utf8';
print "Content-type: text/html; charset=utf8;\n\n";
print "こんにちは";

<
のようなスクリプトを実行してしまうと、このスクリプトを実行したApacheの子プロセスにおいて、それ以降のすべての出力がUTF8にエンコーディングされてしまい、結果サイトが文字化けしてしまうことになります。

mod_perl環境ではencodingプラグマは使用しないで、JcodeとかEncodeモジュールを利用するほうがよさそうです。

-Jcodeを使う場合
>

#!/usr/bin/env perl
use strict;
use Jcode;
print "Content-type: text/html; charset=utf8;\n\n";
print Jcode->new("こんにちは", 'euc')->utf8;

<

-Encodeのfrom_toを使う場合
>

#!/usr/bin/env perl
use strict;
use Encode;
my $str = "こんにちは";
Encode::from_to( $str, 'euc-jp', 'utf8');
print "Content-type: text/html; charset=utf8;\n\n";
print $str;

<

MT3.x+mod_perl環境でMTプラグインのロードに失敗するとエラーになる

結構前からなぜかmod_perl環境でMTが動かなくなってしまっていて、しょうがなくCGI環境で動かしていたんですが、どうにも遅くてやりきれないので、ちょっとMTのソースを追ってみました。

エラーの内容はこんな感じです。
>

Got an error: Can't call method "connection" on an undefined value at /path/to/mt/lib/MT/App.pm line 594.

<

App.pmの該当行ををみてみるとどうやら、apacheのリクエストオブジェクトが空のためエラーになっている模様。さらにソースを追ってみると、親クラスのMT.pmでのinitでこけていることが判明。そこでMT.pmにwarnを仕込んでデバッグしてみたところ、プラグインのロードに失敗した際に呼ばれるlogメソッドが原因だと判明しました。

MT.pmのinitメソッド内では、pluginのreiquireに失敗すると、$mt->logメソッドを呼び出すのですが、このlogメソッドはMT::App.pmで定義されたlogメソッドによりオーバーライドされています。
そのMT::App::logでは$mt->{apache}->connectionを呼び出しているのですが、$mt->{apache}はこの時点ではまだ生成されていないため、最初に書いたようなエラーがでていたのでした。

このエラーを回避し、プラグインのロードに失敗した際もMTが止まらないようにするためには、失敗した際に、$mt->logではなくMT::logを直接呼び出すように書き換えればOKだと思います。とりあえずパッチを書いてみました。

>

--- MT.pm.orig  Tue Jan  4 05:27:34 2005
+++ MT.pm    Tue Jan  4 05:27:42 2005
@@ -292,7 +292,7 @@
$plugin = $1;
eval { require $plugin };
if ($@) {
-                    $mt->log("Plugin error: $plugin $@");
+                    MT::log("Plugin error: $plugin $@");
return 0;
}
return 1;

<

mod_perl使用時はMaxClientsの値に気をつけましょう

導入するだけで既存のCGIスクリプトがお手軽に１０～２００倍高速になるmod_perlですが、mod_perl自体がサイズがでかいのと、高速化のため、モジュールをキャッシュするため、apacheのプロセスサイズが結構大きくなってしまいます。経験的にはだいたい１プロセスあたり２０～３０MByte位にはなります。このような性質上、mod_perlを使う場合はメモリの使用量を考えなくてはいけません。

ところで、Apacheのデフォルトの設定ではMaxClientsの値は１５０に設定されています。これは同時に最大１５０のリクエストをさばく、つまり最大１５０まで子プロセスを同時に生成するということです。仮に１５０個の子プロセスを生成するとすると、mod_perlを利用時の１プロセスのサイズをおよそ２０Mbyteとすれば２０×１５０＝３０００[MByte]＝３[GByte]のメモリを必要とすることになります。この場合、スワップ領域を含めてメモリの容量が３[GByte]に満たないサーバはすべてメモリを使い切り、最悪落ちることになります。

ということでほんとに落ちるかどうか実際に試してみました。
方法はApache付属のベンチマークツールabを使い同時アクセス数100、で1000回のリクエストを送るというものです。

ab -c 100 -n 1000 -k http://targetsite.hostname/

対象サーバのスペックはCPU：Pentium３の６００MHz、メモリ：５１２MByte、スワップ領域は１GByteです。

結果はというと、、abはタイムアウトで測定不能となりました（当たり前）。さらに、ab終了後のサーバにも問題が。。サーバが落ちることはなかったんですが、abはタイムアウトで終了しているのにめちゃめちゃサーバのレスポンスが悪くなってしまいました。sshでの接続にも数十分かかる始末。やっとの事でログインし、Apacheを終了させるとようやくレスポンスが生き返りました。

結論、mod_perlを使うときはMaxClientsの値に注意しましょう。Apacheのデフォルト設定で運用すると最悪サーバが落ちます。MaxClientsの値は「サーバのメモリ容量　/ Apacheの１子プロセスのサイズ」でおおざっぱに計算できます。今回試したサーバでは５１２/２０＝２５位に設定しておけば、メモリを使い切ってサーバが落ちる危険がなくなります。