Нагрузка в DLE: что ломается первым и как это измерить

На DLE сайт может начать отдавать 502 или заметно замедлиться задолго до полной остановки сервера: сначала растёт время ответа динамических страниц, затем очередь PHP-FPM, а после база данных начинает обслуживать запросы с задержками. Ниже — разбор для DataLife Engine 17.x–18.x: где проходит запрос, что обычно заканчивается первым и какие показатели нужно снять до изменений.

Из чего складывается запрос к DLE

Упрощённая цепочка выглядит так: веб-сервер принимает соединение, передаёт PHP-скрипт интерпретатору, DLE загружает конфигурацию и модули, обращается к MySQL или MariaDB, собирает данные для шаблона и возвращает HTML. Если страница уже есть в кеше, часть этой работы может не выполняться.

Статика и динамика нагружают сервер по-разному

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

Первое практическое разделение — смотреть не только на общее число запросов, но и на URL. Если растёт время ответа у статических файлов, проверяйте веб-сервер, диск, сеть и CDN. Если тормозят страницы новостей или поиск, начинайте с PHP, кеша и базы.

Почему кеш не превращает сайт в статический

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

Не стоит считать включённый кеш доказательством готовности к нагрузке. Важно проверить, попадает ли конкретный URL в кеш и сколько запросов действительно доходит до PHP.

Нагрузка в DLE измеряется не количеством посетителей в сутки, а числом одновременных динамических запросов и временем, которое каждый из них удерживает PHP и базу.

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

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

• PHP-FPM или другой обработчик PHP. Если все рабочие процессы заняты, новые запросы ждут в очереди. Пользователь видит долгий ответ, 502 или 504, хотя база ещё может отвечать нормально.
• База данных. Поиск, фильтрация, сортировка, комментарии и страницы с большим числом связанных данных создают больше запросов, чем обычное открытие закешированной новости.
• Файловая система. Кеш DLE, загрузка изображений и работа с большим числом мелких файлов чувствительны к задержкам диска. На перегруженном VPS это проявляется скачками времени ответа.
• Шаблон и подключаемые модули. Тяжёлые виджеты, дополнительные блоки, счётчики и сторонние интеграции могут добавлять запросы или сетевые ожидания на каждую страницу.

Сноска. p95 — значение, быстрее которого выполняется 95% запросов. Оставшиеся 5% показывают хвост задержек: именно там часто скрываются таймауты и жалобы пользователей.

Как отличить очередь PHP от проблем базы

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

Это не повод сразу увеличивать число PHP-воркеров. Больше процессов ускорит обработку только при наличии свободной оперативной памяти и ресурсов базы. Иначе сервер быстрее упрётся в swap, CPU или лимит соединений.

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

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

1. Разделите URL на группы. Возьмите главную страницу, страницу новости, рубрику, поиск и страницу с комментариями. Для каждой группы запишите код ответа, среднее время и p95. Отдельно отметьте, был ли запрос авторизованным.
2. Посмотрите access-лог. Сравните время ответа, количество запросов и долю кодов 5xx. Ищите не только среднее значение: несколько очень медленных запросов могут теряться в общей цифре.
3. Проверьте PHP. Зафиксируйте число одновременно занятых процессов, очередь и перезапуски. Если этих метрик нет, включите штатное наблюдение вашей версии PHP-FPM по официальной документации, не копируя настройки от другой версии.
4. Проверьте базу. На время теста включите журнал медленных запросов с осторожным порогом и ограниченным сроком хранения. После замера разберите конкретные запросы, а не пытайтесь оптимизировать базу целиком.
5. Повторите замер после одного изменения. Меняйте только один фактор: кеш, конкретный модуль, шаблонный блок или индекс. Иначе вы не узнаете, что именно дало эффект.

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

Три направления оптимизации и их цена

Почему «добавить сервер» часто не помогает

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

Масштабирование имеет смысл после определения слоя, который упирается в лимит. Для статических файлов полезен CDN и корректное кеширование заголовков. Для динамики сначала нужно понять, что именно удерживает PHP-процессы.

Граничные случаи: где схема ломается

Всплеск после публикации новости

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

Поиск и фильтры

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

Сторонний код в шаблоне

Внешний счётчик, рекламный блок или API-виджет может добавить задержку, не отражённую в запросах к базе. Если HTML формируется быстро, а браузер долго ждёт полную загрузку, разделите серверное время и время загрузки ресурсов в инструментах разработчика.

Что проверить дальше

Соберите базовый отчёт по пяти группам URL: среднее время, p95, доля 5xx, занятость PHP-процессов и медленные запросы базы. Затем выберите один самый дорогой сценарий — обычно это поиск, страница с тяжёлым блоком или популярная новость — и повторите замер после одного изменения.

Для эксплуатации DLE важнее постоянный график p95 и числа 502/504, чем разовый результат теста. После этого отдельно настройте мониторинг свободной памяти, диска, PHP-FPM и базы. Инвалидация кеша и оптимизация конкретного шаблона — самостоятельные темы, здесь достаточно проверить их вклад в общий путь запроса.