Можно долго перечислять преимущества Drupal, однако все они будут сведены в ничто, перед проблемой низкой производительности вашего сайта, построенного на его основе. Так или иначе, если проблема производительности не может быть решена переносом сайта на более производительную платформу или увеличение производительности оной, остается только применение кэширования. Первый пост хотел посвятить моей разработке CacheExtra, однако решил уделить побольше времени на отладку этого модуля. Поэтому начнем с известной многим разработки, именуемой CacheRouter, которую на досуге немного потвикал.

Можно долго перечислять преимущества Drupal, однако все они будут сведены в ничто, перед проблемой низкой производительности вашего сайта, построенного на его основе. Так или иначе, если проблема производительности не может быть решена переносом сайта на более производительную платформу или увеличение производительности оной, остается только применение кэширования. Первый пост хотел посвятить моей разработке CacheExtra, однако решил уделить побольше времени на отладку этого модуля. Поэтому начнем с известной многим разработки, именуемой CacheRouter, которую на досуге немного потвикал.

В общем суть изменений такова:

• Реализован выбор хранилища по совпадению ключа с регулярным выражением, что позволяет более гибко управлять тем, где будут храниться кэшируемые данные. bin с регулярным выражением для ключа описывается как: #. Так например, чтобы кэш строк локализации хранился в файловой системе, в массиве $conf['cacherouter'] пишем следующее: 'cache#locale' => array('engine' => 'file').
• Добавлен движок dual для хранилищ. Кэшируемые данные хранятся в двух хранилищах, различающихся по скорости чтения/записи в них и общему объему. Фронтэнд хранилище имеет более быстрый двигатель кэша, но ограничено по объему хранимых данных. Ограничение по объему данных или числу хранимых значений не следует рассматривать буквально, будем считать, что мы не заинтересованы в слишком сильном разрастании объема кешируемых в этом хранилище данных. Бэкэнд хранилище не ограничено по объему, использует двигатель, более быстрый для операций чтения и медленный для записи. Помним, что наша основная цель - соблюсти баланс. Алгоритм работает следующим образом: при установки значений в кэш, реальная запись данных всегда осуществляется в фронтэнд хранилище с одновременным удалением устаревших данных в бэкэнде. Когда происходит запрос извлечения значения, пробуем сперва извлечь данные из бэкэнда, если их там нет - извлекаем из фронтэнда. В случае, если данные кэша в фронтэнд хранилище не пусты и просуществовали некоторое время, переносим их в бэкэнд, а в фронтэнде удаляем. Также реализую несколько иной алгоритм, с целью расположения более часто изменяемых данных в ведении фронтэнда, а остальные в бэкэнд.

  Мой конфиг для cachextra, использующий этот движок:

  <?php
  'cache_extra' => array(
    'engine' => 'dual',
    'backend' => 'cache_extra_fs',
    'frontend' => 'cache_extra_db',
    'delay' => 60*5, // хотим, чтобы данные были перемещены в бэкэнд
     // через 5 минут после создания и в последствии тянулись оттуда
  ),
  'cache_extra_fs' => array(
    'engine' => 'file',
    'path' => './sites/default/files',
  ),
  'cache_extra_db' => array(
    'engine' => 'db',
  ),
?>
• Пофиксен баг в движке file. Не работало удаление данных по ключу с маской, а также удаление всех данных по маске *.
• Реализована в зачаточном состоянии статистика использования кэша. Включается статистика через settings.php строчкой $conf['cacherouter_statistic'] = TRUE;. Отчеты можно наблюдать в 'admin/reports/cacherouter'. Пока реализовал общую статистику использования кэша (соотношение числа запросов извлечения, установки, удаления, сброса), статистику частоты использования кэша по хранилищам и ключам. Ах да чуть не забыл, чтобы отображались диаграмы (для чего использованы наработки http://keith-wood.name), ваш браузер должен понимать и любить svg.

Может у кого-нибудь будут лучшие идеи?

P.S. Пытался связаться с автором оригинального модуля, но пока безуспешно.