Movable Typeをめっちゃ高速化する20の方法。
公開日 : 2007-07-06 12:41:08
いつかちゃんと書こうと思っていた。
こういうタイトルのEntryをM回以上かくとブログがつまらなくなるらしいのだが、まぁいいや。問題は中身だよ。
ここで言う「高速化」とは、CMSを操作している発信者側、ブログを訪れる訪問者側双方を対象にしている。全てが全てどんな環境でも出来るとは限らないが(特にサーバーに対する権限の問題で出来ない部分も人によってはあるかもしれないが)何しろ20もあるから1つや2つは誰にだって出来るだろう。
環境まわり。
1.ハードウェアのスペックを上げる。
当たり前のことだけど、メモリを増やす、高速なHDDに入れ替える、あるいはサーバー自体を変える。
レンタルサーバーとかだったらプランを変更する。 金かけたくない? とはいえメモリーもHDDも昔と比べたら安いものだ。
それでもお金が...というのであればちょっと考えてみて欲しい。レンタルサーバーA社のプランaとプランb, B社のプランcとプランd。価格とスピードは必ずしも比例しない。
2.mod_perlあるいはFastCGI化する。
MT3.34以降の場合は特に後者がお勧め。導入が簡単になっている。mod_perlは高速だがメモリー喰うのでサーバースペックアップとあわせて検討。
参考
- Movable Type を mod_perl で高速化する - Apache::Registry 編
- The blog of H.Fujimoto：Movable Type 3.34をFastCGIで動作させる手順
(追記)
mod_perlが多くのメモリーを要する件について以下のエントリーで解決の一例が示されている。簡単に言うとApacheを2つ立ち上げて(1つは例えば8080ポート)片方のApacheは静的ファイル群、もう片方のApacheでmod_perlということ。
この例では mod_proxy で説明されているけれども、僕としてはPoundがお勧め。軽い。このサーバーでも使っている。
(追記ここまで)
データベース関係。
3.RDBMSを変更する。
MySQLかPostgreSQLが速いといわれているが、サーバーとユーザー数とかによってそのあたりは変わってくる。僕の経験では意外(?)と速いのがSQLite。
(追記)
ちなみにここはMySQLね。まぁ無難なところかな。(追記ここまで)
参考
4.DBの最適化を行う。
特にSQLiteでは顕著。VACUUM コマンドで定期的に最適化する。
参考
正攻法?
5.テンプレートのモジュール化。
例えばこのブログのように「最新のエントリー」とかを全てのページに表示させる場合、1ページ変更すると全再構築が必要になる。
再構築について誤解があるといけないので書いておくが、一般的には「ファイルをディスクに書き出す」処理よりも「DBからデータを呼び出してHTMLを組み立てる」方に時間がかかる。MTは内部的にはキャッシュを様々なところで利用していて出来るだけ無駄がないように工夫している。実際のところ「全てを再構築」しても全てのファイルが更新されるわけではない。静的HTMLファイルのタイムスタンプを一度チェックしてみると良い。
この方法は環境に依存せずに実行できる手法であるから是非検討すべき。
詳細は下記のエントリー参照。MT内でIncludeする方法もあるし、PHPやSSIでインクルードする方法もある。
6.テンプレートタグのクリーンアップ。
コメントを受け付けているかどうか、とかCCライセンスかどうか、等はそうそう変更するものでもあるまい。余分な分岐や余分なDBへのアクセスを減らせばその分速くなる。これも先のエントリー参照。
(追記)
少し引用。つまり、デフォルトテンプレートには結構不要な分岐処理のタグなんかが含まれているのだ。
また <MTBlogIfCCLicense> とか一度決めてしまえば不要なもの、あるいは「追記(more)」を使用していないのであれば「 <MTIfNonEmpty tag="EntryMore" convert_breaks="0">」のブロックとかも不要。 カテゴリーアーカイブが必ず吐かれる設定であるのなら「<MTIfArchiveTypeEnabled archive_type="Category">」のブロックもいらない。「タグ」を使っていないとか、自分のスタイルにあわせて不要な部分を削除していく。その分プログラムがデータをチェックする(僅かではあるが)処理が省略できる。
(追記ここまで)
7.アーカイブの数を減らす。
そもそも「月間アーカイブ」って必要? 一度ログをとって解析してみれば良い。不要ならアーカイブマッピングを削除して要らないアーカイブを吐かれないようにしてしまおう。
(追記)
アーカイブだけじゃなくて不要なインデックス・テンプレートもないかチェック。静的生成で運用しているのに mtview.php が毎回再構築されるなんて設定になってない? CSSやJavaScriptは毎回再構築の必要ある? (インデックス・テンプレートの場合は「インデックス・テンプレートを再構築するときに、このテンプレートを自動的に再構築する」のチェックを外せばよい) (追記ここまで)
8.アクセスの少ないページや古いページを再構築対象から外す。
1日1回更新するブログで10,000エントリーを超えていて1日のPVが1,000程度だったら...再構築から再構築の間にアクセスが全くないページが多いわけで(少なくとも9,000ページは無駄な再構築)。
古いページは静的HTMLで置いておき再構築対象から外してしまえば良い。アーカイブとかサイトマップとかトップページへのリンクをちゃんと貼っておけば興味のある人は辿ってくれるだろうし。
ファイルを予めバックアップしておいてMT上でエントリーを削除あるいは下書きにする。全再構築後バックアップファイルをサーバーへ戻してやればよい。というかそんなプラグインはないのだろうか。無ければ作ればいいし。
9.不要なプラグインは外す。
どのプラグインがどうとは言えないが、そのプラグインがどこで何をしているかを把握できない人は不要なプラグインを外すべき。処理が必要かどうかにかかわらず、ロードされる僅かな時間だけでも短縮できる。
プラグインやフリーソフトの手を借りる。
10.高速化のためのソリューションを検討する。
僕の書いたものであれば「Background Rebuilder」や「RebuildAt1stView」など。他にもPerl版ダイナミックパブリッシング(MT4対応版が今日リリースされています)やRebuildQueue、Fast Searchとかいくつかのソリューションがある。ブログの状況に応じて役に立つものがあるかもしれない。
11.高速な全文検索システムを導入する。
mt-search.cgiは重い。
代わりのソリューションを検討しよう。Fast Searchとか、僕も一つ作ったものを公開している(MTLiteSearch)。
エントリー数が少なければAjax化とか、あるいはもっと手軽にGoogleやYahoo!を使う手もある。
サーバーへソフトウェアのインストールが可能なら、全文検索システムを入れてしまえば良い。お勧めはHyper Estraier。このブログでも使っている。以下のエントリーで紹介している。
負荷対策、というかスパム対策。
(追記)
まとめ記事
(追記ここまで)
12.トラックバックを無効にするか、検知されにくくする。
無効にするのが嫌ならば<$MTEntryTrackbackData$> を削除する。「自動検知」ができなくるが、普通にトラックバック機能は有効。尚、無効にするのであればCGIは削除しておこう。CGIが叩かれたらどのみち負荷がかかる。
スパム検知のソリューションで外部へHTTPで通信するタイプのものは場合によっては外すことも検討する。処理に時間がかかるのでそれなりの負荷がかかる。DBへのアクセスが嫌か無駄なHTTPが嫌かは状況に応じて。どのみち事前承認制にしているのであれば自分が嫌な気分になるのさえ我慢すれば良い。
13.コメントを無効にするか、わかりにくくする。
もちろん無効にするってのは根本的な解決法ではない。JavaScriptでコメント欄を組み立てるとか、ダミーのフォームを作って(ダミーのフォームはCSSで非表示)だまくらかす、等。但しアクセシビリティに注意。
14.コメントやトラックバックのCGIのファイル名を定期的に変更する。
上記の2つと被るかもしれないが、CGIファイルの定期的なリネーム。自動化している人もいるようだ。
15.ウェブサーバー側でスパムを排除する。
どんなに優秀なスパムフィルタであっても、CGIを叩かれまくりDBアクセスやHTTP通信が発生していたら負荷かかりまくりである。上記で紹介した「スパマーを騙す」方法にも限界があるし、Apache(に限らないがWebサーバー)側でスパムを弾こう。.htaccess等でdeny指定してやれば良い。但し.htaccessの設定項目が多いとApache側に多少負担がかかる。コメントやトラックバックスパム対策であれば、該当するCGIプラグラムやCGIディレクトリだけを対象にしてやれば良い。
.htaccessでの弾き方の例は例えばこちら↓
サーバーチューニング、HTTP通信関係。
16.ウェブサーバー自体を高速化する。
ApacheならApache自体を高速化する。ログのDNSルックアップを無効にするとか (そもそもログ必要?) 不要なディレクティブを削除するとか.htaccessを使わないとか。そもそもルート権限があるのであれば不要なモジュールを外して再コンパイルする等。
mod_cacheも検討しよう。
17.ダイナミック・パブリッシングではサーバーキャッシュとクライアントキャッシュを使わせるようにする。
サーバー側でキャッシュ機能を使うようにしているWebアプリは多いがクライアントキャッシュをきちんとコントロールしているものはまだまだ少ない(ように思う)。具体的にはConditionalGET(条件付きGET)に対応させること(If-Modified-Sinceをちゃんと見て適切に304を返す)。 これは負荷対策だけでなく転送量も減らしてくれる。
MT4にはダイナミックパブリッシングにおいてこれらの設定が可能になった。
以下のエントリーもご参考にどうぞ。
その他の方法。
18.「全再構築」をコマンドラインから行う。
mt-rebuildを使うとコマンドラインから再構築が行える。シェルが使えないのであればRebuildQueueとかBackground RebuilderであればCGIとは別プロセスで再構築を行えるので同様の効果が期待出来るだろう。
19.更新は夜中(明け方?)に行うか「指定日公開」を使う。
共用レンタルサーバーとかであれば全体の負荷が少ない例えば明け方とかに更新・再構築すれば負荷は少ないが、健康にご注意を。
健康を気にされる方は (気にしろよ!＞俺) 指定日公開でなくとも良いが、cronでmt-rebuildを走らせてもよいし、とにかく負荷の少なそうな時間帯に再構築を行うようにする。
20.JavaScriptやFlash製のブログパーツを外す。
これは閲覧者側の速度に関わるものだが (俺も広告貼ってんじゃん!) ブログパーツや広告の多いページは「重い」。特に別のサーバーにアクセスして動的にJavaScriptで組み立てるタイプのものは重くなる。広告配信サーバーが重ければそのとばっちりも受けなければならない。静的な広告はそうでもないが。
動的とか静的とかいう以前になんぼでも方法はあるのですね。
ところで、あなたのブログが仕事に欠かせないビジネスブログであったり重要なマーケティングツールであったり、ビジネスサイトの運用にMTをCMSとして利用している場合、上記の20項目を簡単に実行するたった一つの方法がある。
21.ウチの会社に連絡する。
ということで、ブログ高速化コンサルティング(コンサルティングだけじゃないよ)、お受けします! (笑)
