Ogawa::Memoranda

SixApart Professional NetworkのMLをチェックされている方はご存知だと思いますが、先月末あたりからTimothy Appnelのエントリーをきっかけに(私自身も含めて)SQLiteネタで盛り上がっていました。それが理由というわけではありませんが、このブログも「MySQL+ダイナミックパブリッシング」から「SQLite+スタティックページ」に移行してみました。

でなぜ移行を思い立ったかというと、以前から(細かいバグの件は別にして)DPはイマイチだなーと感じていたことがあったからです。少し詳しく説明すると以下のような現象・事実があるのです。

「DPに失敗した際に表示されるエラーページが検索エンジンbotにクロールされてキャッシュされている例を散見する」

ロリポップの場合、時間帯によってはMySQLサーバーが過負荷状態になってクエリーに応えられずDPに失敗することがしばしばあるため、このような現象が観測されます。他のレンタルサーバーでも同じ状況は発生し得ますが、ロリポップは10数万のユーザーに対してわずか6台のMySQLサーバーしか用意されておらず(もちろん全ユーザーがMySQLを利用するわけではありません。おそらく10%以下でしょう。)、極めて状況が悪いと言えるでしょう。

「CGIの実行時間を制限するサーバーでは、再構築時、実はSPよりDPの方がInternal Server Errorを起こしやすい」

例として個別アーカイブをすべて再構築する場合を考えると分かりやすいです。SPでは(mt.cfgの)EntriesPerRebuildで指定された個数(既定では40個)ずつ再構築していくために一回ずつのCGI実行時間は短く保たれます。一方、DPでは個別アーカイブの再構築は行われない代わりにFileInfo(個別アーカイブの動的生成に必要な情報)の更新が行われますが、この作業はEntriesPerRebuildの値に関わらず一回のCGI実行で一度に行います。

前者(SP)の一回ずつのCGI実行時間はエントリー数が増加してもほぼ一定で、またEntriesPerRebuildに小さ目の値を設定することでInternal Server Errorを積極的に回避することもできます。MySQLサーバーがビジーで再構築に失敗しがちな場合にもこの対処が一定程度有効です。しかし、後者(DP)の所要時間はエントリー数の増加とともに単調に増加するのみでユーザー側から制御する手段がありません。

つまり、サーバー環境によってはダイナミックパブリッシングは(仮に使えたとしても)実用的でない場合があるということです。

SQLiteを使う場合、現状ではDPは使えませんから上記の問題は半ば強制的に解決します。また、MySQLサーバーの負荷状況に依存しない(Webサーバーの負荷状況にだけ依存する)という利点もあります。各Webサーバーに一つずつMySQLサーバーを立ち上げてくれればDPでも構わないわけですが、一応バックアップを取ったりデーモンが落ちたら再立ち上げする管理コストや、ストレージ容量の問題があるのでしょうね。