MTの500エラー改善の経過報告と再構築時間改善方法等を教えてもらいました
みなさん、こんにちは、まーしーです
先日、500エラーに対応中 という記事を書いたら各所で色々教えていただきました。
どうもありがとうございます。この場を借りてお礼を述べさせてもらいます。
先日の記事でも紹介した
Six Apart - Movable Type アップグレード 秘話ブログ - :GIZMODO JAPAN編 - :第三話 MT4高速化しよう！講座の巻
http://www.sixapart.jp/promotions/upgrade/gizmodomovable_type_03.html
でも教えていたSix Apartの柳下さんから改善の方法や日々の確認方法を教えていただきました。
ちなみに、CGIの実行時間を延ばしてもらった効果が出ているのか前回以降500エラーは出ていないような感じです。
まず、改善するに当たっての３分類は
- Movable Type
- Apache
- DataBase
ということでした。
Movable Typeの部分もわかっていないことが多いのですが、Movable Type部分で教えてもらってもらったことをまとめてみようと思います。
Movable Type周りを改善する
Movable Type周りについて出来ることをとりあえず羅列してみます。
- mt-config.cgiをきれいにする
- デバッグモードにする
- 使っていないプラグインを外す
- カテゴリーを使わず、Blogを分割する
- SSIを使う
- 公開キューを設定する
- MTのアクティビティログを見る
- mt-tmpl-testを使う
- パフォーマンスログを見る
- FastCGIを使う
ではそれぞれについて見ていきましょう。
mt-config.cgiをきれいにする
どのくらい効果があるのか、ちょっとわかっていないところでもありますが。
きれいにしておいて損はないですね。
デバッグモードにする
これはデバッグ用のメッセージを見るための設定ですね。
DebugMode | 環境変数リファレンス
http://www.movabletype.jp/documentation/appendices/config-directives/debugmode.html
これらの値を
DebugMode 1
のような感じで、mt-config.cgiに記載しておきます
恥ずかしながら今まで知りませんでした。
お客さんが使用するMTで設定するわけにはいかないですが、
自分で使用する場合は見ておくとよいかもしれません。
使っていないプラグインを外す
MTをインストールするとプラグインがいくつか入っていますよね。
どのプラグインがどの様に必要なプラグインか判断して、不要なモノを削除してしまいましょう。
例えば
WXR Importer 1.1
「WordPressからエクスポートされたRSSをMTにインポートします。」
ということなので、Wordpressから入れないのであれば不要ですね。
SpamLookup
スパムをはじくためのプラグインなんですがTypePad AntiSpamプラグインもあるので、どちらかは不要ですね。
Movable Type 3.3 マニュアル - SpamLookup
http://www.sixapart.jp/movabletype/manual/3.3/05_preinstalled_plugins/spamlookup.html
Textile 2.05
Six Apart - Movable Type プラグインディレクトリ: MT-Textile
http://www.sixapart.jp/movabletype/plugins/mt_textile.html
Markdownと似たようなものですが。Textileの入力方法が不要なのであれば不要ですね。
Markdown
Six Apart - Movable Type プラグインディレクトリ: Markdown
http://www.sixapart.jp/movabletype/plugins/markdown.html
Markdownの入力方式がいいという人もいますね。
ただ、Markdownで入力しなければ特に不要ですね。
上記であげたようなプラグインは使わなくても、メモリに展開されているようで、使わないのであれば削除してしまった方が負荷を減らすことが可能なようです。
このあたりの話は、言われたものを「はい、そうなんですか」というレベルなのでどうにかしないといけないとこです。
カテゴリーをつかわず、Blogを分割するとか
１つのブログでサイトを構築した方が良い場合と複数ブログで構築した方が良い場合があるかと思います。
前回紹介した記事のGIZMODEのような大量のエントリーがあるサイトとかの場合は、ブログを分けた方が再構築を短くすることが可能になる場合もあります。
サイトマップが最初にきまって、どのようにMTを使うか？という感じで進めていくかと思うのですが、将来的に記事が増えた場合にどうなりそうか？という視点も持ちながら考えてみる必要がありそうです。
パッと考えてみると、１記事に対して複数カテゴリ指定したい場合とかは１カテゴリ＝１ブログみたいな作りだと難しいのかも？とか思ったりもしています。
SSIを使う
共通パーツでそこまで変更がない部分はSSIにしてしまうことで再構築の負荷を減らすことが可能です。
サーバーサイドインクルード | Movable Type 4 ドキュメント
http://www.movabletype.jp/documentation/server-side-includes.html
このあたりに関係してきそうなモノとしてテンプレートモジュールのキャッシュがありますね。
テンプレートモジュールのキャッシュ | Movable Type 4 ドキュメント
http://www.movabletype.jp/documentation/module-caching.html
モジュールのキャッシュを使えば、時間がかかってしまうmt-includeも少し早くなるらしいです。
ここは早めにためしてみないといけないところです。。
公開キューを設定する
ブログ記事やindexページは更新したらすぐ表示された方が良いかもしれないですが、カテゴリアーカイブや日付アーカイブとかは場合によっては更新してすぐ必要、というモノでもないかもしれません。
そういうときは公開キューをしてサーバーの軽い時間で更新する選択肢もありますね。
指定日投稿や公開キュー等のスケジュール処理の設定 | Movable Type 4 ドキュメント
http://www.movabletype.jp/documentation/schedule_task_framework.html
あとはリクエストがあったときにアーカイブを作るとかのプラグインを入れる、という方法がありますね。
Perl版ダイナミック・パブリッシング（MT4用） - The blog of H.Fujimoto
http://www.h-fj.com/blog/archives/2007/07/06-095902.php
MTアクティビティログを見る
多分、これはいわゆるMT管理画面にあるログのことなんだと思っているのですが。
mt-search.cgiがどのくらいたたかれてるか？とかを見ておくときに使う、という感じでしょうか。
mt-tmpl-testをつかう
こういうものがあると言うことを初めて知りました。
コマンドラインから、Movable Type の特定のテンプレートをデバグできる mt-tmpl-test now というツール
小粋空間: コマンドラインから特定のテンプレートをデバグできる mt-tmpl-test
http://www.koikikukan.com/archives/2008/10/31-120300.php
どのテンプレートにどれくらいの時間がかかっているか？というのを知ることが出来るようです。
全然知らなかったので、これは改めて調べ直しです。
パフォーマンスログをみる
こちらも初耳。
動作するにはPerlのモジュールで必要のものがあるかもしれないとのことでした。
再構築にかかった時間の表示や、パフォーマンスログを出力する機能も追加されているので、MT を使う環境に合わせて、テンプレートモジュールのキャッシング設定を調整するなどのチューニングを行い、さらに高速化を狙うこともできる。
再構築などが高速化した Movable Type 4.2〜シックス・アパートに聞く「MT4.2」 - japan.internet.com Webマーケティング
http://japan.internet.com/wmnews/20080623/3.html
ちょっとわかってない部分があります。。
MTOS 4.1.1 のパフォーマンスロギング機能について | MovableType.jp
http://www.movabletype.jp/blog/performance-logging.html
4.3ではシステムに入ってくるらしいですね。
小粋空間: Movable Type 4.3 α版レポート
http://www.koikikukan.com/archives/2009/07/10-015555.php
ということは5でもシステム内に入ってくるんでしょうか？？
FastCGIを使う
FastCGIっていう言葉自体は知っていましたが、使ったことがありませんでした。
FastCGIとは、CGIの動作方法の仕様の一つである。プロトコルは公開されている。
FastCGI - Wikipedia
http://ja.wikipedia.org/wiki/FastCGI
良い情報もありましたし、辞めた、という情報もありました。
どちらがいいのかを全然判断できないのでもう少し調べてみたいと思います
とりあえずまとめ
聞けば聞くほど知らないことがわっさわっさと出てきてしまって、自分の不勉強が恥ずかしくて仕方なかったです。
今回書いてる内容もちゃんとやってる人からしたら当たり前過ぎることなんだとおもうのですが・・・
今回は書いていませんが、ApacheやDBとかの話ももっと知る努力をしないといけませんね。
前回の記事を書いてから色々かんがえていて、MT4iは原因ではなさそうだなぁ、と思ったらやはりMT4iは500エラーの原因としては違う路線の話とのことでした。
なので早めにMT4iは復活させないとな、と思っています。
