Миграция MODX Evolution на Revolution под нагрузкой

Миграция с MODX Evolution на Revolution под нагрузкой чаще всего заканчивается не ошибкой в шаблоне, а цепочкой отказов: база данных упирается в соединения, кеш массово сбрасывается, старые дополнения начинают выполнять тяжёлые запросы, а часть URL перестаёт совпадать с прежней структурой. Ниже — разбор для MODX Evolution 3.x и MODX Revolution 3.x: что проверить до переключения, какие узкие места проявляются первыми и как провести нагрузочный прогон без риска для рабочего сайта.

Почему перенос нельзя считать обычным обновлением

Evolution и Revolution — разные ветки MODX с разной архитектурой ядра, набором дополнений и подходами к работе с кешем, контекстами и настройками. Поэтому перенос обычно состоит из нескольких операций: экспорт контента, перенос файлов, адаптация шаблонов и сниппетов, настройка дополнений, проверка URL и отдельный перенос пользовательских данных.

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

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

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

Что проверить до первого прогона

Сначала зафиксируйте поведение Evolution. Без этого после миграции будет непонятно, что именно сломалось: новая платформа или уже существовавшая проблема.

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

Для теста используйте копию продакшен-данных без реальных токенов и персональных данных. На стенде должны совпадать версия PHP, веб-сервер, тип базы, настройки OPcache и основные параметры PHP-FPM. Иначе результаты нельзя сравнивать с рабочим сайтом.

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

1. Пул соединений с базой

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

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

2. Холодный кеш после переключения

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

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

3. Сниппеты и плагины с запросом на каждый ресурс

В Evolution старое дополнение могло работать приемлемо на небольшом каталоге, а после переноса стать главным потребителем базы. Типичный сценарий — запрос к таблице для каждого элемента списка, повторное получение одного и того же объекта или чтение настроек из базы при каждом вызове.

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

4. Сессии и авторизованные пользователи

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

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

5. URL, редиректы и тяжёлые ошибки

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

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

Как сравнивать Evolution и Revolution на стенде

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

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

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

• Общий рабочий сервер. Нагрузочный тест на продакшене смешивает пользовательский трафик и тестовые запросы. Результат непредсказуем, а риск простоя реален.
• Полная очистка кеша во время пика. Вы одновременно убираете защитный слой и заставляете сайт заново собирать страницы.
• Неполная копия данных. На маленькой тестовой базе запрос может занимать миллисекунды, а на рабочем объёме — держать соединение секунды.
• Старые дополнения без проверки совместимости. Рабочий код Evolution нельзя автоматически считать совместимым с Revolution: меняются точки интеграции, настройки и ожидания от ядра.
• Один сценарий проверки. Быстрая главная страница не говорит о состоянии поиска, импорта, корзины и панели управления.

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

План переключения с возможностью отката

1. Заморозьте изменения контента на время финальной синхронизации или определите точный порядок повторного переноса.
2. Перенесите данные и файлы на новый стенд, адаптируйте шаблоны и дополнения, затем очистите кеш Revolution.
3. Прогоните гостевые, авторизованные и административные сценарии на данных, близких к рабочим.
4. Подготовьте переключение DNS или веб-сервера с заранее известным временем возврата на Evolution.
5. После переключения следите за 5xx, p95, активными соединениями базы, загрузкой PHP-FPM, ошибками сессий, 404 и очередью фоновых задач.

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

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

После миграции не удаляйте стенд Evolution сразу. Сохраните его как контрольную точку и сравните с Revolution не только скорость, но и результаты запросов: количество товаров в разделе, права доступа, URL, отправку форм и фоновые операции. В продакшене поставьте алерты на p95, 5xx, исчерпание соединений базы и заполнение диска кешем.

Следующий практический шаг — снять профиль десяти самых посещаемых URL и пяти самых дорогих SQL-запросов через неделю после переключения. Это покажет, что стало узким местом именно на ваших данных, а не в абстрактном сравнении двух веток MODX.

Версии: рекомендации относятся к MODX Evolution 3.x и MODX Revolution 3.x. Перед миграцией сверяйте совместимость конкретных дополнений, PHP и базы данных с документацией используемой минорной версии.