中堅サイトの負荷対策 これだけは - PHP周辺 -

本日、TBSテレビ「王様のブランチ」で真夜中ナビ深夜営業のお店探し モバイルが紹介されました。

自分はあまり頭が良いわけではないので本当なら、小林麻耶アナ可愛い、森山愛子さん良い声している、ブランチリポーターの誰々が可愛すぎる、斉藤慶太くんも可愛いゎ、とか書きたいのですが、それでは Hatena Diary になりません。技術的観点でためになったことを書いてみます。

放送直後、さすが王様のブランチ。“超夜型サイト”の紹介にも関わらず、真昼間にアクセスが集中しました。

そのとき、興味深かった現象。たとえば（PHPで）ページキャッシュをしているようなページはサクサクなのに、何の工夫もなくDBにアクセスしているページは目に見えて遅かった。（定性的な表現で申し訳ないです。）

PHP と言えば DB（MySQL/PostgreSQL）なしにアプリを作ることは考えられない程にDBと密接なものですが、やっぱり DB処理ってボトルネックなんですね。（当たり前って頭でわかってても、実際に目の当たりにすると改めてそう思いました…。）もちろん、DB上のデータをビューに落とし込むまでの一連の実装方法に依存する部分が大きいと思いますが…まぁなんとなく（いい加減）。

ということで、やってて良かったと思うことをひとつだけあげてみます。中堅サイトを運営している方は参考になるかもしれません。

「通常時はサーバダウンや表示遅延がなくても（いざというときのために）リアルタイムでDB処理を行う必要のないページ（コンテンツ）は労を惜しまず、出力結果をキャッシュするよう実装すべき」

なんてことはない、ABC（当たり前のことを馬鹿にせずちゃんとやる）レベルのことですが。

もちろん、キャッシュするページ自体の表示速度が上がるという直接的な効果もあるのですが、サイト全体としてDB処理を行う回数を減らすことに大きな意味があるように思います。

キャッシュといってもさまざまな層のものがあるようですが、PHPで出力結果をキャッシュするならPEAR::Cache_Liteを使うのが定番だと思います。PEAR::Cache_Lite はページ全体の出力結果はもちろん部分的な出力結果も簡単にキャッシュでき、ソースコードがシンプルで内部処理を把握できる点でも良いと思います。

毎回ながらが駄文ですみません。

[ 追記 ]

PEARマニュアルにあるように、Cache_Lite を使って最大限の効果を得るためには、ページが必要とする全てのパッケージを機械的に include しないことがポイントです。ピンとこない方はPEAR::Cache_Lite 導入が参考になると思います。

ZendFramework のようにクエリ発行時にDB接続を確立するような設計をしていれば、機械的に include してもよいので、それがベターですが…過去の遺産が重たい場合もありますよね（汗