DLE под нагрузкой: как оптимизировать запросы без поломок

Почему DLE начинает тормозить под нагрузкой

На сайте на DataLife Engine задержка часто появляется не из-за одного «тяжёлого» запроса, а из-за их количества: главная страница собирает публикации, категории, комментарии, теги и блоки навигации. При росте параллельных запросов база одновременно читает одни и те же таблицы, а PHP ждёт их завершения. В результате растёт время ответа, появляются 502 и 504, а добавление CPU не меняет ситуацию.

Материал рассчитан на DLE 18.x и MySQL 8.0 или MariaDB сопоставимой версии. Перед работой зафиксируйте точную версию DLE, СУБД и схему таблиц: у старых релизов названия настроек и структура дополнительных таблиц могут отличаться.

Оптимизируйте не «DLE вообще», а конкретный запрос, который занимает соединения и время базы в вашем сценарии нагрузки.

Сноска. Индекс — отдельная структура базы данных, которая ускоряет поиск и сортировку по одному или нескольким столбцам. За это приходится платить местом на диске и дополнительной работой при вставке или изменении строк.

Сначала найдите запрос, а не добавляйте индексы

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

Что проверить на уровне сайта

• страницу, на которой воспроизводится задержка: главную, раздел, поиск или страницу публикации;
• период: обычный трафик, публикация материала, массовый приход из рекламы или пик комментариев;
• включённые модули и блоки DLE, особенно те, что выводят списки публикаций, рейтинги, комментарии и похожие материалы;
• разницу между запросом к странице без авторизации и тем же запросом для зарегистрированного пользователя;
• время ответа PHP и отдельное время ожидания MySQL.

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

Как посмотреть план запроса

Для диагностического запроса используйте таблицу публикаций с вашим префиксом. В примере префикс dle_ замените на фактический. Запрос только читает данные, но запускать его следует на копии базы или в период, когда вы контролируете нагрузку.

EXPLAIN
SELECT id, title, date
FROM dle_post
WHERE approve = 1
  AND date <= NOW()
ORDER BY date DESC
LIMIT 20;

В результате смотрите не на одну цифру, а на сочетание признаков: сколько строк база предполагает прочитать, используется ли индекс, есть ли сортировка через временную таблицу и сколько строк фактически проходит фильтры. Для MySQL 8.0 доступен более подробный вариант с фактическим выполнением:

EXPLAIN ANALYZE
SELECT id, title, date
FROM dle_post
WHERE approve = 1
  AND date <= NOW()
ORDER BY date DESC
LIMIT 20;

EXPLAIN ANALYZE действительно выполняет запрос. Не запускайте его без ограничений на запросах, которые изменяют данные, и не применяйте его к диагностике на пиковом трафике.

Три места, где DLE теряет время

1. Списки публикаций с фильтром и сортировкой

Главная страница и категории обычно отбирают опубликованные материалы, проверяют дату и сортируют результат. Если база сначала читает большое число строк, а потом сортирует их, ограничение LIMIT 20 спасает не всегда: лимит применяется после поиска и сортировки.

Проверьте существующие индексы, а не только текст запроса:

SHOW INDEX FROM dle_post;

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

2. Поиск по публикациям

Поиск по нескольким текстовым полям — частый источник полной проверки таблицы. Индекс обычного типа не превращает поиск по фрагменту строки в быстрый поиск. Если запрос использует шаблон с начальным символом %, например %слово%, B-tree-индекс обычно не помогает.

Не меняйте поисковую логику DLE вслепую. Сначала сравните запросы для короткого и редкого слова, популярного слова и пустого результата. Отдельно измерьте поиск с сортировкой по релевантности и сортировку по дате: это разные планы выполнения.

3. Комментарии, теги и дополнительные поля

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

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

Сравнение подходов к ускорению

Как проверять изменения под нагрузкой

Сравнивайте не только среднее время ответа. Для DLE важны перцентили: p95 показывает, сколько ждут самые медленные 5% запросов, а p99 — самые медленные 1%. Обязательно фиксируйте условия теста:

1. одинаковую копию базы и набор страниц;
2. одинаковое число параллельных клиентов;
3. состояние кеша: холодный или прогретый;
4. версию PHP, DLE, MySQL или MariaDB и параметры сервера;
5. число запросов на страницу, время SQL и количество ошибок 5xx.

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

Где оптимизация ломается

Кеш скрывает проблему

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

Индекс не совпадает с реальным запросом

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

Тяжёлый модуль запускается на каждой странице

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

Обновление DLE меняет поведение

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

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

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