3月29日に開催されたProNet勉強会「～MTの再構築を改善！～パフォーマンスチューニングとシステム構成の集中講座」に行ってきました。講師はSixapartシニアコンサルタントの柳下さんです。柳下さんはいろんなイベントでお話をしたことあるんだけど、素面の状態で名刺交換するのは初めてかもしれない、、、。
で、勉強会スタートです。参加者は15名程度で、セミナーと言うよりは名目通り勉強会という感じの雰囲気ですね、話の途中での質問もOKとのこと。置いてきぼりにされる心配もありませんぞ。
再構築に関するパフォーマンスのポイントは下記の4点とのことです。
・ウェブ／ブログサイトの設計（構成）
・テンプレートデザイン（MTタグ）と設定
・サーバスペック
・システム構成（サーバ分散）
で、私みたいなエンジニアだとすぐに後半のサーバスペックだとかシステム構成の話しに突入しがちなのですが、まずはもっとソフトウエア寄りというか、設計・設定よりの話しから始まります。
まず、『ウェブ／ブログサイトの設計』。これが重要なのは確かに理解していましたが、今まではパフォーマンスというよりは、単に構築上の問題で1つのサイトを複数のブログで構築する今年か考えていませんでした。当然ですが、再構築の観点から見れば「1つのサイトを複数のブログで構築」していれば、それぞれのブログに属するエントリー数も減るわけで再構築にかかる時間も短縮化されます。ただ、全ブログを再構築しなくてはいけないのでは全く意味がないので、そういう意味でのサイトの設計が重要になるという話しです。これは、単純な回答がある訳じゃなくて、サイト毎の特性を考えてどのような分け方ができるか等がポイントになりそうです。
ちなみに、MTのアーカイブの中でカテゴリーアーカイブの再構築が負荷がかかるみたいです。SQL的に考えると、なんかいまいち納得できなかったりするのですが、MTの設計上の問題としてとりあえず理解しておきました。で、カテゴリー毎でブログを立ち上げてカテゴリアーカイブを使わないというのが、最も効果があるとのことでした。
あと、当然ですが「不要なアーカイブは作成しない」というのも重要。ウェブサイトとして構築している場合、日付系のアーカイブは不要なことも多いですからね。ニュースリリースみたいなものだけ、ブログを分けるというのも手かもしれません。というか、MT5についてはサイトの作りがブログとページではっきり分かれているので、無駄にブログで構築しないというのも当然ポイントでしょうね。
次に、『テンプレートデザイン（MTタグ）と設定』。テンプレートタグの使い方で、いろいろなことが変わるのはわかっていますが、再構築のポイントとしては如何にDBアクセスを減らすと言うことが重要。MT4.2以降では、テンプレートモジュールのキャッシュやSSI設定ができるので、やってみるべきとのことでした。これ、全然知らなかった話しですが、MTIncludeのリファレンスにもキャッシュの項目やSSI設定の記載がありますね。ちなみに、テンプレートモジュールのキャッシュおよびサーバーサイドインクルードというページで詳しく解説されています。
また、toolsディレクトリ配下にあるmt-tmpl-testコマンドを使うと、テンプレートがどのような動きをするのか等の解析情報を見ることができるというハックも教えてもらいました。藤本さんのテンプレートの再構築状況を調べるmt- tmpl-testツールで詳しく解説されていますね。
設定でもう一つのポイントが「再構築オプションの見直し」。この点もこれまで全然意識していなかったのですが、再構築オプションで公開キューを選択しておくと、再構築を実行したタイミングではなくrun-periodic-tasksが実行されるタイミングで再構築されるとのことです。比較的優先度の低いアーカイブなどは、「公開キュー」に設定しておくことで再構築にかかる見た目の時間は削減されます。よくよく考えると、再構築全体にかかる時間が短くなる訳じゃないんだけど、優先度をちゃんと考えて設定することで再構築という動作そのものもいろいろ考え直すきっかけにもなりそうです。完全にコンテンツが同期しないといけないという考えを捨てて、アーカイブは後から勝手に再構築してくれるよと考えればいいのかもしれないですね。
あと、このrun-periodic-tasksですが、指定日投稿をしていない方は設定をしていない方も多そうですが（私もそのうちの一人）、実はMTのセッション情報などのDBを定期的にリサイズしたりする機能もあるらしくて（どこにもそんなこと書いてないけど）、是非設定をしておくべきとのことです。このブログも設定してないので、しておこう、そうしよう。設定の仕方は指定日投稿や公開キュー等のスケジュール処理の設定ページに書かれています。
試しにrun-periodic-tasksを実行してみたら、PostgreSQLのdumpデータが15MBも小さくなりました。こりゃー、ちゃんと設定しておかないといけませんね。
なんか、長くなっちゃったので、続きは下記のページでっす。