Как правильно уменьшить количество избыточных запросов с помощью mod_perl?

В довольно большом унаследованном проекте я переделал несколько мохнатых модулей в классы Moose. Каждому из этих модулей требуется доступ к базе данных для (ленивого) извлечения его атрибутов. Поскольку эти объекты используются довольно интенсивно, я хочу уменьшить количество избыточных запросов, например, для неизмененных данных.

Теперь, как мне сделать это правильно? У меня есть несколько альтернатив:

  1. Реализовать кеширование в моих классах Moose через роль, чтобы хранить их в memcached с истечением 5-10 минут (вероятно, не слишком сложно, но сложно с ленивыми атрибутами) update: KiokuDB, вероятно, мог бы помочь здесь, придется почитай про атрибуты
  2. Перейдите на DBIx::Class (это необходимо сделать в любом случае) и внедрите кэширование на этом уровне (DBIC, вероятно, сам по себе устранит большую часть проблем)
  3. Каким-то образом мои объекты сохраняются внутри процесса mod_perl (не знаю, как это сделать :()

Как бы вы поступили и что вы считаете разумным? Кэширование данных предпочтительнее на уровне объекта или на уровне ORM?


caching perl moose kiokudb
person Nikolai Prokoschenko    schedule 08.03.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Краткий ответ на № 3: не используйте «мой». Вы можете сделать что-то вроде:

 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, чтобы они были общими для всех дочерних элементов.

person stu42j    schedule 09.04.2010

arrow_upward
0
arrow_downward

Поскольку вы в любом случае уже собираетесь использовать DBIC, имеет смысл позволить этому изменению позаботиться об этом. Было бы менее разумно свернуть свой собственный, а затем внедрить DBIC, давая вашим сопровождающим паузу, когда они обнаруживают, что вы используете DBIC, но с доморощенным кэшированием ... "по какой-то причине".

Единственные причины не делать этого: (1) если вам действительно нужна эта производительность сейчас, и у вас нет времени ждать изменений DBIC, так как я полагаю, что это будет довольно обширно. Или (2), если вы не уверены, действительно ли собираетесь переходить на DBIC. Если вы не исследовали это и делаете много пользовательских SQL вместо базового CRUD, в конечном итоге это может привести к очень небольшой окупаемости инвестиций.

person Adam Bellaire    schedule 08.03.2010