Joomla под нагрузкой: что ломается первым и как это измерить

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

Как выглядит отказ под нагрузкой

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

• Время ответа растёт, CPU занят. Возможны дорогие PHP-обработчики, шаблон или расширение, которое выполняет работу на каждом запросе.
• PHP-FPM сообщает, что достигнут предел процессов, или веб-сервер ждёт свободный процесс. Медленные запросы занимают воркеры дольше, и новые посетители стоят в очереди.
• Растёт число ожиданий базы данных. Ищите медленные запросы, блокировки и нехватку соединений; не увеличивайте лимит соединений вслепую.
• Время ответа скачет, а внешние запросы занимают значительную часть запроса. Причиной может быть API оплаты, поиска, доставки или другой удалённый сервис.
• Страницы из кеша быстрые, а динамические операции медленные. Это сигнал исследовать компоненты, которые формируют персональный контент или меняют данные.

Ошибка 502 или 504 — следствие того, что запрос не завершился вовремя или приложение не смогло ответить. Она не называет виновника: причину нужно сопоставлять с журналами веб-сервера, PHP и базы в тот же временной интервал.

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

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

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

Профилировщик нужен для ответа на вопрос «где потрачено время», но не заменяет нагрузочный тест. Встроенный отладчик Joomla помогает исследовать отдельные запросы и выполнение приложения; включать подробную отладку на публичном сайте под нагрузкой рискованно — она добавляет работу и может раскрыть служебные сведения. Сначала воспроизводите проблему на тестовой копии. Для долгого наблюдения сопоставляйте метрики приложения с журналами PHP-FPM, веб-сервера и СУБД.

Порядок поиска узкого места

1. Повторите один и тот же сценарий. Возьмите URL или действие, которое замедляется, и задайте известный профиль запросов. Проверьте результат без нагрузки и на нескольких ступенях параллельности. Успех — у вас есть сопоставимые показатели и точное время теста.
2. Сопоставьте задержки с ресурсами. Посмотрите, растёт ли CPU, заканчиваются ли PHP-воркеры, упирается ли память в лимит и появляются ли ошибки в журналах. Успех — у проблемы есть временная граница и кандидат на узкое место, а не только жалоба «сайт тормозит».
3. Измерьте работу базы. Включите подходящий для вашей СУБД сбор медленных запросов на тестовом окружении и выясните, какие запросы совпадают по времени с задержкой. Проверьте план выполнения и блокировки до того, как менять схему или добавлять индексы. Успех — найден запрос или ожидание, который можно повторно измерить.
4. Сравните кешируемый и динамический запросы. Проверьте заголовки и конфигурацию кеширования, затем повторите тест с теми же условиями. Успех — понятно, какая доля запросов проходит через кеш и что именно остаётся медленным.
5. Изменяйте по одному фактору. На копии сайта отключите или настройте подозрительное расширение, измените один параметр либо оптимизируйте конкретный запрос. Повторите прежний сценарий. Успех — улучшение видно в тех же метриках, а функциональные проверки проходят.

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

PHP-воркеры заняты дольше, чем приходит новая работа

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

База данных тратит время на повторяющиеся тяжёлые запросы

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

Кеш скрывает проблему, но не решает её для всех страниц

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

Расширение или внешний сервис задерживает запрос

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

Оптимизация начинается не с настройки «побыстрее», а с воспроизводимого симптома. Если вы не можете повторить замедление и измерить его, вы не знаете, помогло ли изменение.

Как понять, что изменение помогло

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

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

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

Результат зависит от версии Joomla, PHP, СУБД, расширений, веб-сервера и настроек хостинга. Для Joomla 5.x сверяйте требования с документацией конкретной поддерживаемой ветки; выводы одного стенда нельзя автоматически переносить на другой тариф или конфигурацию. Инвалидация кеша и выбор схемы распределения нагрузки — отдельные темы: здесь речь только о профилировании и поиске первого ограничения.

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

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

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