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

Eroge RSS Checker 運営記録

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

合計: 今日: 昨日:
2005年
7月
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
31

rss1.0

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

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

2005-07-09 [J]

_ [思案] キャッシュ問題の決着

そろそろ1ヶ月になってしまうので、終わりにしないといけません。引っかかっているのは、キャッシュファイル数が数万にもなってしまうこと。速度重視で期限切れのキャッシュを削除していないので、SQLの内容が変わるものや、検索結果がたまってしまってすごいことになっている。ただ、それがどんな問題を生むかとなると・・・単純に気分が悪い。後は、FTPでファイル一覧を表示するのに10分以上掛かる(約27000ファイル)。反映ページを限定してこれなので、全てのページでキャッシュを作るには何か変更しなければならない。

SQLの結果セットをキャッシュする今の方法では、ファイル数と利便性はトレードオフの関係にある。更新はテーブルの更新情報を元に行っている、フィールド数も取得できるので活用したい所だが、追加フィールドが条件式に該当するかどうか判断できない。変更時にその情報を保存して更新情報として活用する方法を使えばかなり融通が利くが、それをやるとテキストベースのデータベースを作るのと大した手間が変わらない。したがって、更新情報は今のものを使うしかない、些細な変更でも影響が全体に伝わってしまうけれど仕方ない。

ならば、変えられるのはキャッシュの規模だ。テーブルの結合は非常に面倒(かつ遅い)なのでMySQL側でやってもらうとして、そこからの条件式は、今のフィルターと同じようにPHP側で処理すればいいのではないか。これなら、キャッシュファイルは10程度に抑えられるだろう。ただそれをやると、キャッシュファイルのサイズは最大5MBはいってしまう。しかも、それを毎回処理するのだからデータベースサーバーが相当調子の悪い時でもなければ、遅くなってしまう。データ量がそれほどないならいいのかもしれないが、これは使い物にならない。では、SQLごとのキャッシュではなく、ページごとにしたらどうか。そのページで使うテーブル名を別に記載しておく。ただ、一箇所でも更新されたら全て取り替える必要がある。なにより、フィルターを機能させられない。フィルターの変化も込みでキャッシュを作るとファイル数はさほど変わらない、それどころか原理的には倍増するだろう。

ということで、表示数が多いページに限定して、結果セットを対象に、キャッシュを作る、という今の状態が一番効率的ということになってしまう。最新作の表示をキャッシュしたら他には、表示数の多いページはない。なら、ここのキャッシュを作り、実験中という注意書きを撤去するのがいいらしい。

_ [メモ] 「最新作」だけフィルターが即効かない

Locationで転送できていないにしては、アドレスが変更されていない。

更新すれば、効いている。

何かのキャッシュが効いているような感じ?

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