Кеширование в DLE: как устроено и что ломается под нагрузкой

При росте нагрузки DLE чаще упирается не в один медленный SQL-запрос, а в повторную сборку одинаковых страниц: PHP читает настройки, обращается к базе, формирует меню, модули и список новостей. Кеширование сокращает эту работу, но не превращает DataLife Engine в полноценный full-page cache. Разбор ориентирован на DLE 18.x: конкретные пункты админки и доступные драйверы кеша сверяйте с вашей минорной версией и установленными дополнениями.

Что именно кеширует DLE

Запрос к DLE проходит несколько этапов. Веб-сервер передаёт его PHP, движок определяет тип страницы и параметры запроса, читает настройки и обращается к базе данных. После этого DLE подставляет данные в шаблон, собирает дополнительные блоки и отдаёт HTML браузеру.

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

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

В типичной установке встречаются несколько уровней:

• Кеш данных и запросов. Движок сохраняет результаты операций, которые можно повторно использовать: списки новостей, элементы меню, сведения о категориях и другие данные, зависящие от настроек и дополнений.
• Кеш отдельных модулей. Блоки вроде популярных публикаций, похожих новостей или вывода из стороннего модуля могут иметь собственное кеширование.
• Кеш шаблонов и служебных результатов. Он уменьшает количество повторной работы при обработке шаблона и вспомогательных операций.
• Кеш PHP и базы данных. OPcache хранит скомпилированный байткод PHP, а сама СУБД может повторно использовать планы выполнения и страницы данных. Это уже не механизм DLE, хотя на время ответа они влияют напрямую.

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

Как проходит запрос

1. DLE определяет контекст страницы

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

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

2. Движок проверяет доступный результат

При файловом кеше DLE обращается к файлам в каталоге кеша, обычно внутри engine/cache. Точное имя файла и структура зависят от версии и расширений, поэтому удалять отдельные файлы по догадке не стоит. При использовании внешнего backend’а результат хранится не в файловой системе, а в сервисе, с которым настроена интеграция.

Если запись существует и не истекла, DLE использует её. При промахе кеша выполняется исходная операция: запрос к базе, обработка результата или сборка блока.

3. Результат сохраняется для следующего запроса

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

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

4. Изменение контента запускает очистку

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

Поэтому после публикации полезно проверять не только саму новость, но и страницы, где она должна появиться. Если в админке запись уже изменилась, а на сайте видна старая версия, проблема может быть в кеше модуля, CDN или OPcache — и не обязательно в базе данных.

Файловый кеш и внешнее хранилище

В небольшом проекте файловый вариант проще: не нужен отдельный сервис, резервное копирование остаётся понятным, а сброс кеша выполняется средствами DLE или удалением временных данных по инструкции к конкретной версии. Цена — операции с файлами и зависимость от диска.

Memcached или Redis могут быть полезны на нескольких PHP-воркерах и нескольких веб-серверах. Но они добавляют отдельный процесс, настройки подключения, контроль доступности и правила очистки. Само подключение внешнего хранилища не делает медленный SQL-запрос быстрым: оно лишь меняет место, откуда берётся уже сохранённый результат.

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

Что ломается первым

Устаревшая новость остаётся в блоке

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

Проверяйте проблему последовательно: откройте страницу в приватном окне, очистите кеш штатными средствами DLE, затем временно отключите кеш конкретного модуля. Если данные обновились только после ручной очистки, ищите ошибку в зависимости между изменением публикации и сбросом результата.

Кеш растёт, а сайт не ускоряется

Большое число файлов не означает большой эффект. Если ключ содержит уникальный параметр запроса, почти каждый посетитель создаёт новую запись. Кеш начинает занимать диск, но повторных обращений к одной записи мало.

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

После включения кеша появляются чужие данные

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

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

После очистки кеш сразу заполняется снова

Если каталог быстро растёт, это не обязательно неисправность. При всплеске посещаемости много PHP-процессов могут одновременно не найти одну запись и начать строить её параллельно. Такой эффект называют stampede — «лавиной» кеш-промахов.

Помогают предварительный прогрев публичных страниц, ограничение времени тяжёлых операций и настройка блокировки формирования одного и того же результата, если это поддерживает используемый слой. Конкретный способ зависит от версии DLE и выбранного backend’а; не добавляйте неизвестные параметры в конфигурацию без документации.

Как измерять эффект, а не верить ощущению

Сравнивайте две одинаковые версии страницы на одном сервере и при сопоставимой нагрузке. Зафиксируйте версию PHP, версию DLE, объём базы, число PHP-воркеров и состояние OPcache. Отдельно измерьте первый запрос после очистки и серию повторных запросов.

• время ответа на уровне веб-сервера;
• время выполнения PHP;
• количество SQL-запросов и суммарное время базы;
• долю попаданий и промахов кеша;
• загрузку CPU, диска, памяти и внешнего кеш-сервиса;
• долю ответов 5xx и таймаутов под нагрузкой.

Сравнение «до и после» без одинакового трафика легко вводит в заблуждение. Для небольшого сайта достаточно замеров из журнала веб-сервера и профилировщика на тестовой копии. На рабочем сайте подробное профилирование включайте кратковременно: оно само меняет нагрузку.

Где схема DLE не спасает

Кеширование не исправит запрос с отсутствующим индексом, модуль, который делает десятки обращений к базе на каждый просмотр, или PHP-скрипт, блокирующий воркер. Не поможет оно и при медленном диске, переполненной памяти или неверно настроенном OPcache.

Есть и логические границы. Часто меняющийся каталог, поиск с большим числом параметров и персональные страницы плохо подходят для долгого полного кеша. Для них разумнее кешировать отдельные публичные справочники или результаты, а не весь HTML.

Инвалидация CDN и прогрев кеша — отдельные темы. Здесь важно лишь не смешивать их с внутренним кешем DLE: очистка одного слоя не гарантирует очистку остальных.

Что делать дальше

Сначала составьте карту: какие страницы публичные, какие блоки на них самые дорогие, где хранится кеш и кто должен его очищать после изменения новости. Затем снимите базовые показатели на DLE 18.x, проверьте права каталога кеша и убедитесь, что OPcache работает на сервере.

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