Movable Typeの再構築の出力制御について
ご存知の方も多いと思いますが、Movable Type で再構築（スタティックパブリッシング）を行った時、指定したすべてのファイルは無条件に出力されない仕様になっています。
例えば、すべてのインデックステンプレートで、「再構築オプション」をチェックしている状態（4.15以降であれば「スタティック」を選択）で、再構築画面から「すべてのファイル」または「インデックスのみ」を指定して再構築した場合、スタイルシートやJavaScript（mt.js）を最近編集していないのであれば、それらのファイルのタイムスタンプは更新されません。
極端な条件にすると、ブログ記事やテンプレート、あるいはコメント・トラックバックなど、前回の再構築からブログの情報が全く変更されていない状態で、再構築画面から「すべてのファイル」を選択して再構築を行っても、ファイルはひとつも出力（更新）されません。
この仕様に、最近まで全く気がついていませんでした。
レンタルサーバやローカルPCのタイムスタンプを確認しましたので、おそらく間違いはないと思いますが、認識誤りがありましたらご指摘ください。
１．ファイルが出力される条件
再構築でファイルが出力される条件を示します。
ソースをトレースすれば明確な条件が分かると思いますが、時間がないので（というかトレース能力が低いので）再構築を実際に行って、確認した限りの内容です。
- テンプレートを編集した場合
- 変更した情報に関連するテンプレートタグがテンプレートに記述されている場合
- 管理画面からファイルの出力内容に関係する設定の変更が行われた場合
- 再構築対象のファイルがなくなっている場合
２．各条件の詳細
1番目の条件は自明ですが、テンプレートの内容に変更があった場合、対象のテンプレートを再構築することによってファイルが出力されます。
2番目の条件は、例えば、コメントを投稿（公開）したときに、「最近のコメント」といったコメント関連のテンプレートタグが存在するテンプレートだけが再構築対象になります。逆に、コメント関連のテンプレートタグが存在しないテンプレートは再構築対象になりません。
3番目の条件は、例えば、ブログ記事編集画面でコメント・トラックバックの受信設定を変更した場合、そのブログ記事の内容を変更していなくても、コメントフォームやトラックバックURLの表示が変わるため、保存によって再構築され、ファイルが出力されます。
4番目の条件は、テンプレートの変更や該当するテンプレートタグがなくても、ファイルが何らかの要因でなくなってしまった場合は再構築されます。これはパスやファイル名が変更されたときも同じと思われます。
３．ファイルを出力したい場合
プログラムをハックすれば出力できる手段があるはずですが（または環境変数）、管理画面上で簡単に全てのファイルを再構築するには、テンプレートで共通に呼び出しているテンプレートモジュールを適当に編集してから再構築するのが無難ではないでしょうか。
４．再構築の最適化
テンプレートタグの有無で再構築が制御できることが間違いないのであれば、部品を単純にインクルードするよりも、コメントやトラックバックなどの特定テンプレートタグをモジュール化することで、再構築時間はより短縮できると思います。
4.15のSSIを用いれば、独自にPHP化せずにそのようなことが実現可能かもしれません。
５．再構築の定義
ふと思ったのですが、画面上再構築は行われているのに、仮にファイルがひとつも出力されない場合は「再構築」という表現は正しいのでしょうか（単に素朴な疑問です）。
内部処理では再構築するためのチェックが行われていると思いますし、それを含めて再構築（処理）と定義するのかもしれませんが...。
一括再構築は別として、例えば、個別再構築の場合「前回から変更がなかったのでファイルは更新されませんでした」というメッセージ出力も可能な気がします。
すいません。ちょっと疲れてます。
Movable Type 3.2-ja-2 再構築のパフォーマンス
以前エントリーした Movable Type 3.3b1-ja 再構築のパフォーマンスの後、「3.2の測定もして欲しい」というリクエストがありました。遅くなりましたが本エントリーで測定結果をお知らせします。相変わらず目分量です。
実行環境等は下記の通りです。
- OS：Windows XP Service Pack 2（Pen4 2.8GHz メモリ1.5GBで700MBほど使用中）。自宅サーバです。
- Perl：5.6.1
- DB：MySQL/SQLite
- 再構築対象：エントリー・アーカイブ
- 利用テンプレート：小粋空間3.2テンプレートのエントリー・アーカイブテンプレートを用い、再構築時間に影響があると思われる「最近のコメント *1」「カテゴリーリスト」「サブカテゴリーリスト」をいずれかひとつ設定。その他（カレンダー・最近のエントリー・最近のトラックバック・月別アーカイブ）のリストは常に設定。
- エントリー：約1000
- コメント：約7000
- トラックバック：約2500
- カテゴリー：103
以下、測定結果です。
１．エントリー・アーカイブの再構築時間
数値は最初の120エントリー（40エントリー×3）の平均を元に算出しています。
| MySQL | SQLite | |
|---|---|---|
| 最近のコメント | 18s/40エントリー | 22s/40エントリー |
| カテゴリーリスト | 24s/40エントリー | 124s/40エントリー |
| サブカテゴリーリスト | 33s/40エントリー | 227s/40エントリー |
| 上記リストなし | 18s/40エントリー | 22s/40エントリー |
２．CPU使用率
再構築中は常にほぼ100%。ただし「SQLite+リストなし」のみ96?97%でした。
３．メモリ使用率
再構築時間に比例して増加することはありませんでした（再構築単位でリソースが解放されている模様）。
*1 MTEntries に lastn属性値5を追加しています。lastn 属性を設定しない場合、1エントリーの再構築に30s以上かかるようです（MySQL・SQLiteとも）。
Movable Type 3.3b1-ja 再構築のパフォーマンス
このサイトのバックアップデータを利用して Movable Type 3.3b1-ja の再構築時のパフォーマンスを測定しました。測定といっても目分量ですが。
実行環境等は下記の通りです。
- OS：Windows XP Service Pack 2（Pen4 2.8GHz メモリ1.5GBで700MBほど使用中）。自宅サーバです。
- Perl：5.6.1
- DB：MySQL/SQLite
- 再構築対象：エントリー・アーカイブ
- 利用テンプレート：小粋空間3.2テンプレートのエントリー・アーカイブテンプレートを用い、再構築時間に影響があると思われる「最近のコメント *1」「カテゴリーリスト」「サブカテゴリーリスト」をいずれかひとつ設定。その他（カレンダー・最近のエントリー・最近のトラックバック・月別アーカイブ）のリストは常に設定。
- エントリー：約1000
- コメント：約7000
- トラックバック：約2500
- カテゴリー：103
以下、測定結果です。
１．エントリー・アーカイブの再構築時間
数値は最初の120エントリー（40エントリー×3）の平均を元に算出しています。
| MySQL | SQLite | |
|---|---|---|
| 最近のコメント | 22s/40エントリー | 35s/40エントリー |
| カテゴリーリスト | 27s/40エントリー | 147s/40エントリー |
| サブカテゴリーリスト | 38s/40エントリー | 270s/40エントリー |
| 上記リストなし | 19s/40エントリー | 23s/40エントリー |
２．CPU使用率
再構築中は常にほぼ100%。
３．メモリ使用率
再構築時間に比例して増加することはありませんでした（再構築単位でリソースが解放されている模様）。
*1 MTEntries に lastn属性値5を追加しています。lastn 属性を設定しない場合、1エントリーの再構築に30s以上かかるようです（MySQL・SQLiteとも）。
Movable Type で再構築エラーになる場合の原因と対処
Movable Type 3.2-ja-2 で再構築エラーに関する質問を頂くことが多いので、本エントリーにまとめました。
１．エラー現象
「再構築エラー」とは、主に下記の現象を指します。- 500エラーが表示される
- テンプレート内で MTLink タグを使用していると、そこでエラーとなる（場合がある）
いわゆる「500エラー」とは、 Internal Server Error つまり内部サーバエラーのことで、CGI等のプログラムが何らかの理由で実行できない、あるいはプログラムにエラーがある場合に発生します。
MTLink タグのエラーも500エラーと同様で、MTLink タグのエラーに見えるのは、たまたまそこでエラーメッセージを表示できる実装になっているからではないかと推測しています。
２．再構築エラーの原因
Movable Type で再構築エラーが発生する原因としては、これまで頂いたご質問を集計すると、- Movable Type の DB に BerkeleyDB を使用
→ BerkeleyDB はお手軽ですがパフォーマンスに難があります - エントリー・アーカイブの再構築単位
→ デフォルトの再構築単位は40（エントリー）ですが、この値では再構築エラーになる確率が高いです - エントリー・アーカイブの「最近のコメント」で recently_commented_on を利用している
→ lastn 属性を使用しない recently_commented_on 属性の使用はメモリ消費量が増大します
によるものがほとんどのようです。
そしてこれらを誘発する原因として下記が考えられます。
- サーバのパフォーマンス
- サーバのメモリ量
よくある例として、複数名で共有しているレンタルサーバが考えられます。このケースでは CPU やメモリ等の事実上のスペックは、マシンを占有する人数や使用頻度に反比例して低下していきます。故に再構築の成功率も同時に低下することになります。
また上記の要因が複合すれば再構築エラーが発生する確率はさらに高くなります。
３．エラー解消方法
とりあえず目前のエラーを回避する方法と、本格的な対処の2通りを紹介します。３．１ とりあえず回避する
- デフォルトテンプレートに戻す
デフォルトテンプレートの状態であれば再構築時のエラーはほぼ皆無という認識です。理由は次の内容をご覧ください。 - エントリー・アーカイブのサイドバーを削除してみる
例えば、当サイトの公開テンプレートとデフォルトテンプレートとの大きな違いは、アーカイブページのサイドバーの有無です。公開テンプレートのアーカイブ・テンプレートにはサイドバーにリスト類（カレンダー・最近のエントリー/コメント/トラックバック・カテゴリーリスト・月別アーカイブリスト）を色々と表示しており、その分、MTタグからHTMLマークアップを生成する時間が増加し、結果的に再構築時間に影響を与えることになります。つまりサイドバーにリスト類を表示している場合、それらを全てなくすことで再構築時間を短縮することができます。
なお、再構築エラーは前述の通り複合的な要因で発生します。公開テンプレートでアーカイブテンプレートのサイドバーに情報を表示すること自体についてはテンプレートのバグではありません。その点誤解なきようお願い致します。
３．２ 本格的な対処
対処しやすい順番に並べています。- 再構築単位を少なくする
mt-config.cgi の下記の部分を
から# EntriesPerRebuild 40
に書き換えます。10でもエラーになる場合は値をさらに小さくしてください。かなりの方がこれで解消されています。EntriesPerRebuild 10
3.3 では mt-config.cgi にこの設定自体がなくなっていますので新たに追加してください。
- rebuild支援ツールを利用する
再構築を部分的に行うためのツールです（プラグインではありません）。
rebuild支援ツール for MovableType
- DB を MySQL または SQLite または PostgreSQL に移行する
パフォーマンスに問題のある BerkeleyDB の使用をおやめになることを強く推奨します。SQLite の移行方法については、Movable Type + SQLite を参照ください。
MySQL自体の性能は高いのですが、ひとつのDBを多くのユーザでシェアしている場合は解消されないかもしれません。心配な場合はレンタルサーバのサポートに確認してください（自宅サーバ+MySQLはかなり快適です）。PostgreSQL については MySQL と同等とお考えください。
ロリポップの場合は SQLite への移行をお勧めします。
- PHPモジュール化を行う
サイドバーのリスト類をモジュール化（部品化）することで再構築時のパフォーマンスが向上します。ただし、ページ閲覧時に PHP が起動するため、アクセスの多いサイトでの CGI版 PHP の利用は 503 エラーを誘発する可能性があります。PHP モジュール化を行う場合は「条件付きGET」を有効にしてください。関連記事：
Movable Type の PHP化（その1）
PHPモジュール化の仕組みについて
HTTP/1.1 の「条件付きGET」を利用して PHP ファイルアクセスによるサーバ負荷を削減する
PHP における「モジュール版」と「CGI 版」の比較 + WordPress の適用例
- ダイナミックパブリッシングにする
ページを毎回動的に生成する方法です。静的なファイルを作らないため再構築時間が劇的に縮小します。関連記事：
Movable Type の再構築を不要にする「ダイナミック・パブリッシング」（その1：概要）
Movable Type の再構築を不要にする「ダイナミック・パブリッシング」（その2：設定方法）
- サーバを変更する
レンタルサーバもピンキリで、最終的にはサーバや DB のパフォーマンスに依存します。何をやっても事象が好転しない場合はこれをお勧めします。
2006.04.28 追記
rebuild支援ツールとダイナミックパブリッシングを追加しました。
2006.06.20 追記
文言等修正。
