2004-12-22
Class::DBI::Cacheable
訪問者が多いうちに聞いてみよう*1。
Class::DBI::Cacheableは前の会社にいたときに使おうと思ってたんだけれど、Cache::FileCacheを使っているのでサーバが複数あるとupdateしたときに不整合が起こりそうな気がして使うのをやめた記憶があります。このあたりはどうなってるんでしょうかね？
updateする可能性のあるカラムだけキャッシュしない設定があるとか、あるいはそういうテーブルには使うなってことなんでしょうか。
この辺りが気持ち悪くて自前のCahce::FileCacheラッパを使ってたりするのですけれど。
あと、MySQL*2を使ったCache::Cache*3ってないですよね？ 上記みたいなケースでNFSを使うよりは良さげな気がするんですけれど。そうでもないのかな。
補足
Class::DBIのパフォーマンスを気にしている方がいますが、まずはEssentialの設定を見直すことをオススメします。
キャッシュなんかしなくても、数倍パフォーマンスが良くなりますから。
Class::DBI::Plugin::Iteratorを使うならSELECT * にするのを推奨。
はてな開発の裏側
個人的にはどうやってサーバを展開してるかが気になるのですが～。
ハードじゃなくてソフトのほうね。
例えばプログラムをバージョンアップさせるときに、某所のようにrsyncで散まいてるとは考えたくないのですけれど。
気になった点
伊藤氏ははまぞうで利用したAWSのポイントとして「AWSは正規表現でプログラムすること」を挙げた。はてなのようにページビューが多いサイトでは速度の問題がシビアであり、PerlのXML関連モジュールはどうしても速度の面などで問題があるのだという。「Perlの正規表現はとても優秀で、モジュールと比べても桁違いに早い。（速度という観点から）XMLモジュールよりも現実的なほうを実装している」。
うーん。XMLモジュールでロジックをテストしてから正規表現による独自モジュールに変更、とかじゃないのか……。
そもそもそんなにXMLを頻繁にパースする必要はない気もするんだけれど*4、２億PV／月＝5,000PV／分*5だったりすると何かと問題があったりするのかもしれない。
というか、90台のサーバって、どんな振り分けになってるんでしょ。
