Как многие уже знают - не обязательно передавать все клиентские запросы напрямую в Drupal. Контент может быть закеширован и отдан прокси серверами, такими как, например, Varnish, или CDN серверами, например CloudFront, CloudFlare. Даже Nginx может быть настроен таким образом, чтобы отдавать закешированные запросы самостоятельно. Подобная практика позволяет в разы сократить нагрузку на сервер и увеличить скорость отдачи контента.
Cache expiration
Самая простая стратегия кеширования, cache expiration - это когда прокси сервер смотрит на заголовок страницы, который он получил от Drupal, и в зависимости, от его параметров решает нужно ли кешировать страницу, и если нужно, то насколько. Основной заголовок, который учитывается прокси серверами - это Cache-Control и его параметр max-age.
Сразу стоит заметить, что не все страницы кешируются. В конфигурациях прокси серверов считается правильно не кешировать POST запросы (например, когда форма отправила запрос), а также запросы содержащие сессионные куки (это значит, что пользователь авторизован). Также разные системы могут смотреть и на другие параметры в заголовке страницы. Например, Acquia Cloud не кеширует запросы в заголовке которых присутствует параметр Authorization (необходимо выключить модуль Shield и http аутентификацию в .htaccess, чтобы Varnish в Acquia Cloud кешировал страницы).
Очистка кеша в стратегии “cache expiration” происходит при достижении срока хранения кеша, который задается параметром max-age в заголовке Cache-Control для каждой страницы. Вы не увидите изменений контента, пока кеш не сбросится через определенное время, или вы не сбросите кеш самостоятельно.
Данный вариант размещения кеша легок в настройке и подходит в качестве первоначальной конфигурации для приложения.
К минусам можно отнести то, что значение параметра max-age должно быть компромиссом между вашим желанием снизить нагрузку на сервер максимально и предоставить пользователям актуальный контент. Я думаю, вы бы не хотели показывать обновление страницы через сутки после того, как страница была на самом деле изменена. Поэтому, в зависимости от нагрузки на сайт и частоте обновления сайта, время жизни кеша может быть от пары минут до нескольких часов.
Cache invalidation
Есть и другая стратегия кеширования - cache invalidation. Используя эту стратегию мы можем закешировать данные намного дольше - на день, месяц или даже год. Очистка кеша будет происходить запросом от бекенда к прокси серверу, используя специальный ключ. Примером такого ключа может быть адрес страницы или тег.
Данная стратегия сложнее в реализации, но у неё много преимуществ. Главное из которых - мы очищаем кеш только тогда, когда это действительно необходимо. Благодаря этому мы можем значительно снизить нагрузку на сервер. Но, в тоже время, мы должны очень тщательно подойти к процессу сброса кеша. Если мы не покажем актуальный контент пользователям, то это тоже будет проблемой.
Настройка Drupal 8 в стратегии “Сache expiration”
В Drupal 8 проектах мы можем использовать обе стратегии.
В стратегии “cache expiration” в Drupal вам достаточно выставить время жизни кеша на странице /admin/config/development/performance в настройке “Browser and proxy cache maximum age”.
Настройка Drupal 8 в стратегии “Сache invalidation”
Если вы выбрали стратегию “cache invalidation”, то в Drupal 8 можно использовать стандартную очистку кеша по тегам. В начале вам нужно убедиться, что вы сбрасываете нужные кеш теги при обновлении контента и конфигов. Если вы, например, изменили заголовок сайта, то кеш должен быть сброшен для всех страниц. А если вы добавили новую новость, то страница со списком новостей должна обновиться. Или при изменении ноды мы должны удостовериться, что поиск показывает измененную версию.
Список тегов, которые используются на странице вы можете найти в заголовке страницы “X-Drupal-Cache-Tags”.
Модуль Purge
Следующий этап - установка модуля Purge и одного из его плагинов, который работает с тем прокси сервером, который установлен у вас.
Архитектура модуля Purge довольно изящна. Он состоит из основного модуля - purge и модулей-плагинов, которые реализовывают его функционал.
Модуль Purge cостоит из четырех основных частей:
- Queue - задает хранилище для очереди. В модуле Purge есть реализация для базы данных, файловой системы и хранения в памяти. Для типового проекта рекомендуется использовать очередь реализованной в базе данных. Такой вариант обеспечивает необходимый компромисс между надежностью и быстродействием.
- Queuer - определяет обработчик, который смотрит, что должно быть очищено и добавляет информацию об этом в очередь. Для очистки кеша по тегам используется модуль purge_queuer_coretags.
- Processor - определяет способ запуска очистки. Вы можете использовать purge_processor_cron - запуск очистки по крону, или purge_processor_lateruntime - запуск будет производиться при каждом запросе Drupal после того, как ответ был сформирован, но еще не был отправлен. Также запустить очистку можно используя drush команду
drush p:queue-work. За один запуск процессора может быть обработано определенное количество записей в очереди. Поэтому вы можете комбинировать процессоры в зависимости от ваших задач или использовать все варианты одновременно. - Purger - реализует коммуникацию с прокси сервером. Список вариантов и модуль для интеграции вашего прокси сервера с Drupal вы можете найти на странице модуля Purge.
Модуль Purge UI (purge_ui) предоставляет интерфейс для Purge, что удобно для настройки модуля, но на production сайте он не нужен и его следует выключить.
Если включить модуль purge_drush то вы сможете увидеть, что происходит с Purge:
drush p:diagnostics # показывает информацию о настройках Purge.
drush p:queue-browse # выводит содержимое очереди.
drush p:queue-volume # выводит количество записей в очереди.
drush p:queue-work # запускает очистку
Ссылки: