トップ «前の日記(2005-06-09 [J]) 最新 次の日記(2005-06-11 [J])» 編集

Eroge RSS Checker 運営記録

Categories | メモ | 運営 | 感想 | 記号変更 | 雑記 | 雑文 | 思案

合計: 今日: 昨日:
2005年
6月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

rss1.0

ここは、「Eroge RSS Checker」に関する運営の記録を書きとめておく場所です。第三者に説明する文体で書いていますが、大半は備忘録です。

  1. スクリプトを汎用化して公開する。---最終目標
  2. CSSを論理的に使う。---努力目標
  3. デザインを改善する。---努力目標
  4. 攻略の完全・不完全を出来る限り判別する。---努力目標
  5. 管理要員用のページの充実。---努力目標
  6. JANコードの入手先を探す。---躊躇中
  7. ブランドの複数登録。---大規模改修のとき
  8. 登録を簡潔にしつつ、marker登録を半自動化する。---暇なとき

2005-06-10 [J]

_ [雑記] キャッシュ作成に対する問題とその解決法

前にも書いたけれど、フィルターの状態全てをキャッシュにすると恐ろしいパターンを作らないとならない。

そこで、フィルターなしの状態でキャッシュを作り、フィルターの状態によって出力を変えるという誰でも思いつく方法があるわけだ。では、どの時点でどのような形でキャッシュを作るべきだろうか。XMLデータベースに移行するという手もあるけれど、現状その利点はあまりなく、速度に問題がありすぎるという話だ。なら、単純にXMLにデータを保存して、XSLTか何かでフィルターを実現するのはどうか。これを、CRC32で同一性をチェックする。それは現実的ではあるが、外部ファイルとして読み込んでいるスタイルシートさえ読み込みエラーが起こるのに、ユーザー側にそれをさせるのはちょっと怖い。ということで、こちらでやるとするとあまり意味がないように思える。結果セットを連想配列(というかハッシュ)で保存するのと多分それほど負荷は変わらないだろう。新しく、パースなど表示部分を作る手間を考えると、こちらに軍配があがるだろう。ただ、実際に使用する前に、結果セットを連想配列に入れる手間がかかるが、まぁそんな事を言ったら何も出来ない。ページ全体をキャッシュする場合に比べるとただMySQLに接続しなくてもすむだけなので速度アップはそれほど見込めないが、多少の変更でフィルターの実現とエラーや遅延の回避が出来る。そして、SQLをIDにすることによって、必ずしも全てのページのキャッシュを作る必要がなく、容量の節約が望める。しかも、『Cache_Lite』を使えば前述の全ての処理が可能で、かつ安全で高速であることが保障されている。

後は、最新のデータであることをどうやって保障するか。更新を確認するためにはMySQLに問い合わせないとならない。だが、そこが問題になっているからこんな仕組みを作らなければならないのに、なんだか矛盾だ。一応断っておくと、最近はMySQLが遅いということはない。ただ、時折、応答しなかったり、結果セットの返答までに非常に時間がかかるだけだ。どうも、サーバー間に問題があるような感じ。『Hironobu's HomePage』にあるようにMySQLのキャッシュ機能はかなりすごいので、変更が1日数回のうちなんかは、9割方このキャッシュを読み込みに行っているだけ。

さて、本題のどうやって更新を察知するか。これは、「SHOW TABLE STATUS」で返ってくる「Update_time」や「Rows」などを使えば案外簡単かもしれない。これが変化したテーブルを含むSQLが使われているキャッシュは無条件で更新するようにすれば必ず最新の結果が返される事になる。その方法は、CRONで31分に1回(さくらは30分に1回以上のCRONの実行を禁止している)にしようと思うがこれでは、時間が掛かりすぎるという場合は確率か間隔を指定した、実行ファイルをインクルードすることになるかもしれない。ただこの場合、些細な更新でもその影響は広範囲にわたるという難点がある。その一方で、キャッシュの生存時間を1時間と言わず1日にも出来る可能性がある。更新頻度の高いフィールドを分け、使用を限定すればほとんどMySQLに接続しないことさえ可能だ。

ということでまとめ。

キャッシュはSQLをIDとして結果セットごとに取る。更新チェックは「SHOW TABLE STATUS」を使い比較的頻繁に行う。

その他の高速化について最後にちょっと覚書。

「ini.zlib.output_compression」や「ob_gzhandler」で行える圧縮データでの送信は、別に困っていないのでいじらないでおく。

PhpTips』:ここにも同じアイデアがありますね。

APC で PHP を高速化

Turck MMCacheを導入してみる - キャッシュでパフォーマンスUP

のようなインストールするだけで高速化できるスクリプトは、root権限が必要な感じなので保留。

_ [メモ] Cache_Lite覚書

内容が空の場合、再度キャッシュを作ろうとする。空が正しい場合はキャッシュが効かないことになってしまうので、エラーが出ているかどうかで場合分けをした。

テンプレートよろしく、SQLの種類を減らしかつページ内容を静的にする(日付なら3日前ではなく何年何月何日)、表示形式を今以上に固定して、部品化する。ことから、負荷回避とか諸々の利点と少しの不具合が出てくる。

お名前:
E-mail:
コメント: