Меню

Drupal 7 настройка кэширования



Настройка и оптимизация Drupal — кэширование, страница 404

Здравствуйте, друзья! Сегодня речь пойдет о настройке и оптимизации Drupal. В эту статью я решил объединить следующие темы:

  • настройка «Информации о сайте»;
  • создание страницы 404;
  • ускорение сайта — кеширование Drupal и сжатие файлов CSS и JavaScript;
  • отчеты и логи.

Во как много всего получилось! Не стоит пугаться такого объема, все эти функции в Drupal реализованы на редкость просто.

Информации о сайте

Переходим в раздел «Конфигурация» — «Система» — «Информация о сайте». Большинство параметров уже были заданы при установке Drupal, это название сайта, слоган и email администратора. Есть и кое-что новенькое.

Можно изменить главную сайта, скажем, сделать ее стационарной, а не динамической. В этом случае создайте материал типа «Страница» и в пункт «Главная страница по умолчанию» впишите соответствующий URL адрес.

Тоже самое можно и нужно сделать для страниц ошибок. Особое внимание стоит обратить на ошибку 404 — страница не найдена. Что на ней необходимо разместить:

  • Красивое изображение, которое бы не отпугивало посетителя, а наоборот, располагало к себе.
  • Вежливое обращение. К примеру, «Извините, страница с таким адресом не найдена. Пожалуйста, воспользуйтесь поиском или меню.»
  • Поиск по сайту. Желательно задействовать пользовательский поиск от Яндекс или Google.
  • Список самых популярных материалов. Возможно, что-то да приглянется пользователю, и он продолжит работать с вашим сайтом.

Отчеты и логи

Под всевозможные отчеты и логи в админке Drupal выделен целый раздел, который так и называется — «Отчеты». В нем можно найти следующее:

  • Отчет о состоянии — здесь представлена вся информации о системе. Можно увидеть, что какие-то модули устарели, или сам Друпал нуждается в обновлении. При каких-то ошибках или проблем в работе системы, это первое место, куда нужно лезть в поисках решения.
  • Доступные обновления — здесь представлена более подробная информации об обновлениях тем, модулей и ядра Drupal.
  • Ошибки «отказ в доступе» — этот лог стоит использовать в целях безопасности, чтобы обнаружить попытки взлома система и предотвратить несанкционированный доступ к админке Drupal. Обязательно время от времени просматривайте его.
  • Ошибки «страница не найдена» — данный лог стоит просматривать с целью выявления несуществующих страниц и обнаружения ошибки 404.
  • Популярные поисковые запросы — журнал поисковых запросов при учете, что на сайте используется стандартный поиск Drupal.
  • Список полей — представлен список всех полей. Для каждого поля указаны объекты, в которых оно задействовано.

Ничего обязательного в разделе «Отчеты» нет, но полезного много. Так что хотя бы иногда сюда заглядывайте.

Ускорение Drupal — кэширование и оптимизация файлов CSS и JavaScript

Функция кэширования и оптимизации файлов стилей CSS и скриптов JavaScript заложена в самом ядре Drupal. Ничего дополнительно устанавливать не надо. Браво! Аплодирую стоя! По мере изучения Друпал, он мне начинает нравится все больше и больше.

Для людей, которые не знакомы с механикой работы современных CMS, поясню, что такое кэш и зачем его обязательно следует использовать. В Drupal каждая страница сайта генерируется при переходе на нее. Они формируются на основе шаблонов и заполняются информацией из базы данных. На сервере нельзя найти страницу в виде простого html файла. Чем это плохо?

  • Во первых, это нагружает базу данных, ибо постоянно к ней идут запросы.
  • Во-вторых, это нагружает сервер, а значит за него придется больше платить.
  • В-третьих, это значительно увеличивает время загрузки сайта.

Кэширование позволяет создать «снимок» текущего состояния страницы. Фактически, это обычная страница в формате html, которая живет определенный интервал времени (время жизни), а потом обновляется. Таким образом, страница не генерируется для каждого пользователя, а просто открывается из соответствующего файла html. Данный подход устраняет все три минуса.

Переходим в раздел «Конфигурация» — «Разработка» — «Производительность». В кэшировании я включил первые две опции, минимальное время жизни выставил 12 часов, а максимально время жизни — 1 день. Кэш всегда можно сбросить в ручную, задействовав кнопку «Очистка Кэша».

Ниже расположены настройки оптимизации пропускной способности.

Включаем все три опции:

  • Сжатие кэшированных страниц.
  • Объединение и сжатие файлов CSS.
  • Объединение файлов JavaScript.

Дело в том, что устанавливаемые в Drupal модули привносят в систему дополнительные скрипты и стили. При загрузке страницы файлы CSS и JavaScript каждого такого модуля подключаются в отдельности. Дабы оптимизировать этот процесс и ускорить загрузку сайта, можно все стили собрать в одном файле CSS, который и будет подключатся. То же самое делается и с файлами скриптов JavaScript.

Как видите, оптимизация Drupal сводится к настройке семи опций, пять из которых достаточно просто включить.

Это все, что я хотел сегодня рассказать. Спасибо за внимание! Берегите себя.

Лучший способ выразить благодарность автору — поделиться с друзьями!

Узнавайте о появлении нового материала первым! Подпишитесь на обновления по email:

Источник

Entity cache и Display Cache — комплексное кеширование сущностей

В Drupal 7 одним из главных нововведений было появление новой концепции сущностей (Entity). К сущностям относятся: ноды, комментарии, пользователи, термины таксономии и другие. К сущностям также можно крепить любой набор полей. Но, наверняка, многие знают о проблемах с производительностью при загрузке объектов сущности и дальнейшем их рендеринге, отрисовке в html код для вывода на страницу. А в особенности, если выводится сразу много сущностей, да еще и если к ним прикреплено штук пару-пятнадцать полей.

Для анонимных пользователей можно конечно же закешировать всю страницу (cache page) и отдавать каждому последующему посетителю страницу целиком из кеша. Для авторизованных пользователей все обстоит немного посложнее, ибо для них некоторые элементы страниц будут отличаться.

Многие стараются избежать при выводе материалов модулем views сущностей целиком, чтобы избежать вызовов node_load() для загрузки объектов нод. Вместо этого выбирают вывод только нужных полей. Также существует возможность закешировать вьюс на определенное время, также как и панели. Но, что делать если в какой-либо ноде изменилось какое то поле или же нода была удалена. По хорошему хотелось бы, чтобы и кеш вьюса или панели «освежился».

Для задачи хранения в кеше сформированных объектов сущностей, чтобы избежать постоянных вызовов entity_load(), имеется модуль Entity cache. Он поддерживает все сущности ядра drupal. Он очень прост в использовании — его просто достаточно установить и включить. Он будет все объекты сам ложить в сериализованном виде в кеш и в последующем вместо полной загрузки объекты будут браться из кеша. В Drupal 8 функционал модуля уже включен в ядро.

Читайте также:  Sony cdx gt310 настройка часов

Чтобы избежать последующего процесса рендеринга, можно воспользоваться модулем Display Cache. Он сохраняет в кеш уже готовый html вывод сущностей целиком или же опционально только полей сущности. При этом он позволяет достаточно гибко настроить кеширование для каждой сущности и для каждого view mode.

Рассмотрим установку и настройку модуля Display Cache поподробней. Для установки его нужно стандартно скачать со страницы проекта, разархивировать и положить в каталог sites/all/modules (sites/all/modules/contrib). И далее включаем его на странице /admin/modules. Для пользователей drush все еще проще — просто выполняем команду:

Далее для примера рассмотрим настройку кеширования типа материала article и его view mode «teaser». Переходим на страницу настроек типа материала и открываем вкладку «Manage display» (страница /admin/structure/types/manage/article/display/teaser). В филдсете «DISPLAY CACHE DISPLAY SETTINGS» находятся настройки кеширования:

Для каждого view mode можно выбрать: No caching (вообще не кешировать этот view mode), Cache display (кешировать вывод целиком), Cache fields only (кешировать только вывод полей). При выборе кеширования полностью, вывод полей все равно будет ложиться в кеш. Это необходимо для того, чтобы при изменении одного поля, при рендеринге ноды остальные поля сразу брались из кеша.

Также в настройках можно выбрать, чтобы кеш формировался в зависимости от урла и выбрать раздельное кеширование по ролям или же для каждого пользователя отдельно. Имеет смысл выбрать кеширование по ролям, так как в противном случае анонимные пользователи могут увидеть нежелательные части вывода нод (к примеру контекстные ссылки).

При выборе же кеширования только полей, можно будет дополнительно в филдсете «DISPLAY CACHE FIELD SETTINGS» выбрать, какие поля нужно кешировать.

Для очистки display cache можно воспользоваться drush командой:

Либо же перейти на страницу /admin/config/development/display-cache и нажать кнопку «Flush all display caches». Для более тонкой возможности по очистке кеша, можно также воспользоваться модулем UI Cache Clear (автор kalabro). Модуль позволяет очищать кеш блоков, панелей, вьюсов, path breadcrumbs и страниц. Для очистки кеша используются контекстные ссылки, а кеш страниц можно очистить из admin menu. Он с недавнего времени интегрирован с entity cache и display cache. Правда ограничен только нодами. Зато можно очистить кеш отдельно каждой ноды. Для этого модуль добавляет контекстные ссылки при выводе материалов и вкладки на страницах нод.

Подводя итоги, такое комплексное кеширование сущностей несомненно пригодиться для сайтов, которые посещают авторизованные пользователи и конечно же при большом количестве прикрепленных полей к сущностям. Для случаев, если не хватает стандартных view mode, можно воспользоваться либо хуком hook_entity_view_mode_alter, либо модулем Entity view modes. Также не лишним будет вынести кеш из базы данных в Memcache или же Redis.

Отдельное спасибо duozersk за идею использования модуля, подсмотренную на просторах drupal skype-чатов.

Источник

Drupal Русскоязычное сообщество

Известно, что медленная работа сайта снижает его посещаемость и отрицательно влияет на SEO. Читайте, как нам удалось в 30 раз ускорить обработку входящих запросов и значительно снизить время загрузки drupal-сайта.
https://drupal-coder.ru/blog/nastroyka-keshirovaniya-dannykh-uskorenie-r.

Комментарии

первым делом надо не оптимизировать коммерс аякс формы, а выбросить их к этим самым этих самых

Сколько часов потратили и какая стоимость ?

В какую сумму обошелся сервер ?

Commerce Fast Ajax Add to Cart по каким-то причинам не подошел ?

  • Войдите или зарегистрируйтесь, чтобы отправлять комментарии

По Commerce Fast Ajax Add to Cart нашел пояснение, спасибо.

  • Войдите или зарегистрируйтесь, чтобы отправлять комментарии
  1. отключение http (всегда https/2)
  2. отключение сторонних скриптов (гугл аналитика и яндекс метрика)
  3. кэширование на стороне броузера с помощью модулей апачи expires и headers.

  • Войдите или зарегистрируйтесь, чтобы отправлять комментарии

Бизнес сайту без внешних скриптов практически нереально жить — статистика, колтрекинг, ретаргетинг.

  • Войдите или зарегистрируйтесь, чтобы отправлять комментарии

Публикуйте здесь статью, ну или хоть выдержку. Зачем этот спам?

  • Войдите или зарегистрируйтесь, чтобы отправлять комментарии

если есть непонимание то я удаляю свой комментарий вконтакте. здесь такой возможности нет.
считаю что мой комментарий вполне информационен. если есть вопросы то всегда можно задать вопрос.

  • Войдите или зарегистрируйтесь, чтобы отправлять комментарии

Я думаю, Антон писал про сам пост, а не про твой комментарий

  • Войдите или зарегистрируйтесь, чтобы отправлять комментарии

а, понял. а я уже хотел обидеться.

Я думаю, Антон писал про сам пост, а не про твой комментарий

Все верно. Я — Антон.

  • Войдите или зарегистрируйтесь, чтобы отправлять комментарии

Стандартное кэширование Drupal 8, https, Nginx с кэшированием статики, сервак 4 гига 4 ядра, SSD, ну и качественный код = соточку имеем )))

Источник

Урок Система кэширования Drupal 7. Часть первая: сегменты кэша.

По опыту начал замечать, что многие разработчики, особенно junior/mid уровня, имеют довольно слабое представление о системе кэширования Друпала. До сих пор ни один разработчик не ответил мне правильно на все вопросы о хранилищах и назначении стандартного кэша, который включается в ядро Друпала уже достаточно давно. Мне кажется, уже пора раз и навсегда закрыть этот вопрос.

Я надеюсь, самые базовые знания о том, что такое кэш у вас есть. Если же нет – сначала надо прочитать вводную статью о кэше, а потом продолжать чтение текущей.

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

  • Во-первых, это позволяет выносить определённые сегменты кэша в другие системы хранения кэша (например, в Memcached или Boost). Некоторые сегменты кэша обновляются чаще, другие реже. Это стоит учитывать при разработке сайта, и пробовать разные системы хранения кэша.
  • Во-вторых, это повышает производительность работы с кэшем – в меньших объёмах данных работа с записями происходят быстрее. Более того, при определённых действиях кэш может очищаться частично (сегментно). Согласитесь, в базе данных гораздо быстрее выполнится полная очистка таблицы (TRUNCATE), нежели частичное удаление при помощи %LIKE% .

На текущий момент (Drupal 7.15) ядро Друпала вместе со стандартными модулями насчитывает 11 различных сегментов кэша. Предлагаю разобрать каждый из них подробно.

Общее хранилище кэша.

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

Этот сегмент состоит из 5 полей:

  • cid (Cache ID)— уникальный идентификатор кэша. Сюда обычно записывается любая последовательность символов, по которой вы сможете идентифицировать запись. Например, если бы вы написали свой модуль, который кэширует данные для ноды с nid 74, то можно было бы cid выставить как module_name:node:74. Строгих правил для заполнения этого поля нет, однако довольно удобно (рекомендуется) начинать его с названия модуля, который сохраняет кэш. Единственный нюанс — длина не должна превышать 255 символов.
  • data — данные, которые должны быть закэшированы. Здесь нет ограничений по размеру записываемых данных. Поэтому всё, что должно быть сохранено для быстрого доступа, может быть записано в эту таблицу.
  • expire — время в Unix формате, которое указывает окончание «срока годности» кэша. Например, если вы хотите выставить кэш на 20 минут, то делается это так:

По сути, к текущему времени просто добавляется 20 минут (1200 секунд в Unix формате), и это время записывается в поле expire.

  • created — время сохранения кэша в Unix формате.
  • serialized — флаг (0 или 1), показывающий, были ли кэшируемые данные сериализованы. Напомню, что простые типы данных (строки, числа, null) в сериализации не нуждаются.
  • Читайте также:  Мой склад настройка кассы

    Все остальные сегменты кэша имеют точно такую же структуру, поэтому больше я на этом останавливаться не буду.

    В общий сегмент кэша могут закидываться данные не только из ядра Друпала, но и из контриб-модулей.

    Кэш блоков

    Сегмент добавляется при включении модуля Block (входит в ядро).

    При загрузке региона Друпал загружает данные по всем блокам этого региона. В этот момент проверяется, а не закэшированы ли данные для блока. Если так и есть — то делается запрос к сегменту и вытаскивается массив с данными блока (уже отрендеренными), тем самым пропуская вызов хука hook_block_view() для этого блока с его последующим рендером и с его последующим кэшированием.

    Здесь стоит отметить, что кэширование для блоков отключается, если включаются модули по работе с доступами к материалу, а конкретнее — имплементация hook_node_access().

    При создании блока через hook_block_info() можно управлять параметрами кэширования для блока, указав ему одну из констант:

    • DRUPAL_CACHE_PER_ROLE (по умолчанию): Блок кэшируется в зависимости от роли пользователя, который просматривает страницу.
    • DRUPAL_CACHE_PER_USER: Блок кэшируется для каждого пользователя индивидуально. Обратите внимание, что для сайтов с большим количеством пользователей выставление этого флага будет создавать большое количество данных в кэшируемой таблице.
    • DRUPAL_CACHE_PER_PAGE: Блок кэшируется в зависимости от страницы, на которой он отображается.
    • DRUPAL_CACHE_GLOBAL: Блок кэшируется для всех страниц и всех пользователей, вне зависимости от внешних факторов.
    • DRUPAL_NO_CACHE: Блок не кэшируется вообще. Это значит, что каждый раз при загрузке региона, вызывается загрузка содержимого блока с последующим его рендером.

    При сохранении кэша блока ему выставляется флаг CACHE_TEMPORARY. Это означает, что кэш блока будет стёрт при ближайшем вызове функции очистки кэша.

    Кэш загрузки (бутстрапа)

    — сегмент кэша, в котором хранятся данные, инициализируемые при загрузке Друпала. Вам лично вряд ли доведётся с ней работать, однако знать что в ней хранится, я считаю, надо обязательно (далее жирным выделен Cache ID кэша):

    • bootstrap_modules — список модулей, которые имплементируют хуки бутстрапа. Они загружаются раньше остальных модулей.
    • hook_info — список всех хуков, доступных для имплементации.
    • lookup_cache — данные, которые предоставляют список динамически загружаемых классов и файлов, в которых они хранятся.
    • module_implements — данные, предоставляющие список хуков вместе с модулями, в которых есть реализация этих хуков.
    • system_list — список включенных модулей и тем, со всеми зависимостями, подключенными интерфейсами и так далее. То есть по сути, тут хранятся структурированные данные из .info файла.
    • variables — кэш переменных, записанных в таблицу . При бутстрапе Друпал загружает в глобальную переменную $conf из кэша список всех доступных переменных. Этот трюк позволяет существенно ускорить выполнения множественных вызовов функции variable_get(), т.к. результат не загружается каждый раз из базы данных, а из оперативной памяти забирается уже сохранённое значение.

    Кэш полей

    Данные по всем полям (fields) хранятся в сегменте . Он добавляется при включении модуля Field.

    В каждой записи кэша хранится набор полей со значениями, которые относятся к загружаемой сущности. При программной загрузке сущности, из этой таблицы забирается кэш всех полей сущности и добавляется к загруженному объекту. Если же кэша нет в таблице, то для каждого поля вызывается загрузка информации и данных, после чего полученный результат сохраняется в сегменте .

    Cache ID формируется по правилу field:тип_сущности:id_сущности. Например, для материала с nid 52 Cache ID будет выглядеть как field:node:52.

    Кэш фильтров

    С модулем Filter сталкивались все – он входит в набор модулей ядра, которые обязательно включаются при установке Друпала. Этот модуль создает свою таблицу для хранения кэша для обработанного фильтрами текста. Например, при вызове check_markup() вы можете передать четвёртый параметр TRUE, и тогда текст после прохождения фильтра будет сохранён в сегменте . В обратном случае фильтр будет вызываться каждый раз, обрабатывая один и тот же текст при каждой его загрузке. Чем сложнее фильтр, тем больше процессорного времени тратится на обработку текста. Поэтому по возможности я бы рекомендовал все вызовы check_markup() кэшировать.

    При сохранении (обновлении) и отключении фильтра, все его сохранённые данные будут удалены из сегмента с кэшем.

    Cache ID для таблицы собирается по правилу название_формата:язык:хэш_текста :

    Кэш форм

    На самом деле, это не совсем тот кэш, который содержится в остальных хранилищах кэша. Если остальные кэшируемые данные хранятся для ускорения работы сайта, то этот кэш на производительность никак не влияет. Однако благодаря ему все формы, построенные с помощью Forms API Друпала, являются абсолютно безопасными с точки зрения уязвимостей.

    Каждый раз при построении формы она сохраняется в сегменте . Причем сама форма и массив с её значениями хранятся отдельно — у них Cache ID field_$form_build_id и field_state_$form_build_id соответственно. При нажатии на сабмит Друпал проверяет полученные POST/GET данные с теми, что были сохранены при построении формы. И только в том случае, если полученные значения корректны, произойдёт дальнейшая обработка формы.

    Данные из кэша форм стираются в двух случаях:

    • По крону, когда истёк «срок годности» кэша (он кэшируется на 6 часов)
    • После успешного сабмита формы

    Если форм и посетителей много, то имеет свойство разрастаться до внушительных размеров. Бороться с этим можно путем двух нехитрых действий:

    • Настроить автоматический запук крона через каждые 1-2 часа.
    • Уменьшить время хранения кэша форм. К сожалению, на данный момент это значение забито жёстко в коде. Поэтому чтобы это исправить надо открыть файл includes/form.inc , найти строку $expire = 21600; (531 строка) и уменьшить её значение, например, до 7200 (2 часа). В этом случае при каждом обновлении ядра вам придётся каждый раз исправлять значения этой переменной (по крайней мере до тех пор, пока это значение не будет вынесено в настройки). Я изменение кода ядра не особо приветствую, но в критических ситуациях можно этим методом воспользоваться.

    По опыту могу сказать, что хоть таблица и разрастается, но своевременный запуск крона позволяет держать её размер в более-менее адекватных рамках. Например, на сайте с 15к уников в день и относительно небольшим количеством форм она держится в рамках 200мб (без изменения срока годности кэша форм).

    Кэш изображений

    Хранится в сегменте . На самом деле пользы в этой таблице никакой нет, т.к. никакой кэш изображений туда не складывается. Таблица зарезервирована модулем Image и может использоваться как хранение сведений о проведении различных манипуляций над изображениями.

    Кэш меню

    Сегмент включается при включении модуля Menu и является хранилищем ссылок из всех меню, созданными через интерфейс Друпала. Cache ID строится по правилу links:имя_меню:tree-data:язык:хэш_параметров:

    В качестве данных обычно сюда передаётся полностью построенное дерево меню, содержащее все данные по ссылкам меню – название пунктов, их ссылки, язык, родительский пункт, дополнительные параметры и так далее.

    Кроме деревьев здесь также находится и постраничное меню – т.е. меню, которое должно отображаться на конкретной странице.

    Кстати, модуль Admin menu тоже хранит здесь свои данные. Правда, он записывает их уже отрендеренными (в виде html кода) и занимает всего одну запись в таблице.

    Кэш страниц

    Это один из наиболее важных видов кэша. Сегмент с этим кэшем называется и в ней Друпал хранит закэшированные данные страниц для АНОНИМНЫХ пользователей.

    В процессе бутстрапа (инициализации системы) Друпал проверяет пользователя и настройки кэширования системы. Если текущий пользователь – аноним, и включена опция кэширования, то Друпал попытается из сегмента вытащить данные, которые он уже показывал другим пользователям, и построить страницу используя полученные данные. В этом случае время загрузки страницы существенно уменьшается, т.к. Друпалу не надо производить построение данных для отображения страницы и рендерить это – ведь эти данные уже лежат в кэше!

    Если Друпал нашёл для текущей страницы её кэш, то будут вызваны только 2 хука:

    Остальные же хуки (включая hook_init() и прочие) будут пропущены.

    Важно понимать, что это именно тот кэш, который вы включаете на сайте в разделе настроек производительности (admin/config/development/performance) с нажатием галочки на «Кэшировать страницы для анонимных пользователей». Если в этом разделе вы выставите настройку «Минимальное время хранения кэша» например в 10 минут, то произойдёт следующее: когда на страницу сайта зайдёт аноним, то страница соберётся для него, а потом закешируется в . Если в течение следующих 10 минут на эту же страницу будут заходить другие анонимные посетители, то им будет показываться та же страница, что и первому анониму. Это несмотря на то, что данные на сайте уже могли обновиться, и авторизованные пользователи уже видят страницу с последними обновлениями. Именно поэтому очень важно настраивать кэширование с полным пониманием того, кому и как должен быть показан контент – кому обязательно его показывать сразу же после создания, а кто может и потерпеть какое-то время ради увеличения производительности.

    Из написанного выше вытекает, что для авторизованных пользователей как такового глобального кэша нет. Кэшируются блоки и прочие мелочи технической жизни – и всё. Остальное кэширование лежит на сборщиках / разработчиках сайта. Например, кэширование выводимых данных с помощью Views, или же Panels, или другими модулями. И этот момент обязательно надо учитывать при построении сайта.

    Кэш путей

    Для более быстрого поиска алиаса по системному пути (и наоборот – системного пути по алиасу) создан отдельный сегмент . Он в себе хранит соответствие между системным путём и его алиасами. Как разработчик я не сталкивался с необходимостью работать с этим кэшем, поэтому я не считаю его важным для изучения. О нём надо знать, что он существует и используется Друпалом для поиска системных путей и алисов. Пожалуй, больше здесь я ничего не расскажу.

    Кэш обновлений

    При включении модуля Update manager добавляется сегмент . Он в себе хранит данные по всем релизам для включенных модулей. Этот сегмент опять же является не совсем кэшем (на производительность сайта не влияет) – скорее, просто хранилище данных по модулям. Однако обойтись без этого сегмента нельзя – получение данных по релизам модулей занимает достаточно много времени, и без кэширования этих данных некоторые страницы админки, связанные с модулями, загружались бы несколько дольше.

    Кэш данного сегмента обновляется только тогда, когда Друпал получает новые данные по релизам модулей. Из этого следует, что никакие сбросы кэша этот сегмент не затрагивают.

    Объектный кэш CTools’a

    Ещё один кэш, про который не рассказать просто нельзя, хоть он и не относится к ядру. Ещё когда только выходила седьмая версия Друпала я много слышал о каком-то магическом «объектном кэше ctools’a». Как тогда я понял из прочтённого и услышанного, это некая хитрая система, которая делает мир лучше, и по идее увеличивает производительность сайта. Как выяснилось позже – об этом много кто слышал, но никто не интересовался что это и как это работает. А оказалось всё намного банальнее и проще, чем это раздули слухи и больное воображение.

    Объектный кэш CTools’a – это сегмент кэша, который предоставляет своё пространство под хранение больших объектов, которые редактируются в данный момент. Приведу пример из модуля Views: при создании или редактировании нового вьюса, до его сохранения, все изменения видны только для того пользователя, который их внёс. Даже если вы измените вьюс, потом закроете сайт, а затем снова откроете – вам будет показана изменённый вами вьюс. Это значит, что объект с изменённым и не сохранённым вьюсом где-то хранился только для вас, в то время как сохранённая вьюха лежала без изменений. Вот теперь вместо этого «где-то» — сегмент объектного кэша CTools’a.

    В отличии от других сегментов кэша он имеет дополнительное поле sid (Session ID) – идентификатор текущей сессии пользователя. Именно благодаря нему изменённые данные видны «персонально», то есть только изменившему объект пользователю.

    Кстати, этот сегмент не имеет поля expire, и, соответственно, не удаляется при очистке кэша через интерфейс Друпала. Однако раз в сутки CTools запускает крон и удаляет из этого сегмента кэш недельной давности.

    Источник

    Adblock
    detector