かのネタフルさんに当wikiのMovableTypeからWordPressへのURL込みの移行方法が紹介されたのですが、その後の展開が丁度気になっているMTの再構築時間の話に。
私のところはアクセスが少ない上回線が細いのでCPUパワーが余り気味です。そこで出来る限りのパーツを静的に出力し、SSIでインクルードするようにしました。おかげで再構築の必要性がほとんどなくなり、負荷も許容範囲で、実質WPと同じように使えています。でも大規模なアクセスがあるサイトでは1msのCPU時間も節約したいでしょうから、こんな手法はそのままでは取れないかもしれません。私もサーバが非力なときはかなり気にしていました。
こちらではCMS全般について静的生成と動的生成について議論されています。静的・動的の利点と欠点を踏まえて、 最大の利便性をユーザに提供するべきであるとのご意見を述べておられます。
ユーザにも書き手にも優しい方がいい
全くご意見には賛成なのですが、現状のシステムにおいて、MovableTypeの再構築システムはやはり大きな欠点ではないかと思います。もちろんMovableTypeには負荷を軽減するための多くの機能が搭載されており、ユーザの使い方次第で、ソースコードをいじることなく、かなり性能を向上できます。しかしこの高速化手法は効果の大きい方法ほど動的手法を使うことになります(phpやSSIなど)
特にコンテンツ管理システムからみると記事のライター、読者はある意味対等にユーザです。再構築などという時間のかかる作業も、動的生成で極度に遅いレスポンスもどちらもまずい選択です。MovableTypeの高速化はテンプレートでMTIncudeなどを行ったあたりが限界です。あとは管理者(!=ライター)が負うべきコストですね。
あちこちで使われてる技法キャッシュ
結果行き着くのは似たところです。静的手法では最初の生成時間や高負荷は0には出来ません。動的手法では毎回の負荷増加を0には出来ません。両方を満足させるためには結果としてどういう形にせよキャッシュ技術を使うということ。
特に動的生成の手法ではキャッシュによって劇的にレスポンスが改善される可能性があります。DB、サーバソフト内、スクリプト言語、Webサーバと考えられる要素全てにキャッシュがあるといってもいいくらいです。有効に使うことで原理的に静的生成とほぼ変わらないレスポンスが得られるはずです。
またキャッシュはMovableTypeにも有効です。Webサーバのキャッシュはレスポンス向上になりそうですし、再構築中の負荷を見るとかなりデータベースが食っていますのでDBのキャッシュも効くと思います。
特にapacheでのキャッシュは全てに対して有効そうです(WPで試すとWP-Cacheと同等か少し速い)。またsquidなどでリバースプロキシーをかますのも有効かも知れません。
こちらはmysqlのキャッシュ。(実測したらMTの再構築が少し速くなりました)
なるべく楽したいですね
昔からシンプルで確実、複雑で楽というバランスの話はいろんな場面で語られます。ベテランほどシンプルなものを好むような気もします。UnixenがIDEではなくviを好んだり、アメリカの警官がシンプルで故障しにくいリボルバーを好む人も多いなんていう話も根は同じ感じですね。
が、技術は人が楽するためにあるのですから、これを使うことで楽できるのなら、出来るだけ使ってやろうではありませんか。仮に問題が出てもそれを解決することで、また他の人も楽になる可能性が出てきます。使いものにならなければ、元に戻せばいいだけです。
かくいう私もまだ移行してません。一番の敵は"面倒"ということのようで。
#関連先にトラックバックさせていただいてましたがスロットリングとタイムアウトが出ていたようです。
#take to oneself2さん、mt4iの作者さんとは気づいていませんでした。使わせてもらっています。
タグ:
| パーマリンク
