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

Question

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

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

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

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

Answer 1

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

Answer 2

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

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