[Rumble-jp-dev] キャッシングシステム検討

黒澤です。

ページ生成のオプティマイズは進めるとして、
生成結果のキャッシングも検討したいと思います。

タスク優先順位やスケジュールは別途検討するとして、
とりあえず実装方式を議論しようと思います。

まずは大前提として、
『キャッシングできるのは「検索処理」のみ』になります。
ここはいいですよね。

次は、キャッシングレベルです。
■1.サーバサイドキャッシュ
サーバサイドで生成したHTMLをファイルか何かに保存しておき、
クライアントからのリクエストに対し、適宜EJB呼び出しをする前に
結果を返してしまう。

メリット:
  a.サーバ負荷はかなり下がる

問題点  :
  b.ネットワークネックは解消できない
  c.キャッシュのExpireの考え方。
    時間でやるか、データ更新をトリガとするか

■2.クライアントキャッシュ
フォーラムの実装(更新のあったフォーラムを強調表示)
で使っている方法の応用。

サーバサイドで生成したHTMLを返す際にContentDateも設定し、
次回以降のブラウザからのリクエストをIf-Modified-Sinceヘッダ付き
のリクエストにさせる。
サーバサイドでは、If-Modified-Sinceヘッダの日付と
データの最終更新日時を比較し、変化がなければ304 Not Modifiedを返す。

メリット:
  d.頻繁にアクセスするユーザの利便性がかなり上がる
  e.頻繁にアクセスするユーザばかりの場合、ネットワークネックが解消できる

問題点  :
  f.キャッシュはクライアントサイドなので、新規ユーザがアクセスしてきたら
    当然キャッシュがないのでデータは作り直し。
    ユーザが多く、かつ更新が多い場合、
    実はあんまりサーバの負荷は下がらない。
  g.laplaceさんがフォーラムの動作について述べていたように、
    明示的にリロードしないと最新表示にならなかったりする現象がおきる。
  h.「データの最終更新日時」をどう定義するか。
    DB上の各行にタイムスタンプつけるとか？
    とすると、更新日時チェックにもそれなりのサーバ負荷がかかる。

■3.組み合わせ(サーバ＆クライアントキャッシュ)
1と2を併用。
サーバサイドキャッシュに保存されているHTMLファイルの日付を使って
If-Modified-Sinceのやり取りを行う。

メリット:
  i.サーバ負荷とネットワーク負荷どちらも下がる。
  j.クライアントキャッシュの問題点fとhが解消できるので、
    クライアントキャッシュを実装するなら、このパターンを使うのが一番楽。

問題点:
  k.クライアントキャッシュの問題点fは依然として残るので、
    明示的にリロードしないと最新表示にならなかったりする現象がおきる。



ポイントは、
・キャッシュExpireのタイミングまたはデータ更新判断
・クライアントキャッシュの問題点f
ですね。

頭で「検索系のみ」と前提を置いてしまっているので、
キャッシュは一定時間でExpireするとしちゃって、
設定か何かでページ毎の更新間隔をコントロールする
というのが現実解でしょうかね。

クライアントキャッシュの問題点fは、
フレームを導入して、最新表示にならないと困る部分(メニュー部分)と
ならなくても大丈夫な部分(つまりキャッシュしたい部分)を分ければ
解決しますが、どうかなー。

もう古い情報ですが、
「ウェブデザインの間違いトップ10」
http://www.usability.gr.jp/alertbox/9605.html

「あれから3年、『間違いトップ10』を再検証」
http://www.usability.gr.jp/alertbox/990502.html

トップ1がフレームなんですよ。
なるほどと私も思うし、実際最近フレームを使ったサイトが
以前より減っているので、やっぱりみんなもいまいちだと思っているんじゃ
ないかなぁと。

-- 
Naoki Kurosawa <naoki_kurosawa ＠ ybb.ne.jp>