multiDomainCMS vs WordPress Multisite：真实世界性能案例研究

在 WordPress 上管理一组网站存在着一个众所周知的上限。无论你运行的是 WordPress Multisite（多站点）还是大量独立的安装实例，这种架构最终都会与你产生冲突——体现在内存、响应时间、维护开销以及托管账单上。本案例研究记录了我们将一个包含 130 个网站的网站群从 WordPress 技术栈迁移到 multiDomainCMS（我们内部的 Node.js SSR 平台）之后观察到的实际差异。

基准：大规模的 WordPress

WordPress Multisite 是从一个代码库运行许多网站的标准方案。它将主题、插件和管理后台整合在一个 WordPress 安装中。在纸面上，它看起来很高效。但在生产环境中，现实要复杂得多。

每个请求一个 PHP 的模型

每一个 WordPress 页面请求都会启动一个新的 PHP 进程，加载 WordPress 核心（约数百个文件），初始化数据库连接，向 MySQL 查询文章，再次查询菜单，再次查询小部件，让所有活动的插件通过其钩子链运行，并渲染主题模板——然后才发送第一个字节。即使使用了对象缓存（Redis/Memcached）和字节码缓存（OPcache），在共享或 VPS 基础设施上，WordPress 响应的底线通常也是 200–600ms TTFB.

WordPress Multisite 的特定开销

• 单个 wp_ 数据库前缀表集会随着站点数量成倍增加（wp_2_posts, wp_3_posts等），导致大型网络的 MySQL 表数量膨胀到数千个
• 子站点之间的插件兼容性是一个持续的维护负担——破坏一个子站点的插件更新可能会影响整个网络
• 超级管理员操作（全网插件激活、用户迁移）会锁住共享资源并使负载飙升
• 每个站点的内存限制累加起来：50 个并发请求，每个 128MB，就是 6.4GB RAM——这还不算 Web 服务器、数据库或缓存层

替代方案：大量独立的安装实例

一些机构倾向于用 130 个独立的 WordPress 安装来代替 Multisite，以避免耦合。运维开销呈线性扩展：130 套核心更新、130 个插件审计、130 个数据库连接、130 个独立的定时任务、130 个备份计划。这是维护工程师的全职工作，而不是一个平台。

替代方案：multiDomainCMS 架构

multiDomainCMS 从一个由单个 MongoDB 集合支持的单 Node.js Express 进程运行所有 130 个域。该架构在每一层都有根本的不同。

没有启动税的 SSR

Node.js 不会按请求启动。服务器已经在运行，React 组件树已经编译好，数据库连接池已经打开。一个请求到达，路由器通过 Host 头进行分发，MongoDB 返回文章文档，React 渲染为 HTML 字符串，响应被发送。整个周期（对于冷缓存未命中）在应用层测量通常是 8–35ms TTFB measured at the application layer.

一个进程，130 个域名

整个 130 站点网络在 multiDomainCMS 中的内存占用与单个中等流量的 WordPress 安装相当。Node.js 进程的空闲 RSS 约为 180–220MB。提供同等流量的 WordPress Multisite 在使用交换空间（swap）之前需要 2–4GB 的 RAM。这不是微不足道的差异——它改变了你需要的硬件级别。

基准测���：正面交锋数据

WordPress 仍然胜出的地方

这并不是对 WordPress 的全面否定。它在特定上下文中具有真正的优势：

• 非技术编辑 ——Gutenberg 编辑器和 WooCommerce 管理后台经过精雕细琢、文档齐全，并且可以向非开发人员进行培训
• 插件生态系统 ——60,000 多个插件几乎涵盖了所有用例，无需自定义代码
• 低 SKU 数量下的 WooCommerce — 对于流量不大的小型店铺而言，WooCommerce 的运营简单性胜过构建自定义电商层
• 拥有丰富的 WordPress 开发经验的团队 — 如果您的团队对 WordPress 了如指掌，那么切换新技术栈的成本是真实存在的

临界点在于：当您需要管理多个站点、预期的并发流量较大，或者需要将 毫秒以下的响应时间作为基准时。在这种情况下，无论采用何种缓存策略，PHP 启动模型都会成为瓶颈。

将此托管在 WinWinHost 上

这两种架构均可在 WinWinHost上作为托管主机选项提供。我们的 托管 WordPress 主机 可自动处理核心更新、插件审计、每日备份和 Redis 对象缓存。对于希望采用 multiDomainCMS 方法的代理商和组合运营商，我们的 Node.js VPS 主机 包括 PM2 集群管理、MongoDB 配置、Nginx 反向代理配置以及通过 Let's Encrypt 获取的 SSL — 无需自行管理基础设施即可运行完整技术栈所需的一切。