Cacheフレンドリな設計

大概のフレームワークにはcacheコンポーネントがある。
効果的に導入できればパフォーマンスはかなり改善される。しかし、キャッシュのベストプラクティスはアプリケーション毎、対象にしているクライアントによって異なる。

一般に、キャッシュを効果的に利用するにはアプリケーション上の制約が必要になる。

大雑把に言えば、ページ一枚まるっとキャッシュを食わせることができるような状況ならあまり考えることはない。ページキャッシュを使えばすぐにできる。
しかし、通常、ページキャッシュで済むサイトならフレームワークを使う必要もあまりない。効果的にページを作成管理できるデスクトップアプリを開発したほうがましだろう。
複雑なサイト構成になってくると、クライアント毎、アクセス毎に動的なデータアクセスを必要とする場合がある。そこで、キャッシュを工夫する必要が出てくる。
キャッシュを考える上では、更新に対する管理も重要。更新が起きたキャッシュを破棄するロジック、または、更新フラグをチェックしてキャッシュを利用しないロジックが必要になる。

初歩的工夫

ページ全体をキャッシュ可能なコンテンツと動的に出力しなければならないコンテンツに分けることができれば、キャッシュ可能なコンテンツの出力に必要な重いバックエンドの処理を省くことができる。また、そういったコンテンツは再利用性も高い。1枚のレスポンスの中に、動的な要素を組み込めばいい。
たとえば、レスポンスを配列にして、

<?php
$res[] = array('string' => '共通コンテンツ');
$res[] = array('dynamic' => array('ClassX', 'MethodY', 'param'));

といった具合にレスポンスを積み重ね、このスタックをキャッシュしておく。
このキャッシュに条件としてヒットした場合、キャッシュをunserializeして、文字列はそのままecho。dynamicに指定してある部分はクラスやメソッドをコールして動的なコンテンツを取得する。無論データ構造などについてもキャッシュもしくは動的取得等を連鎖的に利用する。
こうすることで、ログイン状態の表示や個人レベルのカスタマイズを生かすなどの工夫が可能になる。

レスポンスオブジェクトとビューの工夫

設計を工夫すればもっと柔軟な設計になる。普通のレスポンスオブジェクトは出力を文字列でスタックしておき、最終的に結合して出力する。この部分で、文字列だけではなく、文字列化可能なオブジェクトをスタックしていけば、キャッシュを保存するタイミング、データアクセスするタイミングを工夫することができるようになる。PHP的には、クロージャーを使う方法がシンプルでいい。
http://www.ibm.com/developerworks/jp/opensource/library/os-php-5.3new2/#N10105
こちらのリスト６にあるように、段階的なビューの育成を可能にすればよい。

高負荷耐性は誰のもの？

大規模Webサイトでは高負荷対策を行うのは言うまでもないが、意外にも中小規模の場合の方がそのニーズは高いのではないか。
サーバーファームを増設すれば済む大規模サイトに比べると、まだまだ数台の構成で運営しているWebサイトは多いものだ。そんなサイトでも、本格的なスケール展開をするかどうかの敷居値が十分に高ければ、損益分岐点に余裕ができる。