2005-03-12  Movable Typeいまさら大問題

こんばんは，yumi-ii/area_muronoをMovable Typeに移行する作業をしておりました。移行作業はローカル環境による「模擬」と，リモート環境による「本番」に分けています。模擬環境の構築中に実時間で処理できない問題が発生してしまい，このままでは導入判定を通過できそうにありません。いまさらですが大問題なのです。

件数が増えると読み出しが困難に

Movable Typeでは，外部ファイルをBLOGに取り込むことができます。この機能を「エントリーの読み出し」と言います。ひとつのエントリーはひとつの記事に対応します。エントリーの数が記事の数となるわけです。

yumi-ii/area_muronoのエントリー数は，だいたい1,800です。Movable Type上にそっくり構築するには，1,800件のエントリーを読み出さなければなりません。最初，私は何のためらいもなく1,800件を読み出してみました。すると200件ほど読み出したあとに，WWWサーバがタイムアウトしてしまいました。

タイムアウトしても，途中まで読み出したエントリーは消えずに残ります。つぎに追加（2回目）で読み出せたのは130件でした。3回目は70件でした。4回目は64件，5回目は42件でした。合わせて800件ほどを読み出したあとには，一度に28件しか読み出せなくなっていました。

どうもエントリーの数が増えれば増えるほど，読み出しに掛かる処理量が増えてしまうようなのです。タイムアウトの時間は一定なので，一度に読み出せるエントリーの数がどんどん少なくなってしまうのです。

この調子では残りの1000件を読み出すのは，まず無理です。どうもDBの性能が足を引っ張っているように見えるので，DBを変えればいくらか改善できるのかもしれません。いまはBerkeley DBを使っています。Movable TypeではBerkeley DB以外のDBも使えるので，ほかのDBに変えてみることにします。DBを変えてもスループット（単位時間あたりの処理量）が改善しない場合は別の作戦（それが何であるか定かではない）を考えなければなりません。

再構築に時間が掛かる

エントリーを読み出しただけでは，HTMLファイルはまだ作成されません。Movable Typeではこのあと「再構築」という処理をすると静的なHTMLファイルが作成されます。（余談ですが，「ダイナミック・パブリッシング」という動的な生成機能もあります。）

この再構築なのですがとっても時間が掛かります。タイムアウトすることはないものの，エントリーの件数が増えるとどうなるのか心配なところです。

長期運用性が不明

環境を移してしまったあとの話です。エントリーの数はこれからどんどん増えていきます。これから5年以内にエントリー数は3,000件を超えてしまうでしょう。試してみなければ分からないことですが，Movable Typeがそれだけの件数を裁けるのか怪しい気がします。

ともかく，ほかのDBの効果を検証してみてやっぱり実時間で処理できないなら（MySQLを試してみるつもり），当分のあいだ頭を抱え続けることになりそうです。