6

かなり大規模なレガシー プロジェクトで、いくつかの毛むくじゃらのモジュールを Moose クラスにリファクタリングしました。これらの各モジュールは、その属性を (遅延) フェッチするためにデータベース アクセスを必要とします。これらのオブジェクトはかなり頻繁に使用されるため、たとえば変更されていないデータに対する冗長なリクエストの数を減らしたいと考えています。

さて、どうすればそれを適切に行うことができますか？いくつかの選択肢があります：

  1. 5〜10分の有効期限でそれらを保存するロールを介してMooseクラスにキャッシュを実装しますmemcached（おそらくそれほど難しくはありませんが、遅延属性では注意が必要です）更新：KiokuDBはおそらくここで役立つ可能性があり、属性について読む必要があります
  2. (いずれにせよ実行する必要があります) に移行しDBIx::Class、このレベルでキャッシュを実装します (DBIC はおそらくそれだけでほとんどの苦痛を取り除きます)
  3. どういうわけか、オブジェクトを mod_perl プロセス内に永続化します (これを行う方法の手がかりはありません :()

あなたはこれをどのように行いますか？オブジェクトまたは ORM レベルでデータのキャッシュが優先されますか?

4

2 に答える 2

1

#3 に対する簡単な答えは、「my」を使用しないことです。あなたは次のようなことをするかもしれません:

 use vars qw($object);
 # OR post perl5.6:
 # our ($object); 

 # create your object if it doesn't already exist
 $object ||= create_object;

 # Maybe reload some attributes if they have expired.
 $object->check_expires;

ハンドラー内でこのように作成されたオブジェクトは、各 Apache 子内でのみ共有されます。これは、5 ～ 10 分ごとにデータをリロードする場合に問題ありません。読み取り専用のモジュールとオブジェクトは、すべての子で共有されるように PerlPostConfigRequire スクリプトにロードする必要があります。

于 2010-04-09T15:49:56.693 に答える
0

いずれにせよ、すでに DBIC を実行する予定なので、この変更で処理できるようにするのは理にかなっています。独自のものを展開してから DBIC を実装するのはあまり意味がありません。DBIC を使用しているが独自のキャッシングを使用していることにメンテナーが気付くと、「何らかの理由で」一時停止します。

これを行わない唯一の理由は、(1) そのパフォーマンスが今本当に必要で、DBIC の変更を待つ時間がない場合です。または (2)、本当に DBIC に移行するかどうか確信が持てない場合。それを調査せずに、基本的な CRUD の代わりに多くのカスタム SQL を実行している場合、投資に対する見返りが非常に小さくなる可能性があります。

于 2010-03-08T16:34:25.830 に答える