Нагрузка в Joomla: что происходит внутри запроса

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

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

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

1. Веб-сервер принимает запрос. Nginx или Apache обслуживает статические файлы либо передаёт PHP-запрос обработчику. Если включён внешний кеш или CDN, Joomla может вообще не запускаться: готовый ответ отдаётся раньше.
2. Срабатывает точка входа. Для сайта это публичный index.php. Joomla подключает автозагрузку, определяет окружение и создаёт приложение соответствующего типа.
3. Приложение читает конфигурацию. На этом этапе становятся известны подключение к базе данных, режим отладки, настройки кеша, пути к каталогам и параметры сайта. Ошибка здесь затрагивает почти каждый запрос.
4. Загружаются расширения и плагины. Плагины могут менять входные данные, проверять доступ, добавлять заголовки, перехватывать события маршрутизации и обрабатывать результат. Поэтому короткий URL не означает короткий путь внутри PHP.
5. Маршрутизатор выбирает компонент. URL сопоставляется с компонентом и его представлением. Для страницы материала это обычно com_content, но конкретный маршрут может быть переопределён меню, SEF-настройками или сторонним расширением.
6. Компонент получает данные. Контроллер выбирает задачу, модель обращается к базе данных, а представление готовит данные для шаблона. Здесь возникают дорогие запросы, повторные выборки и лишняя загрузка связанных сущностей.
7. Шаблон собирает страницу. Компонент отдаёт основную область, а модули заполняют позиции шаблона. Сам шаблон определяет, какие позиции будут отрендерены и в каком порядке. Затем плагины могут изменить готовый документ перед отправкой.
8. Ответ уходит клиенту. Joomla формирует HTML, отправляет заголовки и завершает PHP-процесс. Браузер после этого отдельно запрашивает CSS, JavaScript, изображения и шрифты.

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

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

Где расходуются ресурсы

PHP и жизненный цикл приложения

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

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

База данных

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

На рабочем стенде смотрите не только на число запросов, но и на их суммарное время. Один запрос на 800 миллисекунд опаснее десяти запросов по 2 миллисекунды. Для анализа используйте инструменты базы данных: журнал медленных запросов и план выполнения. Включать подробное логирование на боевом сайте на длительный срок не стоит: оно само создаёт нагрузку и может раскрыть внутренние данные.

Плагины, модули и шаблон

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

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

Кеширование: какие запросы исчезают, а какие остаются

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

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

Сноска. Инвалидация — удаление или обновление устаревшей записи в кеше после изменения исходных данных. Без неё ускорение превращается в показ старой цены, статуса заказа или текста материала.

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

Без базовой точки нельзя понять, стало ли быстрее. Снимите показатели на копии или в контролируемое окно, сохранив версию Joomla, PHP, базу данных, объём каталога и настройки кеша.

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

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

Граничные случаи и место поломки

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

Отдельный риск — операции, которые кажутся чтением, но запускают тяжёлую работу: пересчёт фильтров, построение поиска, генерация изображений или обращение к внешнему API. Если такой вызов происходит во время обычного HTTP-запроса, пользователь ждёт весь внешний тайм-аут. Для долгих задач нужен отдельный процесс или очередь, а не увеличение тайм-аута страницы.

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

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

Начните с карты одного медленного URL: запишите цепочку от веб-сервера до компонента, список активных плагинов, модули его шаблона и SQL-запросы. Затем повторите замер после одного изменения. В проде поставьте мониторинг времени до первого байта, ошибок 5xx, заполнения PHP-воркеров и медленных запросов базы. Следующим отдельным этапом будет проверка инвалидации кеша и персональных страниц — не объединяйте её с оптимизацией шаблона.