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

В DLE проблема под нагрузкой обычно начинается не с одного «медленного SQL-запроса», а с их суммы: список новостей, комментарии, поиск, похожие публикации и дополнительные поля обращаются к базе на каждом запросе страницы. При нескольких сотнях одновременных обращений растёт очередь PHP-процессов, MySQL начинает конкурировать за CPU и диск, а посетитель видит тайм-аут или ошибку 502. Ниже — разбор для DLE 17.x; точную минорную версию и настройки сервера проверьте перед изменениями.

Почему DLE упирается в базу раньше, чем кажется

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

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

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

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

Какие запросы становятся узким местом

Лента новостей и категории

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

Отдельный риск — вывод большого количества материалов на странице. Уменьшение лимита публикаций не решает проблему полностью, но снижает объём HTML, количество связанных операций и время генерации. Важно измерять не только время SQL, но и размер ответа: тяжёлая страница создаёт дополнительную нагрузку на PHP и веб-сервер.

Поиск по сайту

Поиск — частый кандидат на деградацию. Запросы по заголовку и полному тексту публикации могут просматривать значительную часть таблицы, особенно если пользователь вводит короткую или распространённую фразу. Индекс обычного типа не превращает поиск по произвольному тексту в мгновенную операцию.

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

Комментарии, теги и похожие материалы

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

Такой паттерн называют N+1-запросами — вместо одного запроса для набора данных приложение выполняет один общий запрос и ещё по одному для каждого элемента. В DLE источник часто находится не в ядре, а в стороннем модуле, шаблоне или подключённом дополнительном поле.

Как провести разбор, а не угадывать

Сначала зафиксируйте сценарии и условия. Запишите версию DLE 17.x, версию PHP, MySQL или MariaDB, объём базы, число PHP-процессов и тип диска. Без этого сравнение «до и после» легко превращается в впечатление от случайного состояния сервера.

1. Разделите страницы по типам. Проверьте главную, категорию, публикацию с комментариями, поиск и страницу, которую чаще всего открывают по access-логам. Для каждой страницы запишите время ответа, код HTTP, размер ответа и число запросов в минуту. Проверка результата: у вас есть отдельные показатели минимум для пяти сценариев, а не одно среднее число.
2. Включите наблюдение за базой на короткий период. Используйте slow query log MySQL или MariaDB с аккуратным порогом, чтобы собрать реальные медленные запросы во время воспроизводимой нагрузки. Не оставляйте подробное логирование включённым навсегда без оценки объёма файлов и влияния на диск. Проверка результата: в логе видны повторяющиеся запросы, их время и частота.
3. Сгруппируйте запросы по смыслу. Отдельно посчитайте выборки публикаций, поиск, комментарии, теги и запросы сторонних модулей. Одинаковый запрос, выполненный тысячу раз, может быть важнее одного запроса, который выполняется пять секунд. Проверка результата: для каждой группы известны частота и суммарное время.
4. Проверьте план выполнения. Для тяжёлых запросов используйте EXPLAIN в поддерживаемой вашей версией MySQL или MariaDB форме. Смотрите, сколько строк сервер предполагает прочитать, используется ли индекс, появляется ли сортировка или временная таблица. Проверка результата: вы понимаете, почему запрос читает именно такой объём данных, а не просто видите его длительность.
5. Повторите тот же сценарий после одного изменения. Меняйте только один фактор: индекс, лимит списка, модуль или шаблонный блок. Проверка результата: новая и старая серии измерений сделаны на одинаковом объёме данных и при сопоставимой параллельности.

Что сравнивать при оптимизации

Индекс имеет смысл добавлять только после анализа плана и частоты запроса. Индексы на все поля подряд не являются универсальным ускорителем: они увеличивают размер таблиц и стоимость INSERT, UPDATE и DELETE. Для DLE особенно важно учитывать, что префикс таблиц и набор полей могут отличаться от установки к установке, поэтому SQL для индекса нельзя безопасно копировать без проверки схемы.

Что измерять до и после

Минимальный набор метрик выглядит так:

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

Смотрите на p95 и p99 времени ответа, а не только на среднее значение. Средняя страница за 300 миллисекунд может скрывать один из двадцати запросов, который ждёт несколько секунд. Для нагрузки используйте тестовый стенд или заранее согласованный сценарий: публичный стресс-тест продакшена способен сам создать отказ.

Где подход ломается

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

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

Кеш скрывает причину

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

Сторонний модуль меняет картину

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

База уже не помещается в память

Когда рабочий набор данных не помещается в доступную память, растёт число обращений к диску. Увеличение PHP-процессов в этот момент часто ухудшает ситуацию: процессы одновременно создают конкуренцию за CPU и I/O. Сначала проверьте размер таблиц, буферный кеш базы и профиль чтения, затем решайте, нужен ли более быстрый диск или изменение архитектуры.

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

Начните с одного сценария, который чаще всего приводит к тайм-ауту, и соберите его базовые показатели. Затем найдите запрос с максимальным произведением «частота × время», проверьте план выполнения и измените только один фактор. После этого повторите тест на том же объёме данных.

Для продакшена добавьте наблюдение за p95 и p99, количеством медленных запросов, ошибками 5xx и загрузкой диска. Если узким местом оказался поиск или сторонний модуль, не маскируйте проблему бесконечным увеличением кеша: зафиксируйте ограничение, план миграции или решение о замене компонента. Инвалидация кеша и репликация базы — отдельные темы; здесь важнее сначала установить, какой запрос создаёт очередь.