この件に関しては先に書かれてしまったけれど、書きかけだったので書いときます。
すっかり落ち着かれたようですが、個人的にはほんのちょっと前まで、百式管理人こと田口元さんのライフハックブログ、「IDEA*IDEA」が大変熱かったです。何が熱かったかって、僕が以前書いて心配していたことを、まさに再現してくれていたからです。
以前書いたというのは、以下の二つの記事です。
- 静的生成と動的生成、Webページをビルドするコストは誰が支払うべきなのか - talk to oneself 2
- 続・静的生成と動的生成、Webページをビルドするコストは誰が支払うべきなのか - talk to oneself 2
一部抜粋。
静的生成では 2時間の我慢で済んでいたものが、動的生成ではそこから開放される代わり、サーバーダウンを引き起こす可能性が確実に上がるのです。ダウンしないまでも、多くのレンタルサーバーでは高負荷時に CGI の動作を制限したりしますので、Web ページ自体が見られなくなったりします。静的生成なら、例え高負荷で CGI に実行が制限されたとしても、Web ページ自体はただのファイルですから閲覧することは可能です。これが先に、「動的生成の CMS に乗り換えるべきなのかというと、すべてがそうとは言い切れません」と書いた理由です。
田口さんの MT→WP への移行の道のりを整理しておきましょうか。
- 2009年12月27日、まずは「SIMPLE*SIMPLE」を移行
- 2009年1月5日17:03、「IDEA*IDEA」で試したところアクセス数が多すぎるので、新しいサーバー借りてやってみるとの記述
- 2009年1月6日12:35、さくらのレンサバプレミアムを借り、「IDEA*IDEA」を移行
- 同日19:20、「それでも負荷がかかるよう」と、自宅サーバーに再度移行
比較的 PV の少ない「SIMPLE*SIMPLE」でまず試したところ快調だったので、「IDEA*IDEA」も移行した。しかし「SIMPLE*SIMPLE」よりも PV の多い「IDEA*IDEA」では思いの外負荷が高く（動作が重たく）、外部にレンタルサーバーを借りたところそれも駄目で、結局新規に自宅サーバーを立てて再度移転、と。
お疲れ様です。
まぁ田口さんの場合、移行の理由を
さてそろそろWordPressに移行しますよ。MovableTypeにはお世話になりましたが、企業CMSとして高機能版へ進化していっているので個人ブログにはちょっとつらい（MT4.xへアップグレードする理由がない）。あとモバイルへの対応が難しいのも理由です（WordPressだとプラグイン使えば固定リンクそのままでケータイへ振り分け可能）。
と、単に「MT は負荷が高いから WP に移行する」などと書かれているわけではないので、苦労してサーバー引っ越す羽目になったとしてもそれはそれで価値のあるものなのでしょう（それでも、「高機能版へ進化していっているので個人ブログにはちょっとつらい」とシンプルな WordPress に移行したのに、かえって負荷が高くなっちゃってサーバー移転ってのはどうよ、と思いますが）。しかし気になったのは、「WordPressが重いからサーバー移した」と言っているのは、実際何がどう重かったの？という点。管理側なのか、閲覧側なのか、その両方なのか。僕が覗いていた範囲では、閲覧側がそれほど重いとは感じませんでした。何がどう重かったのかは分かりませんが、負荷のかかった原因としては、
- コンテンツ量が多いので、最初の Cache が生成されるまで負荷が高かった。
- デザインをトライ＆エラーで変更しまくっていたので Cache の Purge が発生して負荷が高かった。
の二つなんじゃないかと予想。なんか移行してから色々とデザインをトライ＆エラーで変更していましたよね。最初の Cache が生成されるプロセスは、MT で再構築しているようなもの。そう、実は一過性のものであり、しばらく我慢すればサーバー引っ越さなくても済んだんじゃないでしょうかね、と思ってみたり。デザインの変更は、別に検証環境でも何でも作ってそっちでやって、決定したものを適用するべきだと思いますけどね。それは MT だろうが WP だろうが同じでしょう。500／日PV以内の小規模なブログならば、トライ＆エラーでも良いのかもしれないですけど。
「WordPressが重いからサーバー移した」とだけ書かれるのは、なんか WordPress に変にマイナスなイメージだけを与えるので、その辺はきちんと説明した方がいいんじゃないかと思います。このバタバタで、WP への移行を思いとどまる人は多いんじゃないでしょうか（コグレさんの決断は妥当だとおもいますけど）。
田口なんて、その程度の知識レベルだっていうのは、一度ブログを見たことがあればわかるじゃん。
WordPressユーザーは、そんなにバカじゃないから大丈夫だよ
＞口田さん
うーん、心配してるのは既ユーザーではなくて、新規あるいは他のブログツールのユーザーの方です。
使っている人は「重い重い」と言われても「何か？」という感じでしょう？
このところ MT → WP への移行が多いようで、興味深く見ています。
IDEA*IDEA の場合、DB サーバーがネックだったでしょう。さくらは MySQL サーバーが別で、これの反応が重いらしいです。DB クエリをキャッシュするか削減するかすればいいのですが、なかなかテクニックが必要です。ウチのサイトの場合、メインブログでは 50 queries ぐらいで、ちょっと多いかもしれません。20を切るぐらいになればだいぶ軽快になるはずです。
個人的には「PC と携帯電話は同じ URL で閲覧できるのがベスト」と考えていますが、そうなると完全な静的生成は無理なんですよね。PHP コードを含む html を吐くというハイブリッド方式か、動的生成で一部をキャッシュするか。
MT4i は現時点では動的生成 + キャッシュですが、ハイブリッド形式というのはいかがでしょう?? 当然ながら、アルゴリズムや仕組みがまったく違うので、まるで別ソフトになってしまいますが。
さくらは PHP が CGI モードで動作するというのもネックです。
クエリの設定は、さくらの共有 MySQL サーバーでは勝手にいじれないですよね？
あと、クエリの削除ってどういうことでしょうか？
実行途中のクエリを削除してしまう？
延々応答が返ってこないクエリを削除、というのなら分かりますが。
しかしそれってそんなクエリが残ってしまう根本を解決する必要がありますよね？
ハイブリッド形式は、現状でも工夫すれば何とかなるでしょう。
MT で .htaccess 吐くとか。
試してませんけど。
必要ならばユーザー側で工夫してもらえば良い、というのが基本スタンスです。
PC での閲覧まで動的に受けて、いたずらに負荷を上げるのもどうかと思いますよ。
自宅サーバー運用するだけの知識と手間をかける時間があるなら、それくらいの工夫は訳もないと思うんですけどね正直…。
ちなみに昨日も、IDEA*IDEA から応答が返ってこない時間帯がありましたね。
23時頃。
ずっと見ていたわけではないのでどれくらいの時間そうだったのか分かりませんが、自宅からとレンタルしているさくらのサーバー上から接続できませんでした。
名前解決はできていたのですが、HTTP 接続負荷（タイムアウト）、Ping も通らなかったので、サーバーがダウンしていたものと推測されます。
大丈夫なんでしょうかね？＞負荷
ちょっと心配。
ゆりこさんもこんなところにコメントしてないで、田口さんに直接アドバイスしてあげたらよろしいのではないでしょうか。
＞あと、クエリの削除ってどういうことでしょうか？
画面出力を生成するのに必要な MySQL 総クエリ数を減らすということです。具体的には、クエリを多数発行しそうなテンプレートタグやプラグインを減らしたり、クエリ結果をキャッシュさせるとかの方法です。実例として「WordPress サイトのパフォーマンスチューニング (1)」があります。
クエリ数は、footer.php あたりに get_num_queries() というテンプレートタグを使えば取得できます。
＞ハイブリッド形式は、現状でも工夫すれば何とかなるでしょう。
＞MT で .htaccess 吐くとか。
.htaccess を使うということは、携帯のキャリアごとに html を吐いて振り分けるということですか?
わたしの想定しているのは、PC・携帯を1つの php ファイルとして出力して、php ファイル内で PC/携帯判別して if 文とかで表示内容を変更させるという手法です。
＞PC での閲覧まで動的に受けて、いたずらに負荷を上げるのもどうかと思いますよ。
きちんと携帯対応すると、PC : 携帯のアクセスはほぼ 1 : 1 になるので、携帯向け出力の負荷が PC に比べてあまりに高いならば、少し PC 向けの負荷が上がってもハイブリッド形式にした方がトータルでは軽くなります。例えば、PC 向け負荷が 1 で、携帯向け負荷が 10 ならば、平均負荷は 5.5 です (PC と 携帯の比率が 1:1 と仮定)。これを、ハイブリッド形式にして、両方の負荷がともに 2 になったとすると平均負荷は 2 になるので、約 1/3 の負荷軽減となります。ですので、「PC 向けページの負荷を上げることは、まかりならん」というのは必ずしも正しくないと思います。
＞クエリの削除について
すみません、「削減」を「削除」と空見していました。
＞ハイブリッド形式について
はい、それでも別に良いです。
＞PC閲覧の負荷について
ハイブリッドにするとどうして負荷が下がるのか、さっぱり理解できません。
頭が悪くてどうもすいません。
＞ハイブリッドにするとどうして負荷が下がるのか、さっぱり理解できません。
これはハイブリッド形式の実装案\について詳細を書いてないので、分からなくても仕方ないですね。
わたしが想定しているのは、MT の再構築時に PHP ファイルを書き出すようにして、その PHP ファイルは、if 文で表示するコンテンツを変化させるものです。
if (is_ktai()) {
--携帯用コンテンツ--
} else {
--PC用コンテンツ--
}
携帯用コンテンツは、機種判別によってページ分割とか画像や絵文字の変更も必要ですが、PHP ならばさほど難しくはないです。
で、この PHP ファイルの実行には、MT の API を呼んでコンテンツを引っぱってくる必要はないので、perl の CGI を実行するコストが一切かかりません。純粋な HTML の表示よりも PHP の実行は少々負荷がかかりますが、CGI の実行よりは遥かに少ないです。このため、MT4i による動的生成よりも軽いと予想できます。したがって、「ハイブリッド形式だと負荷が下がる」ということです。
MT4i 3.0 以降はキャッシュ機構があるので、比較的軽いと思われますが、それでも perl CGI の実行ですから、PHP よりはコストがかかると思います。
このへんの話を厳密に議論するには、実際にプロトタイプを作ってみて、サーバー負荷を計測した方がいいですね。定性的な話では平行線になってしまいそうですから。理屈よりは数値が大事ですし。
# ヒマがあれば MTOS と MT4i を試してみたいんですが、なかなか手がつけられません……。
すみません、余計に理解できなくなりました。
「ハイブリッド形式だと負荷が下がる」というのは、単に PC 版と携帯版で URL を共有することによって負荷が下がると言っているのだと思ったのですが、違うようですね。
PHP よりも Perl CGI を実行する方がコストがかかるという前提の上に話が成り立っているようですが、僕の使用しているさくらのレンタルサーバーのように、PHP が CGI として実行されるような環境の場合にも、果たしてそうなのでしょうか？
などという議論は本筋からずいぶん外れてしまっているようなので、これ以上の継続はご勘弁いただければと思います。
その PHP で書かれた WordPress が「重いからサーバー移転した」とか言われてるんですけどね…。
＞PHP よりも Perl CGI を実行する方がコストがかかるという前提の上に話が成り立っているようですが、
これもありますが、コンテンツ (エントリーやコメント) がすでに取得されていて、Perl のモジュール大部分や MT のライブラリー を use しなくて済むのが大きな理由です。携帯向け画像変換は再構築時にやっておけば、読み込み時に ImageMagick を読まなくてよくなります。
MT4i が重いと言われるのは、Perl や MT のライブラリーを多数読むからじゃないかと予想しているんですが、このへんは「実測」しないと検証できませんね……。
＞僕の使用しているさくらのレンタルサーバーのように、PHP が CGI として実行されるような環境の場合にも、
さくらについてはあまり詳しくないんですが、プロ以外は CGI 動作らしいですね。モジュール動作とどれだけ負荷に差があるか知りませんが、Perl CGI と同じぐらい重い気がします。そうなると、「ハイブリッド形式が純粋な HTML とあまり負荷に差がない」という前提は崩れてしまいますね。MT4i による動的生成ほどは重くないでしょうが、あまり差がなかったりして……。
定性的議論ではなんだか発散してしまうので、わたしもこのへんで打ち止めとしておきます。
コンテンツの作りやすさでは明らかに動的生成なので、動的生成をいかに軽くするかという面でがんばる方が楽だとは思います。