Отключить кэш drupal 7
В последнем посте мы рассмотрели какие механизмы кэширования есть в Drupal "из коробки". Мы поняли как Drupal кэширует страницы для анонимных пользователей и нашли решения, позволяющие отдавать кэшированные страницы без загрузки Drupal (используя обратный прокси, например, Varnish или перенаправление запросов при использовании модуля Boost). Также мы увидели, что даже используя эти инструменты кэширования, Drupal также может хранить кэшированны страницы в базе данных. Однако Drupal позволяет прозрачно подключать и другие более быстрые кэширующие бэкенды:
Другой кэширующий бэкенд для Drupal может помочь в ускорении генерации элементов страниц Drupal, таких как блоки, представления и ноды.
Замена кэширующего бэкенда в большинстве случаев достаточно простой процесс, для этого достаточно в файле конфигурации settings.php указать другой кэширующий бэкенд и настройки для него. Например для memcache необходимо добавить следующие строки в settings.php:
Частичное кэширование страниц
- Кэширование содержимого: Ноды могут быть закэшированы при условии что поля выглядят одинакого для различных пользователей.
- Кэширование блоков: блоки могут размещаться на различных участках страницы и могут быть закэшированы глобально, или в привязке к странице, ролям или пользователям.
- Меню и ссылки меню: Вместо сбора информации о меню и ссылках меню на каждом запросе их сериализованные версии могут быть закэшированы и повторно использованы.
- Представления: Представления обычно используются для выборки информации из базы данных и представления ее на страницах Drupal. Модуль Views позволяет кэшировать результаты или промежуточные результаты, которые были запрошены из базы данных и должны быть отображены в представлении. Views caching API достаточно продвинут, чтобы определить в каком контексте представление было отображено: фильтры и аргументы могут влиять на конечный вид представления. Поэтому когда кэширование включено фильтры и аргументы используются как часть ключа кэша для гарантии того что результат кэширования сохранен верно.
- Для каждого запроса модуль определяет может ли страница по этому пути и для этой роли пользователя находится в кэше.
- Если может, то Drupal ищет в кэше корректную версию этой страницы.
- Если нашел, то отправляет эту страницу пользователю, иначе генерирует страницу и сохраняет ее в кэше для следующих запросов.
Autcache дополнительно сохраняет в cookie имя пользователям и email, которые могут быть использованы в шаблоне страницы.
Autcache работает как обертка кэширующего бэкенда, которая отлично интегрируется с другими кэширующими бэендами (Memcache и Cacherouter). Установить модуль можно следующим образом (используемые кэширующий бэкенд будет автоматически определен):
Authcache автоматичиски пытается сделать include для файлов Cache Router или Memcache. Если используется другой кэширующий модуль, то необходимо указать путь к нему, например:
Предотвращение бутстрапа
Обычно, когда используется частичное кэширование, Drupal делает бутстрап для загрузки различных кэшированных элементов, который отнимает процессорное время. Это можно оптимизировать используя ESI (Edge Side Includes) и Varnish: элементы страницы или блоки могут быть загружены при каждой загрузке страницы через внутренний вызов к бэкенд серверу. Это может помочь в ситуациях когда всю страницу можно кэшировать, но некоторые элементы должны кэшироваться по-другому или не могут быть кэшированы, так как изменяются в зависимости от контекста. Есть модули, позволяющие интегрировать ESI c Drupal и отображать несколько типов элементов по url, которые включены в вызовы ESI. В Drupal 8 ожидается, что отображение нескольких элементов через ESI вызовы станет значительно проще. Это одна из главных целей WSCCI
Кэш в Drupal — это промежуточный буфер, хранящий часто запрашиваемые данные, которые могут быть возвращены пользователю с наименьшими затратами системных ресурсов и максимальной скоростью. Этот буфер может представлять из себя таблицу(ы) в базе данных, файл с данными на жёстком диске или набор ключ-значение в сетевом журналируемом хранилище данных. Подойдёт любой вариант хранения информации, который можно интегрировать с PHP для кэширования веб-приложения на Drupal.
Один из примеров использования кэша в Drupal — это кэш меню. В большинстве случаев меню не является часто изменяемой частью сайта. Не имеет смысла каждый раз перестраивать (получать все пункты, их зависимость друг от друга, выводить их в шаблон) меню для вывода пользователю при его заходе на новую страничку сайта. Тем более, что если это меню каталога из 1000 пунктов, оно может перестраиваться для вывода достаточно долгое время. Зачем же заставлять пользователя ждать? Поэтому Drupal кэширует однажды построенное меню на указанное администратором время и выводит его пользователю из кэша, избегая долгой операции по перестраиванию меню.
Drupal содержит встроенный кэш (в своих базовых модулях), который можно настроить на странице: /admin/settings/performance. Нужно не забывать его периодически чистить, когда вы добавляете новую функциональность в каких-либо своих разработках (будь то шаблоны или модули).
- С помощью кнопки «Очистить кэш» на странице /admin/settings/performance
- Установить модуль admin_menu и выбрать в самой левой вкладке Flush all caches (Очистить все кэши)
- С помощью ссылки «Empty cache» (очистить кэш) блока Devel Block (модуль Devel)
- Выполнив команду Drush: drush cache-clear theme (чистится только кэш темы)
- Программно, вызвав функцию drupal_rebuild_theme (чистится только кэш темы)
Кэш Drupal разбит по сегментам, а не хранится в одном единственном месте. По умолчанию каждый сегмент кэша хранится в виде отдельной таблицы в базе данных. Это позволяет выносить часто обновляемые сегменты кэша в другие системы хранения кэша, например в Memcached или Boost. Так же это повышает производительность работы с кэшем — в меньших объёмах данных работа с записями происходят быстрее. Более того, при определённых действиях кэш может очищаться частично (сегментно).
Drupal насчитывает множество различных сегментов кэша. Сегменты кэша похожи для версий 7.XX и 6.XX:
1. — сегмент для общего хранилища кэша. Сюда попадают данные, которые невозможно классифицировать, либо же нет смысла создавать под них новый сегмент кэша.
2. — добавляется при включении модуля Block (входит в ядро). При загрузке региона темы Drupal производится загрузка данных по всем блокам этого региона и при необходимости производится построение блока или отображение его из кэша, пропуская вызов хука hook_block_view(). Стоит учесть, что кэширование для блоков отключается, если включаются модули по работе с доступами к материалу, использующие hook_node_access(). Так же необходимо знать, что при программном создании блока через hook_block_info() можно управлять параметрами кэширования для блока (подробнее — в документации).
3. — модуль Filter создает свою таблицу для хранения кэша для обработанного фильтрами текста. Чем сложнее фильтр, тем больше процессорного времени тратится на обработку текста. Поэтому по возможности все вызовы check_markup() кэшируются. Cache ID для таблицы собирается по правилу название_формата: язык: хэш_текста.
4. — если остальные кэшируемые данные хранятся для ускорения работы сайта, то этот кэш на производительность никак не влияет. Он необходим, чтобы формы, построенные с помощью Forms API, были абсолютно безопасными с точки зрения уязвимостей. Каждый раз при построении формы она сохраняется в сегменте . Если форм и посетителей много, то имеет свойство разрастаться до внушительных размеров, если не запускать cron для очистки кэша каждый час-два.
5. — включается при включении модуля Menu и является хранилищем ссылок из всех меню, созданными через интерфейс. Cache ID строится по правилу links: имя_меню:tree-data: язык: хэш_параметров.
6. — хранит закэшированные данные страниц для анонимных пользователей. Если найден кэш для текущей страницы, то будут вызваны только 2 хука: hook_boot() и hook_exit(). Остальные же хуки (включая hook_init() и прочие) будут пропущены. Это именно тот кэш, который включается на сайте в разделе настроек производительности (admin/config/development/performance) галочкой «Кэшировать страницы для анонимных пользователей».
7. — модуль Update manager добавляет данный сегмент. Он хранит данные по всем релизам для включенных модулей.
Сегменты кэша, имеющиеся в Drupal версии 7.XX (нет в версии 6.XX):
1. — хранит соответствие между системным путём и его алиасами для более быстрого поиска алиаса по системному пути.
2. — зарезервирована модулем Image и может использоваться как хранение сведений о проведении различных манипуляций над изображениями.
3. — сегмент кэша, в котором хранятся данные, инициализируемые при загрузке Drupal.
4. — в данном сегменте хранятся данные по всем полям (fields). Cache ID формируется по правилу field: тип_сущности:id_сущности.
- cache_hacked
- cache_l10n_update
- cache_token
- cache_views
- cache_views_data
Жизненный цикл страницы
При запросе страницы у веб-сервера браузером пользователя происходит следующее (на примере Drupal версии 7.XX):
- DRUPAL_BOOTSTRAP_CONFIGURATION: Инициализирует только конфигурацию.
- DRUPAL_BOOTSTRAP_PAGE_CACHE: Инициализация слоя кэширования.
- DRUPAL_BOOTSTRAP_DATABASE: Инициализация слоя базы данных.
- DRUPAL_BOOTSTRAP_VARIABLES: Инициализация слоя переменных.
- DRUPAL_BOOTSTRAP_SESSION: Инициализация работы с сессиями.
- DRUPAL_BOOTSTRAP_PAGE_HEADER: Инициализация слоя работы с заголовками.
- DRUPAL_BOOTSTRAP_LANGUAGE: Инициализация слоя работы с языком страницы.
- DRUPAL_BOOTSTRAP_FULL: Полностью загружает Drupal. А также добавляет функции проверки и исправления введенных данных.
- Подключение файлов системных функций.
- Инициализация всех слоёв и первичных настроек.
- Подключение файлов всех включённых модулей.
- Инициализация переменных и системных функций для работы с путями и их алиасами в Drupal.
- Инициализация включённой темы оформления.
- Производится выполнении module_invoke_all(). Реализует API для загрузки и взаимодействия с модулями Drupal, регистрируя все хуки текущих включённых модулей.
- Функции drupal_deliver_html_page(), которая возвращает данные страницы в виде HTML в браузер пользователя. Внутри этой функции вызывается функция drupal_render(), которая не только выводит данные, но и сохраняет в один из сегментов кэша и достаёт их оттуда при их наличии вместо повторной генерации страницы с использованием шаблонизатора.
- Функции drupal_page_footer(), которая устанавливает кэш страницы ('cache_path' и 'cache_bootstrap'), если это необходимо, и позволяет модулям реагировать на закрытии страницы по hook_exit (). Тут же при необходимости производится запуск Cron.
- Производится инициализация всех необходимых переменных и функций.
- Производится проверка, имеется ли кэш по данному URL (). Если имеется, то он возвращается, иначе производятся дальнейшие действия.
- Производится проверка имеется ли кэш полей (), контента (), меню (), блоков (), а так же изображений () и алиасов (). Если кэш не имеется, то производится операция по получение и обработки необходимых данных с сохранением в кэш. Полученные данные передаются в функцию темизации.
- Функция темизации строит страницу и кэширует её по данному URL ().
- Данные возвращаются пользователю.
Самым распространённым вариантом работы с кэшем является сохранение данных разрабатываемого модуля в кэш используя функцию cache_set. А также извлечение их из него, используя функцию cache_get.
Очистить данные кэша с именем my_module_data можно, вызвав одну из функций:
Drupal позволяет создавать свои сегменты кэша для хранения данных. Создадим для этого модуль: mymodule. Для этого в каталоге сайта: ./sites/default/modules создадим папку: mymodule. В ней создадим файл описания модуля mymodule.info с содержимым:
Так же создадим файл mymodule.install в котором, используя hook_schema(), создадим новую таблицу для хранения данных своего сегмента кэша:
Существует малоизвестная функция cache_is_empty, с помощью которой можно узнать, хранятся ли в кэше с заданным именем какие-либо данные:
Вынесение кэша из базы данных
Кэш сегментов можно перенести, например в Memcached или Redis.
В данной статье рассмотрим вынесение кэша в Redis, который мне нравится более простой настройкой по сравнению с Memcached. А сравнительные тесты скорости обоих хранилищ рассмотрим в другой статье.
Не забывайте читать файл README.txt в папке модуля, так как в нём описаны все настройки модуля.
Где это можно применить?
Один из вариантов применения описанных знаний вынесение части данных сайта в блоки загружающиеся после основной загрузки страницы, как для ускорения загрузки сайта, так и для общего ускорения работы сайта. Достаточно лишь взять за основу модуль Ajax Blocks, интегрировать его с модулем High-performance JavaScript callback handler, а кэш данных поместить в своё хранилище в Redis, используя данную статью.
На платформе разработки кеширование может быть болезненным. Могу ли я выключить его? Будет ли это влиять на любой из модулей, которые требуют этого?
Установите модуль devel, который добавляет опцию очистки кеша для администраторов. Вы найдете блок devel для добавления в регион для быстрой очистки кэша, или если вы установите меню администратора и получите быстрое меню в верхнем левом углу для очистки различных кэшей в Drupal.
Если вам нравится командная строка, установите drush и используйте drush cc all команду для очистки кэшей ваших сайтов. Помните, что в настоящее время drush cc не очищает кэш Varnish, если это применимо к вашей настройке.
Если вы используете Drupal 7, вы всегда можете настроить кеширование на использование DrupalFakeCache, который обычно используется только в процессе установки. Чтобы установить это, добавьте следующий фрагмент кода в файл settings.php:
Модуль «Меню администрирования» обеспечит ярлык на панели инструментов, если очистка кеша должна выполняться более регулярно - во время разработки темы я постоянно сбрасываюсь.
Насколько я знаю, нет никаких модулей, которые требуют кэширования. Если вы не хотите выключать его, вы можете очистить его в Site Settings > Performance разделе.
Даже если кэширование отключено, Drupal не будет распознавать новые файлы, добавленные в темы, пока вы не очистите кеш.
В дополнение к методам, упомянутым Стивом Х , использование модуля Devel открывает еще несколько опций, в том числе:
- Восстановление кеша темы при каждой загрузке страницы (полезно, если вы работаете с файлами шаблонов)
- Блок, который обеспечит легкий доступ к пустой функции кэша и функции переустановки.
Когда модуль Devel и кеширование отключены в разделе « Производительность» , единственным другим основным кешем, с которым вы столкнетесь при рутинной разработке, является маршрутизатор меню, который можно перестроить, используя Devel или Admin Menu, как упоминал Стив.
Важно отметить, что если у вас много таблиц стилей (из вашей темы или из модулей), то отключение оптимизации CSS-файлов может привести к поломке вашего сайта в IE.
Хотя на самом деле это не кэширование, оно находится на той же странице настроек и часто используется с кэшированием.
Кстати, ссылка «Сбросить все кэши» в модуле админ-меню просто фантастическая.
Если вы используете Drupal 6, модуль « Cache Disable » может быть полезен для этой задачи, если вы не хотите [по какой-то причине] устанавливать более тяжелые модули, такие как Devel.
Старый вопрос, но я просто увидел, что он всплыл как связанный с поиском, который я проводил.
Почти все методы очистки кэша в конечном итоге вызывают drupal_flush_all_caches . Вы можете поиграть с этим при различных обстоятельствах в своем собственном коде.
Количество кэшей, используемых с Drupal, иногда может сойти с ума.
Вот общие методы отключения и очистки кешей Drupal и связанные с ними.
ОТКЛЮЧЕНИЕ КЕШОВ:
Обратите внимание, что вы не можете отключить все кэши, так как некоторые из них требуются Drupal.
Вот метод отключения кэшей, добавив следующие строки в ваш файл настроек:
Если вы отключите все свои кэши, ваш веб-сайт будет работать очень медленно, поэтому он не рекомендуется использовать в других средах, кроме вашей машины для разработки.
ОЧИСТКА КЭШОВ
XCache
Очистить кеш XCache, если используется:
Или очистите кэш в XCache в панели администратора (/ xcache-admin), если выше не будет работать.
Eaccelerator
APC
OPCache
Очистить PHP OPCache при использовании с PHP> = 5.5
Примечание. Команда выше CLI не очищает кэш для Apache, как указано ниже : Opcache - Очистить кэш в PHP5.4 и ниже .
Memcached
Если вы используете memcached, вы должны очистить, перезапустить или убить свою memcached одним из методов:
Как пользователь (один из них):
Как корень (один из них):
Также рекомендуется установить модуль memcached со следующей строкой в вашем файле настроек:
Таким образом, кэши Memcached очищаются на стандартном кеше очистки Drupal.
лакировка
Если вы используете Varnish, рекомендуется установить модуль Varnish и установить следующую строку в файле настроек:
Таким образом, кеш Varnish будет очищаться вместе на кеше Drupal clear.
В качестве альтернативы вы можете использовать curl для очистки страниц вручную:
Drupal
Очистить кеш Drupal через drush:
Вы можете сделать то же самое в / admin / config / development / performance, поскольку иногда кэши пользовательского интерфейса очищаются лучше, чем из CLI.
Вот полезный скрипт оболочки для очистки всех кешей:
мы можем использовать один из следующих методов, чтобы очистить кеш в drupal
1.) Мы можем просто зайти по URL-адресу your_domain / admin / config / development / performance и нажать кнопку очистки кэша.
2.) Если у нас установлен модуль drush, мы можем очистить кеш этой командой drush cc all .
3.) Если у нас есть доступ к базе данных, мы можем очистить кеш с помощью следующих команд (прямой доступ к производственной базе данных категорически не рекомендуется; вместо этого используйте одну из альтернатив, если ваш сайт «живой»)
Кеш TRUNCATE TABLE;
TRUNCATE TABLE cache_block;
TRUNCATE TABLE cache_bootstrap;
TRUNCATE TABLE cache_field;
TRUNCATE TABLE cache_filter;
TRUNCATE TABLE cache_form; // обратите внимание на важные отличия от других таблиц cache_ * - см. дополнительную информацию ниже
TRUNCATE TABLE cache_image;
TRUNCATE TABLE cache_menu;
TRUNCATE TABLE cache_page;
TRUNCATE TABLE cache_path;
TRUNCATE TABLE cache_token;
TRUNCATE TABLE cache_update;
4.) Мы также можем написать запрос в файле нашего модуля db_query ("DELETE FROM ;");
5.) Мы можем использовать drupal api для очистки кеша, например cache_clear_all ()
6.) Мы также можем очистить кеш с помощью модуля devel, установить модуль devel и включить «Блок разработчика / разработки», этим мы можем очистить кеш
Больше информации о cache_form, которая имеет другое назначение по сравнению с другими таблицами cache_ :
В основных документах API для drupal_flush_all_caches () сказано: «Не очищать cache_form - отправка форм в процессе выполнения может прерваться». Это относится только к сайтам с активными пользователями, а не к версиям для разработчиков.
другие ручные методы очистки кэшей, описанные в этом посте, не влияют на cache_form
если вам нужно уменьшить размер cache_form на рабочем сайте, см. Размер таблицы Cache Form огромен
Эффективно, как вы инструктируете конечного пользователя очистить свои кеши?
ОТВЕТЫ
Ответ 1
Когда вы регистрируетесь как администратор (очевидно, что не каждый пользователь сайта должен отключить кеш), должна быть страница в "Администрирование" > "Конфигурация сайта" > "Производительность".
И в нижней части страницы должна быть кнопка (что-то вроде "Очистить кэшированные данные" ), чтобы очистить кеш
Насколько я помню, нет необходимости в Devel для этого, и вам действительно не нужно заходить в базу данных и не запускать собственный PHP-код.
В качестве справочной информации вы можете взглянуть на Как очистить кэш на стороне сервера Drupal
Ответ 2
Вы также можете использовать модуль Drush, который позволяет вам использовать командную строку для выполнения популярных команд Drupal, таких как "drush cron" или "очистить кеш очистить".
Ответ 3
Если вы хотите очистить кеш от модуля, вы можете использовать следующий код.
Ответ 4
Ответ 5
Ответ 6
Очистка по требованию может быть выполнена при администрировании > Конфигурация сайтa > Производительность.
Вы должны настроить задание cron для запуска каждый час (или любой другой интервал по своему усмотрению).
Когда cron запускается на Drupal, все кеши очищаются и перестраиваются без необходимости вручную делать это.
Если этот вопрос относится к тематике, вы должны отключить механизмы кэширования (css/js aggregation), и вам не придется очищать данные кэша при внесении изменений.
Ответ 7
Это помогло мне, потому что у меня были проблемы, при которых очистка кеша в разделе "Конфигурация" > "Эффективность", похоже, не помогла.
Ответ 8
Вышеприведенный код предназначен для Drupal 6.
Для Drupal 7 модуль очистки кэша будет выглядеть следующим образом:
Примечание: вы затем очистите его, перейдя к:
Убедитесь, что вы предоставили им разрешение на странице разрешения. Очистите кеш "обычным" способом, если разрешение не появляется после включения модуля.
Это предпочтительнее, если вы не хотите, чтобы ваш клиент получал доступ к меню администратора, но вы все еще хотите, чтобы они могли очистить кеш.
Ответ 9
Мне пришлось снять установку модуля "devel" (это было несовместимо со специальными пунктами меню, которые мне еще хуже), поэтому я сделал свой собственный.
В любом месте, где вы видите MODULENAME, замените его на имя вашего модуля.
ШАГ 1: Добавьте в любой модуль (предпочтительно один из ваших настраиваемых модулей) в HOOK_MENU перед строкой "return $items":
ШАГ 2: Теперь, в том же файле модуля, где он не "внутри" любой другой функции, добавьте:
Теперь вы можете просто перейти к URL-адресу/флеш-кешу на своем сайте, чтобы очистить кеш. (После того, как вы очистите кеш в последний раз старым способом.)
ШАГ 3: Если вы хотите, чтобы это было ДЕЙСТВИТЕЛЬНО удобно, добавьте следующее в свой файл page.tpl.php. Вы можете поместить его почти где угодно между <body> и </body> . ПРИМЕЧАНИЕ. $My_is_test - это переменная, которую я использую в TRUE для моей тестовой системы, и FALSE в производстве. Если у вас нет чего-то подобного, замените его TRUE или FALSE, чтобы включить или выключить его:
И вуаля! У вас есть ссылка "flush" в верхнем правом углу каждой страницы, на которую вы можете щелкнуть. Не стесняйтесь изменять "правильные" и "верхние" суммы (или менять "право" на "левый" или "верхний" на "снизу", чтобы поместить их туда, где вам это нравится. Это позиционирование ссылок работает только в современных браузерах, но оно только для вас, так что это не должно быть проблемой, верно?
Ответ 10
Следующий модуль создает элемент меню, доступный только пользователям с разрешением "флеш-кеш", который этот модуль предоставляет на странице обычных прав пользователя.
Ответ 11
В Drupal 8 модуль меню администратора еще не готов к использованию. И это, вероятно, заменит Drupal "Панель инструментов". Поэтому прямо сейчас нет простого способа очистить кеш, фактически не получив:
Единственная альтернатива - добавить элемент меню в существующую панель инструментов. Это можно сделать, используя этот модуль, но, как вы можете видеть, все еще требуется небольшая работа. Я заработал, но должен был сделать несколько настроек.
Ответ 12
используйте drush и эту команду: drush cc all
Если вы используете Boost для кеширования, вам нужно быть более конкретным:
Кэширование Drupal 7 может быть реализовано с помощью Varnish или любого другого кэширующего reverse proxy сервера, главное правильно настроить.
Этот пост является переводом отличной статьи с dev.nodeone.se, в которой описано как можно контролировать актуальность кэша Varnish на Drupal сайте, используя модули Varnish, Expire, Cache Actions.
Использование Varnish позволяет существенно ускорить сайт на Drupal. Drupal 7 позволяет работать с кэширующими reverse proxy серверами из коробки и интеграцию Varnish и Drupal 7 можно сделать с помощью модуля Varnish.
Настройка Drupal для работы с Varnish
У нас есть новая установка Drupal 7 и настроенный Varnish перед ним. Необходимо в Drupal сделать некоторые настройки для работы с Varnish:
Теперь можно посмотреть заголовки ответа при открытии страниц нашего сайта. Сделать это можно используя firebug в браузере Firefox или "Средства для разработки" в Chrome/Chromium (Ctrl+Shift+J). Если все правильно настроено, то заголовки должны выглядеть примерно следующим образом:
Обратите внимание на заголовок Cache-Control. Этим заголовоком Drupal информирует, что страница закэширована на 86400 секунд (на 1 день). Если у вас не установлен этот заголовок (возможно с каким-то другим значением) значит где-то ошиблись с настройкой кэширования.
Также обратите внимание на заголовок X-Varnish. Если в него записаны 2 значения, значит страница выдана из кэша Varnish.
Не беспокойтесь, что заголовоко X-Drupal-Cache имеет значение MISS. Это значение будет всегда, когда страницы будут выдаваться из кэша Varnish.
Обновление кэша
Мы настроили Varnish и Drupal. Кэш будет автоматически обновляться по истечении установленного в настройках Drupal времени. Но этого недостаточно, если вы хотите, чтобы пользователи получали новый контент сразу, как только вы его добавили, обновили или удалили.
Встроенное в Drupal кэширование работает следующим образом:
- Все страницы сохраняются в кэше Drupal (таблица cache_page) после первого посещения.
- Если не установлен параметр "Минимальное время жизни кэша", то весь кэш сбрасывается, как только происходит добавление/обновление/удаление материала. Этот параметр позволяет хранить кэш заданное количество минут.
Но встроенное кэширование не работает с Varnish, потому что в Drupal нет встроенной возможности сообщить Varnish об изменении контента. Модуль Varnish позволяет нам решить эту проблему. Этот модуль позволяет Drupal взаимодействовать с Varnish через порт для администрирования, по умолчанию 6082.
Для установки модуля Varnish необходимо:
- Установите модуль varnish.
- Перейдите на страницу настройки модуля Varnish (admin/config/development/varnish) и установите следующие параметры:
Модуль Varnish использует возможность Drupal называемую "Cache backend", которая позволяет заменить встроенный функционал кэширования на другую реализацию. Для того, чтобы модуль начал работать необходимо добавить в файл settings.php следующие строки:
Теперь модуль Varnish работает и для проверки можно сделать следующее:
- Открыть страницу под анонимным пользователем, и, посмотрел на заголовки, убедиться, что страница загружена из кэша Varnish.
- Изменить эту страницу.
- Обновить открытую в браузере страницу под анонимным пользователем. Эта страница должна обновиться и она будет закэширована после первого просмотра.
В результате мы получили функционал встроенного в Drupal кэширования, используя Varnish.
Расширенное использование
Встроенный в Drupal функционал кэширования работает отлично для небольших Drupal сайтов с небольшим количеством посетителей, но если на вашем сайте большое количество посетителей, то скорее всего вы захотите изменить этот функционал. Сброс кэша для всего сайта может быть критичным для больших сайтов. Простейший способ выхода из этой ситуации — установить параметр "Минимальное время жизни кэша", это позволит не слишком часто сбрасывать весь кэш, но тем не менее кэш будет сбрасываться полностью.
Выходом из этой ситуации является:
- Использование модуля Cache Expiration. Этот модуль интегрирован с модулем Varnish и удаляет из кэша страницы, на которых присутствует измененный контент. В этом модуле реализована логика работы модуля Boost по удалению кэша. Модуль Expire находится в стадии активной разработки, поэтому есть вероятность столкнуться с проблемами и придется обращаться за помощью на форум к разработчикам.
- Использование модуля "Cache actions", который позволяет удалить кэш страницы конкретного нода, после его изменения. Этот модуль позволяет создавать правила удаления кэша с использованием модуля Rules.
Для настройки Cache actions для удаления кэша страницы нода, после изменения нода необходимо:
- На странице настройки Varnish (admin/config/development/varnish) выбрать "none" для параметра "Varnish Cache Clearing". Это позволит не сбрасывать весь кэш, при изменении материалов на сайте.
- Установить и включить модули "Cache Actions" и "Rules UI".
- На странице admin/config/workflow/rules создать новое правило.
- В поле "Реакция на событие" выбрать "После сохранения нового документа".
- Добавьте действие (action) "Clear a specific cache cid".
- В параметре "CACHE BIN" укажите "cache_page".
- В поле "CACHE KEY" впишите node/[node:nid].
Попробуйте отредактировать какой-нибудь нод, все должно работать. Сейчас разница в том, что из кэша удалена не вся страница, а только запись конкретного измененного нода. Вы можете попробовать открыть другую страницу и убедиться, что она все еще кэширована, посмотрев заголовки.
Другие решения
Читайте также: