Drupal 8 очистить кэш вручную
От автора: приветствую Вас друзья. Скорость загрузки сайта – довольно важный параметр, потому как в современном изобилии всевозможных интернет ресурсов, пользователи просто не желают ждать загрузку тяжеловесного веб-сайта. Поэтому разработчики после создания своего проекта, всячески пытаются ускорить его работу, применяя различные известные методы. Одним из таких методов, является кэширование, а значит в данной статье, мы с Вами поговорим о том, как в Drupal очистить кэш.
Кратко хотелось бы напомнить Вам что кэширование – это процесс сохранения информации о веб-страницах сайта в специальный промежуточный буфер, под названием “Кэш” (Сache), который обладает сравнительно большим быстродействием. Но Вы можете спросить, каким образом подобное сохранение позволяет ускорить процесс работы сайта? Смотрите, пользователь, запрашивая отображение конкретной страницы на экран – отправляет запрос к нашему сайту, который попадает в главную точку входа. Далее запрос попадает в подходящий контроллер для последующей обработки. При этом при необходимости реализуется предварительная обработка данных – валидация, приведение к нужному виду, возможно запрос вспомогательных данных, или просчет некоторых дополнительных параметров. А затем, используя модель, из базы данных выбирается необходимая информация из соответствующих таблиц, которая так же после, может обрабатываться, для передачи дальше в вид – шаблон. То есть, как Вы видите, для того что бы отобразить необходимую страницу на экране пользователя, CMS Drupal выполняет множество всевозможных операций. Но, так или иначе, пользователи запрашивают одни и те же страницы проекта, а значит используя кеширование, готовые к отображению страницы, сохраняются в буфер (в память с быстрым доступом) и при запросе сразу же в виде ответа, отдаются “пользователю”.
Таким образом, не выполняются запросы по выборке информации и что важно, данные заново не формируются, так как они уже подготовлены и готовы к использованию, что значительно ускоряет загрузку приложения. При этом информация, сохраняемая в кэш, записывается на строго определенное время – время жизни кэша, так как сайт – это динамический ресурс и его контент изменяется, то есть, что то добавляется, что то удаляется и нельзя кэшировать навсегда, абсолютно все его страницы, или элементы, так как изменения просто не будут видны. Поэтому для различных элементов сайта выбирается отличное время кэширования, к примеру, блок с меню можно кешировать на более продолжительное время, нежели блок последних записей. Так как содержимое последнего будет изменяться в зависимости от добавления новых материалов.
Причем, обратите внимание, что на этапе разработки кэширование, может сыграть злую шутку с разработчиком, потому как добавляя изменения на сайт, из за того что страницы сохранены в кэше, он может не увидеть добавленных изменений, что само собой приведет, к затратам времени на поиск и определение проблемы происходящего. Поэтому Вы всегда должны помнить о кэше и при внесении изменений, постоянно его очищать, таким образом, обновляя базу сохраненных элементов проекта.
В стандартную комплектацию движка встроен механизм кэширования, который можно включить работу, в разделе “Конфигурация” на странице “Производительность”.
Бесплатный курс «Создание тем на WordPress. Быстрый старт»
Изучите курс и узнайте, как создавать уникальные темы на WordPress с нестандартной структурой страниц
Для включения вышеуказанного механизма, достаточно в выпадающем списке “Page cache maximum age”, выбрать время кэширования элементов и нажать по кнопке “Сохранить конфигурацию”. Повторюсь, что время кэширования зависит от того как часто меняется контент Вашего сайта.
Здесь же присутствует и кнопка, при помощи которой осуществляется очистка устаревшего кэша.
Но перед тем как ее использовать, давайте внесем небольшие изменения в шаблон нашей страницы. Для этого, если используется стандартная тема “Bartic”, переходим по адресу /core/themes/bartik/templates/ и открываем в текстовом редакторе макет страницы – файл page.html.twig, в который добавим небольшое изменение.
Теперь перейдем в пользовательскую часть и обновим страницу.
Как Вы видите, изменений нет, так как страница сохранена в буфере, и необходимо его сбросить. Для этого воспользуемся уже известной нам кнопкой и снова обновим страницу пользовательской части.
Теперь все отлично, указанные правки видны на сайте.
Теперь Вы знаете, как работать с кэшем, причем для примера я использовал версию 8, движка, но в Друпал 7, работа с рассматриваемым механизмом реализована абсолютно аналогично.
И напоследок, хотел бы уточнить, что более подробно разделы конфигурации, рассмотрены в премиум курсе Курс по Drupal. Основы. На этом данная статья завершена. Всего Вам доброго и удачного кодирования.
Бесплатный курс «Создание тем на WordPress. Быстрый старт»
Изучите курс и узнайте, как создавать уникальные темы на WordPress с нестандартной структурой страниц
Knowing how to clear Drupal's cache is an important skill for any developer. You'll likely find yourself doing it frequently in order to get Drupal to register the changes you make to your code, or other updates you make via the UI. It is also a good first step to trouble shooting problems with your Drupal site: Clear the cache before you do any other debugging to ensure it's not just a bad cache entry.
Learn three methods of clearing Drupal's cache: via the administrative UI, with Drush, and by truncating tables in the database.
Плюшки, фантики и печеньки
Перепроверьте правильность всей конфигурации. Узнать об этом будет куда больнее от клиента в 2 часа ночи, чем сразу после внесения изменений. Поверьте моему опыту интуиции.
Размер очереди на инвалидацию
На странице /admin/config/development/performance/purge присутствует некоторый текущий статус. В частности, обратите внимание на счетчик Queue size. Он показывает текущую длину очереди на инвалидацию кеш тегов – это количество кеш тегов, которые уже инвалидировались в Drupal’e, но еще не были инвалидированы в Varnish’e.
Если вы используете инвалидацию через cron, убедитесь, что это число падает до нуля после запуска cron’a.
Если же у вас используется “Late runtime processor”, то вам следует ожидать ненулевые значения лишь периодически. Слишком высокая цифра, либо длительно не спадающая до 0 будет признаком каких-то проблем.
Еще раз о Cache API в Drupal 8
Описанное в статье — это лишь малая часть того, как используется cache API в Drupal 8. Я лично считаю Cache API главным новведением по сравнению с Drupal 7. Если у читателей есть интерес, то я могу написать следующую статью, где рассмотрю глубже вопросы внутреннего устройства cache API; как кеширование переплетается с рендерингом в Drupal 8.
Prerequisites
Варианты
- Очистка через Админ-часть сайта
- Очистка кеша модуля Views
- Очистка таблиц в базе данных
- Очистка кеша прав доступа
- Очистка кеша PHP-сниппетом
- Очистка кеша с помощью модуля devel
Run the command drush cache-rebuild ( drush cr )
Wait for the command to successfully execute and return to your site.
Recap
In this tutorial, you learned three methods for clearing Drupal's cache: via the administrative performance page at admin/config/development/performance, with drush cache-rebuild or drush cr , and by truncating cache_ tables in the database.
Очистить кеш нужно с таких случаях:
What's the difference between cache-clear and cache-rebuild?
You may have been used to using "drush cc all" aka drush clear-cache . Now it's drush cache-rebuild or drush cr , for short. What's the difference and why the change?
Caching is widespread in Drupal and creates many interdependencies. Improperly or incomplete cache flushing operations can cause the site to fatally error. In order to guarantee that old data is properly flushed and the site stays up and running, drush cache-rebuild both rebuilds or re-bootstraps the Drupal site in addition to clearing the cache. Additionally, the Drush command cache is cleared with drush cache-rebuild , since that was one of the caches included in the old drush cache-clear command.
Drush's cache-rebuild command does the following:
- Clears the APC cache
- Bootstraps Drupal
- Calls drupal_rebuild()
- Clears the Drush cache (to maintain consistency with Drupal 7's drush cache-clear command)
If you'd like to take a peek under the hood of Drush's rebuild method, check out drush/src/Commands/core/CacheCommands.php (line 179).
Reload the page you were working on in your browser
It might take a bit longer than usual since the cache has been rebuilt.
Расширяем Cache API на Varnish
- Purge (purge)
- Purge Drush (purge_drush)
- Purge Tokens (purge_tokens)
- Purge UI (purge_ui)
- Cron processor (purge_processor_cron) или Late runtime processor (purge_processor_lateruntime). О разнице между этими 2 модулями чуть позже.
- Core tags queuer (purge_queuer_coretags)
- Varnish Purger (varnish_purger)
- Varnish Purger Tags (varnish_purge_tags)
Очистка таблиц в базе данных
Лучше вносить изменения, когда посетителей мало или перевести сайт в режим "Обслуживание".
Очистка таблиц оператором TRUNCATE
Очистка таблиц оператором DELETE
Оператор выполняется оень медленно.
Таблицы кеша Drupal 6
- cache
- cache_block - кеш блоков
- cache_content - кеш нод
- cache_filter - кеш форматов ввода
- cache_form -кеш форм
- cache_menu - кеш меню
- cache_page - кеш страниц
- cache_update - кеш обновлений модулей (модуль update status)
Таблицы кеша Drupal 5
- cache
- cache_advcache_block -кеш модуля advcache_block
- cache_block - кеш блоков
- cache_comment -кеш комментариев
- cache_content - кеш контента
- cache_filter -кеш фильтров ввода
- cache_forum -кеш модуля Forum
- cache_menu - кеш меню
- cache_node - кеш нод
- cache_page - кеш страниц
- cache_path - кеш синонимов URL
- cache_search - кеш поиска
- cache_taxonomy - кеш таксономии
- cache_views -кеш модуля Views
- cache_workflow_ng -кеш модуля
Очистка кеша PHP-сниппетом
$core = array( 'cache' , 'cache_content' , 'cache_filter' , 'cache_menu' , 'cache_page' , 'cache_views' );
$alltables = array_merge ( $core , module_invoke_all ( 'devel_caches' ));
foreach ( $alltables as $table ) cache_clear_all ( '*' , $table , true );
>
print( t ( 'Cache cleared.' ));
?>
Очистка кеша модуля Views
Комментарии
все вышесказанное есть происки империалистов.
только крон по событию спасет отцов русской друпал-коммюнити.
Влад TRUNCATE TABLE `cache_table_name`- поправь, если mysql позволяет опускать тип объекта - это не повод в статье не писать в формате ansi-sql!
а что вернее использовать? delete * from table `cache_table` так?
delete from table
оно очень медленное, лучше вносить изменения когда посетителей мало
ну это само собой, просто насколько знаю, truncate - чисто mysql инструкция, и в SQL'92 ее нет
По законам жанра надо было написать список кар, которые ждут пользователей, не очистивших кэш. Ведь если ничего страшного не будет, то зачем очищать кэш?
А зачем такой огромный анонс на главной?
Вопрос не по очистке, а наоборот по созданию: минимальное время жизни кэша какой выставлять (на сайте с посещаемостью 1посетитель/секунда, 1/минута, 1/час, 1/день?
Внёс исправления в статью. Спасибо за советы.
То, что статья на главной - я думал, что это фишка нового дизайна: типа все новые статьи на главную выводить.
В типе материала указано было по умолчанию публиковать на главной.
Лично я не считаю, что это статья для главной страницы. Если это не общесистемная настройка, то статью нужно убрать с главной.
Лично я не считаю, что это статья для главной страницы. Если это не общесистемная настройка, то статью нужно убрать с главной.
Да так, мне веник понравился, вот и ткнул вынос на главную
По законам жанра надо было написать список кар, которые ждут пользователей, не очистивших кэш. Ведь если ничего страшного не будет, то зачем очищать кэш? ;)
Если ситуация, когда нужно очистить кеш не возникает, то и кеш чистить лишний раз не нужно. А вообще, к чистке кеша приводят проблемы с сайтом. Я в разделе "Задача" попытался описать известные мне случаи, когда очистка кеша может помочь.
Кэш в 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, используя данную статью.
Еще во времена Drupal 6 и 7 с помощью Varnish’а было очень удобно кешировать статические ресурсы (рисунки, CSS, JavaScript файлы). Но были пробемы с кешированием HTML страниц – не существовало удобного механизма выборочной инвалидации кеша. Оставалось только либо сознательно отдавать устаревший кеш, либо полностью очищать кеш в Varnish при каких-либо изменениях в Drupal. Оба подхода имели свои недостатки.
Если при каком-либо изменении в Drupal’е вы не инвалидировали кеш Varnish’а, то нужно было ставить относительно маленький TTL, чтобы кеш Varnish’а достаточно быстро устаревал и Varnish обновлял свой кеш новыми данными из Drupal’а.
C другой стороны, если вы на “каждый чих” в Drupal, очищали кеш Varnish’а, то зачастую эти меры оказывались избыточными. Какой-нибудь юзер мог написать безобидный комментарий под малопосещаемой страницей, и это приводило к инвалидации всего кеша Varnish’а (в том числе и очень посещаемых страниц, которые на самом деле не поменялись из-за добавленого комментария).
Дебаггинг информация в Drupal watchdog
На странице /admin/config/development/performance/purge вы можете настроить необходимый уровень логирования в watchdog Drupal’a. Очень полезно, когда нужно идентифицировать проблему.
Add Performance page to Shortcuts
Depending on your role, you may be clearing the cache a lot! Add the Performance page to your Shortcuts so that you can access the page more quickly. Click on the star icon next to the title, "Performance". The star icon will change from an outline of a star to a filled-in yellow star. Access Shortcuts via the Admin Toolbar.
Overview
There are two common ways to clear Drupal's cache: via the UI, or with Drush.
Очистка кеша прав доступа
Открыть в браузере страницу: admin/content/node-settings/rebuild (Drupal 6)
Drupal 8 Cache API
К счастью, дела обстоят куда лучше в Drupal 8, где была добавлена система гибкого кеширования через мета-информацию. Я настоятельно рекомендую любопытным почитать официальную документацию. Вкратце, эта система позволяет Drupal’у отслеживать от чего (ноды, комментарии, конфиги и т.д.) зависит сгенерированная страница. Каждая страница ассоциируется с набором кеш тегов (cache-tags). Затем, при любом изменении состояния, Drupal распознает какие кеш теги необходимо инвалидировать. Это в свою очередь позволяет Drupal’у инвалидировать лишь минимально необходимый набор закешированых страниц, когда что-то (нода, комментарий, конфиг) изменилось. Именно такой подход используется в ядре Drupal’а для инвалидирования внутреннего кеша. С помощью пары ловких движений можно добиться схожего “минимально необходимого” инвалидирования в кеше Varnish’a.
Select the "clear all caches" button
After successfully clearing the cache Drupal should display the message "Caches cleared."
Настройка Drupal 8
На вкладке Headers:
Добавьте заголовок Cache-Tags c содержимым [invalidation:expression]. Это токенизированное выражение будет заменено на значение инвалидированного кеш тега модулем Token.
Остальное можно (и нужно) конфигурировать под ваш вкус и конкретную ситуацию. Теперь Drupal будет включать заголовок Cache-Tags во все свои ответы, куда будет вписывать список кеш-тегов, участвовавших в формировании сгенерированной страницы. Varnish будет хранить эти заголовки, как часть своего кеша и будет их использовать для инвалидации кеша.
В этом месте удостоверьтесь, что ваш Drupal при запросе напрямую (минуя Varnish) действительно содержит Cache-Tags заголовок. В моем случае он выглядит вот так для первой попавшейся страницы:
По умолчанию, Drupal отвечает Cache-Control: private, no-cache (т.е. запрещает кеширование) на все HTML ресурсы, которые он генерирует. Это значит, что Varnish не будет их кешировать. Нужно включить внешнее кеширование в настройках Drupal’а. Перейдите на страницу /admin/config/development/performance и выберите ненулевое значение для Page cache maximum age.
Я рекомендую начать с какого-нибудь безобидного 5-минутного кеша, и только когда все отлажено и успешно обкатано, переходить на полномасштабные значения длиной в часы либо дни.
Опять же, перепроверьтесь – запрашивая страницу Drupal’a анонимным пользователем, вы должны увидеть в ответ: Cache-Control: public, max-age=[ненулевое время жизни кеша] . А при запросе от имени авторизированного пользователя, в ответ должен прилететь Cache-Control: private, no-cache . Таким образом мы разрешили Varnish’у кешировать анонимные и только анонимные HTML страницы.
Open a Terminal window and cd to your Drupal site root
If you're using Drush aliases, you can skip this step.
Использованные материалы
Cache hit в Varnish’е
Не нужно верить теории. После проделанной работы, лучше перепроверить на практике факт, что Varnish правильно кеширует анонимные HTML страницы! Если ваш Varnish изначально не вставляет заголовки о cache hit в свои ответы, то достаточно добавить в vcl_deliver:
Удостоверьтесь на практике, что запрашивая страницу от анонимного пользователя, Varnish ее закешировал (со второго раза он должен отвечать заголовком X-Varnish-Cache: HIT ). В этот момент спровоцируйте инвалидацию исследуемой страницы в Drupal’е – почистите кеш Drupal’a либо пересохраните ноду (если вы анализируете страницу какой-нибудь ноды) и т.п. Не забудьте запустить cron Drupal’a, если он ответственен за инвалидацию кеша в Varnish’e.
Повторите запрос на исследуемую страницу. Первый ответ должен содержать заголовок X-Varnish-Cache: MISS — таким образом вы подтвердите, что Drupal успешно уведомил Varnish об инвалидации необходимых кеш тегов, и последний успешно обработал полученный запрос на инвалидацию.
Сайты на Drupal 8 очень часто могут оказаться громоздкими. В частности это может вылиться в длинный список кеш тегов, ассоциируемых с определенной HTML страницей. Многие вебсервера и вообще Webserver + PHP стек в разных реализациях может иметь ограничение на максимальную длину заголовков ответа. Об это действительно можно споткнуться. Причем, если тестовое окружение имеет тестовый (урезанный) набор данных, то проблема всплывет только на живом окружении. Лечить проблему нужно в зависимости от того, как у вас развернут стек.
Решение
Стандартно кеш хранится в базе данных, если вы не применяли кеш в файлах.
Канал коммуникации Drupal → Varnish
Clearing the cache via the UI
Go to the Performance administrative page
In the Manage administrative menu, navigate to Configuration > Performance (admin/config/development/performance).
Очистка через Админ-часть сайта
Drupal 6
- Откройте страницу "Производительность" (admin/settings/performance)
- Нажмите внизу кнопку "Clear all cache data" ("Очистить все кешированные данные")
Drupal 5
Truncate cache-related database tables
Another method of clearing the cache is to truncate--or clear all the data from--the cache-related database tables. These are all the tables that begin with "cache_" (after the site-specific table prefix, if there is one).
In a SQL GUI application like Sequel Pro, which is what I like to use, this is easily accomplished by connecting to the server, selecting your site's database, highlighting all of the tables beginning with cache_ , ctrl-clicking and selecting Truncate tables. Confirm that you do when the alert pops up. Other database administrative programs will also have the ability to truncate tables.
Or, from the mysql CLI or a SQL command field in a database administrative tool (like PhpMyAdmin or others), you would run the following:
Модули Cron processor и Late runtime processor
Cron processor обрабатывает очередь, когда запускается cron Drupal’а. Это значит, что cron становится стратегически важным (он и раньше должен таковым считаться). Также, из этой модели следует, что существует задержка вплоть до Х (где Х – это частота запуска cron’а), когда Varnish может отдавать закешированый и уже устаревший HTML контент. В некоторых случаях это приемлемо.
Очистка кеша с помощью модуля devel
- Установите модуль
- Включите блок модуля
- В этом блоке будет ссылка для очистки кеша.
Clearing the cache with Drush
To clear all caches, use the cache-rebuild command: drush cache-rebuild . This will empty all caches and rebuild the data required for Drupal to execute a page request. Alternatively, use the aliased commands drush cr or drush rebuild .
Настройка Varnish
Теперь перейдем к подготовке Varnish’a. В ваш VCL необходимо добавить следующее.
Нужно еще добавить саму обработку Ban запросов. В ваш vcl_recv впишите в самое начало:
Так же, по умолчанию, Varnish будет ре-транслировать заголовки Cache-Tags и Cache-Control, которые он получит от Drupal’a, в свой ответ конечному клиенту (браузеру).
В случае Cache-Tags – это банально мусор, который вы будете гонять по сети и лишний источник информации о внутреннем устройстве вашей инфраструктуры. А в случае Cache-Control: public – это довольно нежелательное поведение, т.к. Drupal разрешил кеширование для Varnish’a, но кешировать страницы в браузерах ваших посетителей было бы некорректно (ведь они тогда с опозданием получат обновленный контент и вся наша умная схема про инвалидирование кешей пойдет на смарку). Посему в vcl_deliver надо добавить:
Читайте также: