Особенности работы встроенного в Drupal кэширования

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

Кэширование страниц для анонимных пользователей

Первая настройка — Кэширование страниц для анонимных пользователей. Эта настройка указывает Drupal о необходимости сохранения сгенерированной страницы для одного анонимного пользователя и показа ее другим анонимным пользователям. Страницы сохраняются с идентификатором URL'a запроса, технически это $base_root . request_uri(), так запросы для http://example.com/page_one и http://example.com/page_one?rand=1 считаются различными и генерируются отдельно, даже если '?rand=1' не влияет на генерацию страницы, то есть результирующие страницы одинаковы.

Как только параметр кэширование страниц будет включен станут доступными две настройки: Минимальное время жизни кэша (Minimum cache lifetime) и Максимальное время (expiration of cached pages).

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

Параметр Максимальное время также иногда неправильно понимают. Этот параметр контролирует какое значние будет отправлено в параметре max-age заголока Cache-control и таким образом сообщает прокси-серверу сколько времени прокси может отдавать эту страницу без запроса к Drupal обновленной копии страницы. Это означает, что прокси сервер должен запросить у Drupal новую версию страницы. Drupal перегенерирует страницу после выполнения события очистки кэша.

Событие очистки кэша

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

Для хранения кэша наиболее часто используются база данных и Memcached (DrupalDatabaseCache class и MemCacheDrupal class). Ниже приведена таблца поведения этих кэширующих бэкендов при вызове типовых событий очистки кэша.

Отношение к крону, как к событию очистки кэша, при использовании базы данных для хранения кэша, вместе с частыми запусками крона является причиной того, что знакомые с Drupal пользователи думают о параметре минимальное временя жизни так: "мои страницы будут обновлены по прошествии этого времени". Это также является причиной разочарования пользователей, которые решили сохранять страницы в кэше, до момента изменения контента. Понимание поведения кэширования Drupal, его взаимодействия с прокси серверами типа Varnish и каким образом кэширующий бэкенд ведет себя в различных ситуация — все это является очень важным для уверенности, что контент в кэше будет обновлен когда это требуется и корректно закэширован, когда нет обновлений.