multiDomainCMS против WordPress Multisite: Тематическое исследование реальной производительности

Управление портфолио веб-сайтов на WordPress имеет хорошо известный предел. Независимо от того, используете ли вы WordPress Multisite или парк независимых установок, архитектура в конечном итоге начинает работать против вас — по памяти, времени отклика, накладным расходам на обслуживание и счетам за хостинг. В этом тематическом исслед��вании описывается реальная разница, которую мы наблюдали после миграции портфолио из 130 сайтов со стека WordPress на multiDomainCMS, нашу собственную SSR-платформу на Node.js.

Исходная база: WordPress в масштабе

WordPress Multisite — это стандартный ответ для запуска множества сайтов из одной кодовой базы. Он объединяет темы, плагины и панель администратора в рамках одной установки WordPress. На бумаге это выглядит эффективно. В реальных условиях эксплуатации ситуация выглядит сложнее.

Модель PHP на каждый запрос

Каждый запрос страницы WordPress запускает новый процесс PHP, загружает ядро WordPress (~сотни файлов), инициализирует соединение с базой данных, запрашивает MySQL для получения поста, выполняет повторный запрос для меню, повторный запрос для виджетов, прогоняет все активные плагины через цепочку хуков и рендерит шаблон темы — прежде чем отправить хотя бы один байт. Даже с объектным кэшированием (Redis/Memcached) и кэшированием опкодов (OPcache) нижний предел ответа WordPress на общей или VPS-инфраструктуре обычно составляет 200– мс TTFB.

Специфические накладные расходы WordPress Multisite

• Один набор таблиц префиксов базы данных wp_ умножается на количество сайтов (wp_2_posts, wp_3_postsи т. д.), увеличивая количество таблиц MySQL до тысяч для крупных сетей
• Совместимость плагинов на разных подсайтах является постоянным бременем для обслуживания: обновление плагина, которое ломает один подсайт, может затронуть всю сеть
• Операции суперадминистратора (активация плагинов для всей сети, миграция пользователей) блокируют общие ресурсы и вызывают пиковые нагрузки
• Лимиты памяти на каждый сайт суммируются: 50 одновременных запросов по 6 МБ каждый — это ГБ ОЗУ до того, как вступят в дело веб-сервер, база данных или слой кэширования

Альтернатива: парк независимых установок

Некоторые агентства предпочитают 130 отдельных установок WordPress вместо Multisite, чтобы избежать жесткой связанности. Операционные накладные расходы масштабируются линейно: 130 наборов обновлений ядра, 130 аудитов плагинов, 130 соединений с базами данных, 130 отдельных заданий cron, 130 расписаний резервного копирования. Это полноценная работа инженера по обслуживанию, а не платформа.

Альтернатива: архитектура multiDomainCMS

multiDomainCMS запускает все 130 доменов из единого процесса Node.js Express, опирающегося на одну коллекцию MongoDB. Архитектура кардинально отличается на каждом уровне.

SSR без налога на запуск

Node.js не выполняет загрузку при каждом запросе. Сервер уже запущен, дерево компонентов React уже скомпилировано, пул соединений с базой данных уже открыт. Поступает запрос, роутер распределяет его по заголовку Host , MongoDB возвращает документ поста, React рендерит его в строку HTML, и ответ отправляется. Весь цикл — для холодного промаха кэша — обычно составляет 8– мс TTFB , измеренный на уровне приложения.

Один процесс, 130 доменов

Объем памяти всей сети из 130 сайтов в multiDomainCMS сопоставим с одной установкой WordPress со средней посещаемостью. Процесс Node.js потребляет в режиме простоя около 180–2 МБ RSS. WordPress Multisite при обслуживании эквивалентного трафика потребовал бы – ГБ ОЗУ до начала использования подкачки (swap). Это не маргинальная разница — она меняет требования к аппаратному обеспечению, которое вам необходимо.

Бенчмарк: прямые сравнения

В чем WordPress все еще выигрывает

Это не полный отказ от WordPress. Он имеет реальные преимущества в определенных контекстах:

• Нетехнические редакторы — редактор Gutenberg и админка WooCommerce отшлифованы, хорошо задокументированы и понятны для неразработчиков
• Plugin ecosystem — более 60,000 плагинов покрывают практически любые сценарии использования без написания кастомного кода
• WooCommerce при небольшом количестве SKU — для небольших магазинов с редким трафиком операционная простота WooCommerce превосходит создание кастомного торгового уровня
• Существующие команды, глубоко работающие с WordPress — если ваша команда отлично знает WordPress, затраты на переход на новый стек вполне реальны

Точка перехода наступает тогда, когда вы управляете множеством ��айтов, ожидаете значительный одновременный трафик или нуждаетесь в базовом времени отклика менее мс. В этот момент модель загрузки PHP становится узким местом независимо от стратегии кэширования.

Размещение этого на WinWinHost

Обе архитектуры доступны в качестве вариантов управляемого хостинга на WinWinHost. Наш управляемый хостинг WordPress автоматически выполняет обновления ядро, аудит плагинов, ежедневное резервное копирование и кэширование объектов Redis. Для агентств и операторов портфолио, которым нужен подход multiDomainCMS, наш хостинг VPS на Node.js включает управление кластером PM2, подготовку MongoDB, настройку обратного прокси Nginx и SSL через Let's Encrypt — все необходимое для работы всего стека без самостоятельного управления инфраструктурой.