Отключить кэш drupal 7
Эта тема уже поднималась на форуме раза три. Но я так и не нашёл готового решения.
Есть блок, в блоке сниппет который вытягивает из таблицы базы случайную запись и печатает её. Нужно, чтобы при перезагрузке страницы запрос к БД выполнялся заново и заново вытягивалась информация. Естественно, при включенном кэшировании ничего на странице не обновляется, а остаётся неизменным. Вижу два выхода из этой ситуации:
1. Каким-то образом отключить кэширование блока.
2. Создать блок не стандартным методом, а при помощи какого-то специального модуля, в котором кэширование отключено.
Может кто-то подсказать что-то конкретное? Может кто-то реализовывал такое?
Обновление кэша
Мы настроили 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.
Очистка (сброс) кэша
Для удаления кэшированных данных используется функция cache_clear_all. Её параметры:
- $cid - Cache ID, который надо удалить из хранилища данных. Если не указан, то будут удалены все данные с истёкшим сроком годности и c CACHE_TEMPORARY.
- $bin - название сегмента кэша, из которого надо удалить данные. Если указан указан $cid, то этот аргумент обязателен.
- $wildcard - если указан как TRUE, то все записи, у которых Cache ID начинается с $cid будут удалены. Если $cid имеет значение *, то будет очищен весь сегмент.
Несколько примеров использования:
Частичное кэширование страниц
- Кэширование содержимого: Ноды могут быть закэшированы при условии что поля выглядят одинакого для различных пользователей.
- Кэширование блоков: блоки могут размещаться на различных участках страницы и могут быть закэшированы глобально, или в привязке к странице, ролям или пользователям.
- Меню и ссылки меню: Вместо сбора информации о меню и ссылках меню на каждом запросе их сериализованные версии могут быть закэшированы и повторно использованы.
- Представления: Представления обычно используются для выборки информации из базы данных и представления ее на страницах Drupal. Модуль Views позволяет кэшировать результаты или промежуточные результаты, которые были запрошены из базы данных и должны быть отображены в представлении. Views caching API достаточно продвинут, чтобы определить в каком контексте представление было отображено: фильтры и аргументы могут влиять на конечный вид представления. Поэтому когда кэширование включено фильтры и аргументы используются как часть ключа кэша для гарантии того что результат кэширования сохранен верно.
- Для каждого запроса модуль определяет может ли страница по этому пути и для этой роли пользователя находится в кэше.
- Если может, то Drupal ищет в кэше корректную версию этой страницы.
- Если нашел, то отправляет эту страницу пользователю, иначе генерирует страницу и сохраняет ее в кэше для следующих запросов.
Autcache дополнительно сохраняет в cookie имя пользователям и email, которые могут быть использованы в шаблоне страницы.
Autcache работает как обертка кэширующего бэкенда, которая отлично интегрируется с другими кэширующими бэендами (Memcache и Cacherouter). Установить модуль можно следующим образом (используемые кэширующий бэкенд будет автоматически определен):
Authcache автоматичиски пытается сделать include для файлов Cache Router или Memcache. Если используется другой кэширующий модуль, то необходимо указать путь к нему, например:
Кэширование Drupal 7 может быть реализовано с помощью Varnish или любого другого кэширующего reverse proxy сервера, главное правильно настроить.
Этот пост является переводом отличной статьи с dev.nodeone.se, в которой описано как можно контролировать актуальность кэша Varnish на Drupal сайте, используя модули Varnish, Expire, Cache Actions.
Использование Varnish позволяет существенно ускорить сайт на Drupal. Drupal 7 позволяет работать с кэширующими reverse proxy серверами из коробки и интеграцию Varnish и Drupal 7 можно сделать с помощью модуля Varnish.
Шаг третий. Кэшируем данные.
Давайте теперь для разнообразия закэшируем какие-нибудь данные. Для наглядности я решил закэшировать бесполезную, но достаточно длительную операцию по заполнению массива миллионом элементов. Повесим эту операцию, например, на hook_init():
Как видите, пока никакого кэша нет. У меня эта операция выполняется примерно две секунды. А теперь давайте добавим сюда кэширование:
После добавления кэша время выполнения этой функции существенно уменьшилось.
В принципе, это единственный верный способ работы с кэшем и другого пока не придумано. Однако на практике могут применяться ещё несколько функций. Давайте рассмотрим их все.
Расширенное использование
Встроенный в 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].
Попробуйте отредактировать какой-нибудь нод, все должно работать. Сейчас разница в том, что из кэша удалена не вся страница, а только запись конкретного измененного нода. Вы можете попробовать открыть другую страницу и убедиться, что она все еще кэширована, посмотрев заголовки.
Шаг второй. Заботимся о сбросе кэша.
Вторым шагом я обычно сразу делаю то, о чём в самом конце можно забыть - предусмотреть автоматический сброс кэша. При нажатии на кнопку "Очистка кэша" в разделе "Производительность" (/admin/config/development/performance) должны очиститься все таблицы (сегменты) с кэшем. И наш только что добавленный сегмент не должен быть исключением. Для этого в example_cache.module имплементируем hook_flush_caches(). Он возвращает названия сегментов (таблиц), которые будут очищены при общем сбросе кэша:
Другие решения
Сегодня наконец дошли руки написать продолжение серии статей о кэшировании. В первой части были рассмотрены сегменты кэша, которые находятся в ядре седьмого Друпала. Сегодня же мы поговорим о том, как работать с кэшем программно. Для примера создадим модуль, который предоставляет свой сегмент кэша и управление им.
Шаг первый. Создание нового сегмента кэша.
Назовём наш модуль, например, Example cache. Для создания своего сегмента кэша практически всегда используется клон стандартной таблицы , поэтому и мы не будем исключением. В example_cache.install имплементируем hook_schema(), чтобы добавить свою таблицу:
В принципе всё. Теперь при инсталяции модуля в базе данных будет создана новая таблица с необходимыми полями.
Настройка 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.
Проверка на наличие данных в кэше
С помощью функции cache_is_empty можно узнать, хранятся ли в сегменте кэша какие-либо данные. Достаточно малоиспользуемая функция, но тем не менее помнить про неё надо.
Получение кэшированных данных
Для получения данных из кэша используется функция cache_get. Её параметры:
- $cid - Cache ID - уникальный идентификатор кэша, который надо получить.
- $bin - сегмент кэша (в нашем случае - таблица в бд), откуда надо забрать результат. Если не передать этот параметр, то данные будут браться из сегмента .
Если данных в кэше нет, либо же у него истёк срок годности (когда текущее время больше времени срока годности кэша), то возвращается пустой результат.
Для получения результата так же может использоваться функция cache_get_multiple. Первый её параметр отличается от cache_get лишь тем, что она принимает набор (массив) cid'ов, данные для которых надо получить. После вызова cache_get_multiple из этого массива удаляются все cid'ы, для которых был найден результат.
Комментарии
никак не получится, т.к. друпал кэширует страницу целиком, а не собирает кэш по кусочкам
модуль Block cache посмотрите
georotor, что даже никаким хаком это сделать невозможно? Но ведь это непраильно. Есть материалы, которые должны обновлятся, как мне это реализовать?
deska, модуль Block cache работает для зарегистированных юзеров, а не для всех.
Интересно, а если я через VIEW создам блок и в VIEW укажу, чтобы выводился случайный нод, то кэширование тоже будет срабатывать? Или в этом случае всё будет ОК?
как вариант подгружать содержимое блока через Java скрипт, я еще как то делал свой кэш, когда каждый блок кэшируется отдельно + контент кэшируется отдельно, а в при обращении к странице страница собирается по кусочкам.
Да, это вариант (через Java-скрипт) и его реализовать очень легко. Но мне уже просто интересно, неужели нельзя иначе? Просто через Java-скрипт - это обходной путь, а прямого нет?
что даже никаким хаком это сделать невозможно?
Можно, отключите кэш:)
Как это сделано у меня: кэш включен в нормальном режиме, но тогда корзина кэшируется, сами понимаете это не есть гуд, по этому я поставил на таблицу с кэшем триггер, который не дает за кэшировать страницу с корзиной, а блок корзины я сделал на Яве, собственно это не совсем правильно, т.к. бывают пользователи с отключенной явой, но я решил что мне проще ими пожертвовать.
Если посмотрите таблицу cache_page, то увидите что страница кэшируется целиком. Решить Вашу проблему можно, но только от стандартного кэша придется отказаться.
Короче говоря, я попробовал такой вариант: создал view для блока и указал в сортировке вывод случайного нода. Всё работает как для залогиненых юзеров, так и для анонимов.
Только вот у меня возникли некоторые опасения на счёт кэширования. При рандомном выведении нода будет ли страница кэшироватся или нет? Я думаю, что будет, так как для view есть отдельная таблица для кэша - cache_views . И логично было бы предполагать, что именно в эту таблицу добавляется запись о кэшировании view. В моём же случае, как я понимаю, запись добавлена не будет и мой view будет выполнятся каждый раз.
Есть кто-то, кто хорошо разбирается в кэшировании drupal? Подскажите, насколько верны мои выводы? Как проверить кэшируется конкретная страница или нет?
Никто ничего не может сказать по этому поводу?
неужели в друпале такой тупой кеш что кеширует не как положено - блоки отдельно, страницы отдельно, комменты отдельно - а все целиком.
я был лучшего мнения о умственных способностях его создателей, хотя помню что в 4.5 друпале даже не было возможности определить произвольную зону для блоков, а только лево-право - то да.
хотя все таки друпал создавал не один человек и это наверно его оправдывает
Я вот не пойму как и что кэширует Друпал. Таблица для кэша не одна, так что мне кажется, что есть какое-то разделение. Вот только по поводу моего решения через view никто ничего не отвечает.
какое-то разделение наметилось только в 5-м друпале и то. ну например - зачем кешировать меню когда надо кешировать блоки которые происходят из этого меню, зачем кешировать целиком контент когда надо кешировать отдельно страничку - отдельно комментарии - с кешем у друпала очень все плохо, в отличие от views - есть у views отдельный кеш, есть и инструменты для управления им и в случае надобности можно довольно неплохо при выводе в теме нужного вида продумать его кеширование, если-б еще и views было такое-же как остальной кеш - то оно наверно совсем туго работало-бы.
насчет вашего вопроса - у меня например в блоке на одном сайте сделан рандомный запрос к базе - запрос без views а так сам по себе - так вот вроде обновляется и для анонимных иногда - блок справа в левой колонке
У Вас наверное выставлено короткое время жизни кэша, поэтому и для анонимных иногда обновляется. У меня блок со снипетом закэшировался и не обновляется вовсе. Хотя, если у views свой кэш, то я сделаю через views. Спасибо за помощь!
не - я установил по умолчанию когда время обновления не лимитировано - я так понимаю что когда какое-то время установлено - то он сбросится по истечении этого времени гарантированно, а когда не установлено - то есть наверно вероятность что проживет больше.
Блин, как я ошибался, когда думал, что моя проблема решается через views. Просто тестировал на домашнем компе, а там кэширование было выключено. Короче говоря, сделал через JavaScript + PHP за 15 минут. Но я считаю, что это не правильно. Такая задача должна решатся стандартным Друпаловским функционалом.
))) стандартным друпаловским функционалом не решается даже проблема недостаточной длины заголовков статей - извольте отдельный модуль приставлять )))))
Кэш в 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. Оригинал на английском можно посмотреть тут.
В последнем посте мы рассмотрели какие механизмы кэширования есть в Drupal "из коробки". Мы поняли как Drupal кэширует страницы для анонимных пользователей и нашли решения, позволяющие отдавать кэшированные страницы без загрузки Drupal (используя обратный прокси, например, Varnish или перенаправление запросов при использовании модуля Boost). Также мы увидели, что даже используя эти инструменты кэширования, Drupal также может хранить кэшированны страницы в базе данных. Однако Drupal позволяет прозрачно подключать и другие более быстрые кэширующие бэкенды:
Другой кэширующий бэкенд для Drupal может помочь в ускорении генерации элементов страниц Drupal, таких как блоки, представления и ноды.
Замена кэширующего бэкенда в большинстве случаев достаточно простой процесс, для этого достаточно в файле конфигурации settings.php указать другой кэширующий бэкенд и настройки для него. Например для memcache необходимо добавить следующие строки в settings.php:
Сохранение данных в кэше
Для добавления данных в хранилище кэша используется функция cache_set. Она имеет следующие параметры:
- $cid - уникальный Cache ID (primary key) хранимых данных.
- $data - данные в любом формате, которые надо закэшировать. Данные автоматически сериализуются.
- $bin - сегмент кэша (в нашем случае - таблица в бд), куда надо сохранить данные. Если не указать этот параметр, то данные будут храниться в .
- $expire - задаёт срок годности кэша в милисекундах (Unix timestamp). Он задаётся прибавлением необходимого времени жизни кэша к текущему времени. Кроме числового значения этот параметр может принимать значения CACHE_PERMANENT или CACHE_TEMPORARY. В первом случае данные не будут удалены из кэша, пока вы их не удалите принудительно (очисткой сегмента либо же удалением данных с указанным $cid). Во втором случае данные будут очищены при первой же общей очистке кэша с истёкшим сроком годности.
Примеры использования
В качестве примера работы с кэшем вы можете установить модуль Cache Example, находящийся в составе модуля Examples.
Читайте также: