Как найти причину медленной Joomla 4.4 после апдейта

Если после обновления Joomla 4.4 сайт замедлился, сначала сравните метрики и проверьте журналы, PHP-расширения и настройки кэша. Сам апдейт не доказывает, что сломалось ядро: причина может быть в окружении, кэше или расширении. Покажу порядок проверки и безопасные варианты исправления.

Что на самом деле происходит с кэшем после обновления Joomla 4.4

Начну с неприятного: совпадение по времени ещё не доказывает, что виновато ядро Joomla. После обновления кэш может оказаться пустым и наполняться заново, но это не универсальный эффект каждого апдейта. Если параллельно меняли PHP, у новой версии могут отсутствовать нужные расширения. Отдельно проверьте OPcache: при выключенной проверке временных меток он может хранить старый байткод до ручного сброса. Это разные причины, и лечить их одной галочкой бесполезно. Если нужна постоянная поддержка стека, у нас есть внедрение и поддержка open-source, но сначала соберите данные.

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

Не откатывайте Joomla только ради скорости, пока не установили причину. Возврат старой версии может вернуть и уже исправленные ошибки безопасности, а исходную проблему PHP, кэша или расширения оставить на месте. Сначала зафиксируйте симптомы, затем проверьте кэш страниц, кэш данных, OPcache, сессии и базу по отдельности. Иногда узких мест несколько. Вывод делаем по логам и повторяемым замерам, а не по ощущению «вчера было быстрее».

Как быстро понять, где именно тормозит сайт

Я начинаю со встроенной отладки Joomla на тестовой копии или в короткое окно диагностики с ограниченным доступом. В панели можно увидеть время выполнения и SQL-запросы; сравните одинаковую страницу при одинаковых условиях. Большое число запросов само по себе не доказывает поломку кэша: страница может быть сложной, а результат зависит от расширений и состояния пользователя. После проверки отключите отладку: Joomla предупреждает, что диагностические сведения не следует оставлять включёнными на рабочем сайте.

Затем проверяю PHP именно веб-процесса. Команда php -m показывает модули CLI, но PHP-FPM может использовать другой бинарный файл и другой набор расширений. Сверьте версию и модули через системную информацию Joomla или конфигурацию пула FPM; не публикуйте phpinfo() на доступном извне адресе. Если Redis или Memcached есть в CLI, это ещё не означает, что расширение доступно сайту.

Проверьте доступность сервиса и динамику счётчиков. redis-cli ping подтверждает ответ Redis, а INFO stats показывает накопительные keyspace_hits и keyspace_misses; сравнивайте их прирост на одинаковом сценарии, а не требуйте, чтобы hits всегда были выше misses. У Memcached команда stats отдаёт, среди прочего, get_hits и get_misses. Счётчики не объяснят причину сами, поэтому сопоставьте их с логом PHP, адресом подключения и выбранной базой.

• Отладка Joomla: одинаковая страница и SQL-запросы
• Сверка модулей CLI и PHP-FPM
• Redis: ping и прирост счётчиков INFO stats
• Memcached: get_hits/get_misses и журнал PHP

Где Joomla 4.4 хранит настройки кэша и что ломается в configuration.php

Параметры глобального кэша Joomla сохраняются в configuration.php в корне сайта. Среди них $caching (0 — выключен, 1 — консервативный, 2 — прогрессивный), $cache_handler, $cachetime в минутах и $cache_platformprefix. В Joomla 4.4 у Redis есть параметры $redis_server_host, $redis_server_port, $redis_server_auth, $redis_server_db и $redis_persist; у Memcached — $memcached_server_host, $memcached_server_port, $memcached_persist и $memcached_compress. Конкретный обработчик доступен только при установленных PHP-расширении и сервере.

Не вписывайте обработчик вручную, пока не проверили поддержку установленной сборкой и доступность расширения в веб-SAPI. После сохранения в админке проверьте фактическое значение в configuration.php и журнал PHP. Joomla обычно делает файл доступным для записи только на время сохранения и возвращает права обратно; если запись не удалась, админка должна сообщить об ошибке. Не выводите секрет Redis в статье или тикете: настройка $redis_server_auth может содержать пароль.

Файловый кэш зависит от доступности и прав каталога, а также от скорости диска. Сначала выясните, какой именно каталог указан в настройках; не удаляйте содержимое cache и administrator/cache наугад, пока сайт работает. В Joomla 4 CLI доступна команда очистки php cli/joomla.php cache:clean; запускайте её из корня установки от подходящего системного пользователя и проверьте результат. На Linux df -i показывает свободные inode — это полезно, когда новые файлы не создаются при наличии свободного места.

Кэш страниц, OPcache и сессии: три слоя, которые нельзя путать

В Joomla есть несколько независимых механизмов. System Cache хранит данные компонентов и модулей; системный плагин System – Page Cache может отдавать сохранённый HTML страницы. OPcache хранит скомпилированный PHP-код на уровне PHP и не заменяет кэш Joomla. Поэтому фраза «включите кэш» без уточнения слоя — почти бесполезный совет: сначала выясните, какой механизм включён и где видна задержка.

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

Для OPcache сначала посмотрите opcache.validate_timestamps. Если проверка отключена, PHP не заметит изменения файлов до ручной очистки OPcache или перезапуска соответствующего веб-процесса. Перезагрузка PHP-FPM — один из способов, но имя службы зависит от системы и установленной версии; не копируйте вслепую php8.2-fpm. Сессии — отдельная настройка: Joomla по умолчанию использует базу данных, а Redis и Memcached требуют доступных PHP-расширений. Перед сменой обработчика проверьте сохранность сессий и возможность отката конфигурации.

Как выбрать Redis или Memcached для Joomla 4.4

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

У Redis есть выбор логической базы в поддерживаемых режимах и настройки доступа; детали зависят от режима развёртывания. Memcached не следует считать защищённым паролем по умолчанию: ограничьте доступ сетью и настройками сервиса. Оба сервиса могут потерять данные при перезапуске — поведение зависит от настроек сохранения и самого сервиса. Для кэша это обычно означает повторное заполнение; для сессий последствия нужно оценивать отдельно. Не смешивайте в одном выводе кэш и хранение состояния пользователей.

Порядок настройки простой: сделайте резервную копию, установите расширение под используемую веб-версию PHP, настройте сервис на доступ только с нужного хоста или приватной сети и включите обработчик в Joomla. Параметры подключения проверьте в configuration.php, затем прогрейте несколько страниц и сравните время ответа, запросы к базе, ошибки и статистику сервиса. Не задавайте allkeys-lru как универсальный рецепт: политика вытеснения должна соответствовать тому, храните ли вы только кэш или ещё и важные данные.

Если Redis используется только как кэш, контролируйте память и вытесненные ключи через INFO; сама цифра keyspace_hits без знаменателя не говорит, что сайт стал быстрее. Для Memcached используйте stats и сопоставляйте чтения с нагрузочным сценарием. Убедитесь, что конфигурация после теста переживает перезапуск PHP, а журнал не показывает ошибок подключения. Если метрики не улучшились, вернитесь к более простому обработчику и ищите узкое место в коде, базе или сети.

• Уточнить, зачем нужен внешний обработчик
• Проверить PHP-расширение в веб-SAPI
• Ограничить сетевой доступ к сервису
• Сравнить замеры до и после настройки

Разбор без выдуманных цифр: как локализовать сбой

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

Дальше отключаю по одному подозрительному слою на тестовой копии, чтобы сравнить поведение. Проверяю System Cache и Page Cache раздельно, затем состояние OPcache и совместимость расширений. Такая проверка занимает столько, сколько требует сайт: обещание «за сорок минут» без доступа к журналам и стенду — реклама, а не технический вывод. Фиксирую каждое изменение и возвращаю настройки, если результат не повторяется.

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

Чек-лист перед следующим обновлением Joomla

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

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

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

• Бэкап с тестом восстановления
• Предварительная проверка обновления в админке
• Версия PHP и расширения redis/memcached
• Метрики до: время и число SQL-запросов
• После: сброс OPcache, проверка configuration.php, прогрев

Частые вопросы