Ускорение Drupal. Кэширование спасет ваш Drupal сайт (Продолжение)

Опубликовано admin - пт, 03/30/2012 - 08:32

Продолжение статьи о стратегиях кэширования в Drupal. Оригинал на английском можно посмотреть тут.

В последнем посте мы рассмотрели какие механизмы кэширования есть в Drupal "из коробки". Мы поняли как Drupal кэширует страницы для анонимных пользователей и нашли решения, позволяющие отдавать кэшированные страницы без загрузки Drupal (используя обратный прокси, например, Varnish или перенаправление запросов при использовании модуля Boost). Также мы увидели, что даже используя эти инструменты кэширования, Drupal также может хранить кэшированны страницы в базе данных. Однако Drupal позволяет прозрачно подключать и другие более быстрые кэширующие бэкенды:

  • Memcache наиболее часто используется в Drupal как кэширующий бэкенд. Он хорошо поддерживается модулями и также доступен в Acquia Cloud. Memcache достаточно просто масштабируется и модуль memcache позволяет назначать каждому Drupal cache type разные cache bin. Это позволяет без проблем размещать разные bins на разных серверах. Однако memcache должен находится максимально "близко" к веб-серверу, а лучше на одном сервере. Memcache крайне необходим в архитектуре проектов, в которых требуется частичное кэширование страниц для зарегистрированных пользователей.
  • APC также используется для хранения кэшированых ключей. APC — это популярный акселератор PHP, ускоряющий веб-сайты путём кэширования в памяти php скриптов и предотвращающий чтение этих скриптов с диска. Для CMS типа Drupal, которые при каждом запросе загружают много php файлов, наличие установленного APC просто необходимо. Даже если использование APC быстрее, чем использование memcache, его нельзя масштабировать на несколько серверов и в некоторых конфигурациях память, используемая php процессом, не может быть разделяемой с другими процессам, это является существенным недостатком при сравнении с memcache.
  • И другие, включая Redis, Filecache или MongoDB. Все из них имеют модули для Drupal 6 и 7, предоставляющие разные уровни поддержки кэширования Drupal.

Другой кэширующий бэкенд для Drupal может помочь в ускорении генерации элементов страниц Drupal, таких как блоки, представления и ноды.
Замена кэширующего бэкенда в большинстве случаев достаточно простой процесс, для этого достаточно в файле конфигурации settings.php указать другой кэширующий бэкенд и настройки для него. Например для memcache необходимо добавить следующие строки в settings.php:

$conf['cache_backends'][] = 'sites/all/modules/memcache/memcache.inc';
$conf['cache_default_class'] = 'MemCacheDrupal';

Частичное кэширование страниц

Помимо обеспечения высокоуровневого кэширования страниц Drupal также может кэшировать различные элементы страниц. Эти элементы могут быть кэшированы и использованы при следующей генерации страницы. Ядро Drupal и популярные модули имеют возможность кэширования результатов выполнения, как для анонимных пользователей, так и для зарегистрированных, например:

  • Кэширование содержимого: Ноды могут быть закэшированы при условии что поля выглядят одинакого для различных пользователей.
  • Кэширование блоков: блоки могут размещаться на различных участках страницы и могут быть закэшированы глобально, или в привязке к странице, ролям или пользователям.
  • Меню и ссылки меню: Вместо сбора информации о меню и ссылках меню на каждом запросе их сериализованные версии могут быть закэшированы и повторно использованы.
  • Представления: Представления обычно используются для выборки информации из базы данных и представления ее на страницах Drupal. Модуль Views позволяет кэшировать результаты или промежуточные результаты, которые были запрошены из базы данных и должны быть отображены в представлении. Views caching API достаточно продвинут, чтобы определить в каком контексте представление было отображено: фильтры и аргументы могут влиять на конечный вид представления. Поэтому когда кэширование включено фильтры и аргументы используются как часть ключа кэша для гарантии того что результат кэширования сохранен верно.

Кэширование страниц для зарегистрированных пользователей

Есть другое решение, позволяющее использовать кэширование для зарегистрированных пользователей для Drupal 6. Один из факторов, влияющих на отображение страниц для разных пользователей, являются права пользователей. Права в Drupal контролируются ролями, которые назначаются пользователям. В теории это позволяет веб-мастерам создавать группы пользователей, которые могут видеть различные элементы на разных страницах, и следовательно всегда могут получать одинаковую версию страницы.
Давайте посмотрим на главную страницу Drupal.org: только некоторые закладки могут отличаться для разных пользователей и они могут быть изменены, c помощью javascript, который выполняется уже непосредственно в браузере пользователя. Поэтому такую страницу вполне можем кэшировать и сэкономить время на генерацию этой страницы для зарегистрированных пользователей.
Это обоснование применения модуля authcache. При входе пользователя модуль устанавливать дополнительную cookie, в которой зашифрована роль этого пользователя. Поэтому на каждом запросе модуль может определить роль пользователя без дополнительного обращения к базе данных. Модуль позволяет настроить какие страницы кэшировать и для каких ролей (анонимные пользователи, зарегистрированные пользователи и другие роли Drupal). Также этот модуль позволяет настроить url, которые нужно кэшировать или исключить из кэширования.
Порядок работы модуля authcache следующий:

  1. Для каждого запроса модуль определяет может ли страница по этому пути и для этой роли пользователя находится в кэше.
  2. Если может, то Drupal ищет в кэше корректную версию этой страницы.
  3. Если нашел, то отправляет эту страницу пользователю, иначе генерирует страницу и сохраняет ее в кэше для следующих запросов.

Autcache дополнительно сохраняет в cookie имя пользователям и email, которые могут быть использованы в шаблоне страницы.
Autcache работает как обертка кэширующего бэкенда, которая отлично интегрируется с другими кэширующими бэендами (Memcache и Cacherouter). Установить модуль можно следующим образом (используемые кэширующий бэкенд будет автоматически определен):

 
$conf['cache_inc'] = './sites/all/modules/authcache/authcache.inc';

Authcache автоматичиски пытается сделать include для файлов Cache Router или Memcache. Если используется другой кэширующий модуль, то необходимо указать путь к нему, например:

<?php
$conf['cache_inc_via_authcache'] = './sites/path/to/module/cacheinclude.inc';
?>

Страница конфигурации модуля находится в меню Конфигурация->Разработка->Производительность, на ней можно задать все настройки связанные с путями, ролями и настройками кэширования. Доступен отладочный режим, который может показывать отладочную информацию специфичную для роли, которая может помочь понять правильно ли работает кэширование. Модуль Authcache сейчас имеет стабильную версию для Drupal 6 и находится в стадии активной разработки для Drupal 7.

Предотвращение бутстрапа

Обычно, когда используется частичное кэширование, Drupal делает бутстрап для загрузки различных кэшированных элементов, который отнимает процессорное время. Это можно оптимизировать используя ESI (Edge Side Includes) и Varnish: элементы страницы или блоки могут быть загружены при каждой загрузке страницы через внутренний вызов к бэкенд серверу. Это может помочь в ситуациях когда всю страницу можно кэшировать, но некоторые элементы должны кэшироваться по-другому или не могут быть кэшированы, так как изменяются в зависимости от контекста. Есть модули, позволяющие интегрировать ESI c Drupal и отображать несколько типов элементов по url, которые включены в вызовы ESI. В Drupal 8 ожидается, что отображение нескольких элементов через ESI вызовы станет значительно проще. Это одна из главных целей WSCCI, подробнее можно почитать на http://groups.drupal.org/wscci.

добрый день. подскажите почему после сброса кеша у всех views белая страница?

Добавить комментарий

Filtered HTML

  • Допустимые HTML-теги: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd>
  • Строки и абзацы переносятся автоматически.
  • Web page addresses and email addresses turn into links automatically.