今さらですがMTOS 4.23に乗り換えました

長らく使ってきたMT 3.21を捨てて、MTOS 4.23にとうとう乗り換えました。これで晴れてGPLなMTユーザの仲間入りです。

（相当カスタマイズして使ってきたので）苦行になるであろう移行作業の億劫さと、「MTOS使えやゴルァッ!!」的なことを言いながら旧バージョンを使い続ける後ろめたさ、のせめぎ合いをこれ以上はないというほど楽しませてもらいました（笑）

で早速なんですが、

MT 4.2xって超遅くね？よく使ってられるね？

特に全部スタティックに再構築するのにかかる時間が以前の環境に比べて2倍以上遅くなっています。

その責任の一端はTagSupplementalsプラグインにあります。TagSupplementalsプラグインのmt:RelatedEntriesブロックタグは、タグの共起行列をオンラインで生成するのでO(N²)の計算量が必要なのです。これに対して、tagwireプラグインはエントリーの保存時に計算を行っているので、再構築のオーバーヘッドがかなり抑えられています。いずれ何らかの形で対処するつもりです。

もう一つは、再構築の単位を定めるEntriesPerRebuildというディレクティブの意味が変わったせいというか、バグと解釈しても差し支えないような仕様が4.2あたりで導入されたせいです(changeset 1611)。

EntriesPerRebuildは、ブログ記事アーカイブの再構築する際に、セッションごとに処理するブログ記事数（デフォルトでは40）を指定するためのディレクティブですが、実はそれだけではありません。

月別ブログ記事リストを再構築する場合を例に挙げると、セッションごとに指定された個数のブログ記事に対応する月別ブログ記事リストを生成します。EntriesPerRebuildが40で、月20件のブログ記事を書いていたとすると、一セッションで平均2個ずつ月別ブログ記事リストが生成されるわけです^*1。3.x系の場合には、EntriesPerRebuildの10倍のブログ記事に対応する月別ブログ記事リストをセッションごとに生成していたので、平均20個ずつ生成されていました。いかに4.2になってからアーカイブの生成が非効率になったか分かるでしょう。

^*1 勘のいい人なら気がついたと思いますが、月40件を超えるブログ記事がある場合には、まったくアーカイブを生成しないセッションも発生します。

この問題は、EntriesPerRebuildの値を思い切って大きめに取ることで解決できます。私は400に設定し、かつMemcachedを併用することでまずまずの性能が得られています。

以下は手元の環境（本番機とは異なります）でこのブログを再構築するのにかかる時間を、EntriesPerRebuildを変えながら測定してプロットしたものです。

Rebuild times in MT 4.23 - Google ドキュメント

EntriesPerRebuildの増加による性能向上が400あたりで頭打ちになること、Memcachedを利用することで約50秒再構築時間が圧縮できることが分かるでしょう。ちなみに何も設定しない場合は206秒、EntriesPerRebuild 400でMemcachedを使った場合は101秒。再構築時間が半減できたことになります。