Миграция MODX Evolution на Revolution: цифры до и после

После миграции с MODX Evolution на Revolution сайт может стать быстрее, медленнее или не измениться вовсе. Сам перенос ресурсов не оптимизирует SQL-запросы, шаблоны и кеш: на результат влияют версия PHP, настройки PHP-FPM, структура чанков, количество TV-полей, некешируемые сниппеты и объём старого кода. Поэтому сравнивать нужно не впечатления «страницы открываются лучше», а одинаковые запросы до и после миграции: TTFB, время генерации, число SQL-запросов, размер ответа и ошибки. Универсальных цифр прироста нет — их получают замером конкретного проекта.

Что именно меняется при переходе на Revolution

Evolution и Revolution используют разные архитектурные подходы. Evolution 1.x исторически рассчитан на работу с одним административным приложением и старым стеком расширений. Revolution построен вокруг xPDO, менеджера пакетов и более формальной модели ресурсов, контекста и настроек. Это даёт новые возможности, но добавляет слой совместимости, который нельзя считать бесплатным.

При миграции чаще всего переносят не только страницы, но и:

• шаблоны, чанки и сниппеты;
• TV-поля и их значения;
• пользователей, группы и права доступа;
• дополнения, плагины и системные настройки;
• изображения, файлы и ссылки на документы;
• интеграции с каталогом, CRM, почтой и платёжными сервисами.

Каждый слой может влиять на скорость. Например, тяжёлый сниппет поиска будет тормозить страницу в обеих системах, а неверно перенесённое кеширование способно добавить запросы уже после перехода на Revolution.

Миграция — это смена платформы, а не бенчмарк. Пока вы не зафиксировали одинаковые условия теста, цифры «до» и «после» ничего не доказывают.

Какие цифры снять до миграции

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

Набор метрик

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

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

Где обычно теряется производительность

Кеширование ресурсов

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

Особенно подозрительны вызовы с восклицательным знаком, сложные сниппеты в шапке и меню, а также плагины, которые выполняют запросы на каждом обращении. Если после миграции TTFB вырос только на холодных запросах, проблема может быть в сборке кеша. Если медленными стали и тёплые запросы, ищите работу PHP, SQL или внешних сервисов.

TV-поля и выборка ресурсов

Большое количество TV-полей удобно для редакторов, но усложняет выборку ресурсов и увеличивает объём данных, который нужно собрать. Это особенно заметно на каталогах, где один запрос выводит десятки или сотни товаров. Не передавайте в шаблон все поля без необходимости: для списка выбирайте только данные карточки, а подробные значения загружайте на странице товара.

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

Сниппеты и плагины

Совместимый синтаксис вызова ещё не означает совместимую производительность. Старый сниппет может использовать устаревший способ выборки, загружать объекты по одному и выполнять N+1-запросов: один запрос на список и отдельный запрос на каждый элемент.

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

PHP, база данных и окружение

Сравнение бессмысленно, если Evolution работал на одной версии PHP и сервере, а Revolution — на другой конфигурации. Зафиксируйте версию PHP, режим PHP-FPM, объём памяти процесса, версию MySQL или MariaDB, включённое сжатие и тип диска. Отдельно проверьте, не выполняется ли на новом сервере отладочный режим.

Версию PHP и совместимость расширений нужно сверять с требованиями конкретного релиза MODX Revolution и установленных пакетов. Для этой статьи ориентир — ветка Revolution 3.x, но минорная версия и набор дополнений могут менять требования.

Как провести сравнение до и после

Порядок важнее красивой итоговой цифры. Тестируйте один и тот же сайт в одинаковом сценарии, а не старую систему ночью и новую в рабочий час.

1. Зафиксируйте окружение. Запишите версии MODX, PHP, СУБД, веб-сервера и расширений. Проверка: у вас есть файл или таблица с параметрами обеих систем.
2. Составьте карту URL. Выберите страницы с одинаковым содержимым и одинаковым уровнем доступа. Проверка: каждый URL из списка открывается в старой и тестовой системе.
3. Разделите холодный и тёплый кеш. Первый прогон выполняйте после очистки кеша, последующие — без очистки. Проверка: в журнале отмечено состояние кеша для каждого замера.
4. Сделайте серию замеров. Используйте один инструмент и одинаковое число повторов. Проверка: для каждого URL записаны медиана, p95 и количество ошибок.
5. Сопоставьте причины, а не только результаты. Если TTFB вырос, сравните SQL, логи PHP и состав вызванных сниппетов. Проверка: у каждого заметного изменения есть техническое объяснение.
6. Проверьте нагрузку после запуска. Наблюдайте за p95, 5xx, медленными SQL-запросами и заполнением диска кешем. Проверка: показатели сняты не только сразу после релиза, но и в период обычного трафика.

Как оформить реальные цифры

Не пишите «сайт ускорился в два раза», если не указаны условия. Корректная запись выглядит так: «для 20 последовательных запросов к карточке товара, при тёплом кеше и одинаковом сервере, медианный TTFB изменился с X до Y, p95 — с A до B, число SQL-запросов — с C до D».

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

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

• Сравниваются разные страницы. После миграции изменился шаблон, количество товаров или объём изображений. Такой тест не показывает эффект платформы.
• Считается только тёплый кеш. Пользователь, который открывает страницу впервые, получает другую задержку.
• В тесте участвует внешний сервис. CRM, карта, CDN или платёжный шлюз могут менять время ответа независимо от MODX.
• Игнорируются ошибки. Быстрый ответ с отсутствующим меню или неработающей формой нельзя считать улучшением.
• Меняются версии сразу всего стека. Если одновременно обновлены PHP, СУБД, сервер и MODX, вклад миграции отдельно не измерить.

Инвалидация кеша и настройка CDN — отдельные темы. Здесь важно только разделять их влияние при сравнении Evolution и Revolution.

Что сделать после миграции

Сначала сохраните отчёт с базовой линией и настройте мониторинг p95 TTFB, доли ответов 5xx и медленных SQL-запросов. Затем разберите три самых дорогих по времени сниппета, проверьте страницы без кеша и повторите тест после каждой отдельной правки. Такой порядок показывает, что действительно ускорило сайт, а не приписывает весь результат самой миграции на Revolution.