WPX Agency资源上限：200个站共享300个PHP Workers够用吗？

每站$2有占用率前提

空站位不会降低预付款。把五年总价按已占用站点分摊，50站约 **$8/站/月**，100站约 **$4**，120站约 **$3.33**，200站才约 **$2**。这些是Toolnavia规划算术，不是WPX独立报价。

应估算第1、12、36和60个月仍在付费的客户站数量。若长期占用率不稳，应比较多个Elite账户、分批迁移或其他服务商。30天退款保证有资格条件，续费和排除项目不退款。 它不是五年性能保证。

300个workers不等于每站保证1.5个

200站满占用时，简单平均为 **每站1.5个workers、0.03个CPU核心、0.5GB RAM和1.5GB存储**。这些比例只能提示密度风险。WPX公布的是账户总量，没有承诺为每站预留隔离切片。

一个PHP worker一次处理一个动态请求。workers全忙时，新的未缓存请求会排队；长期饱和可能导致超时。 缓存页面通常绕过PHP，所以相同访问量的站群也可能需要完全不同的worker容量。 展示站不能与WooCommerce、会员站、LMS或繁忙后台等量齐观。

真正该问的不是“300是否大于200”，而是“同一时刻有多少未缓存请求，每个请求占用worker多久”。

6个CPU核心可能先成为共享瓶颈

增加workers不能凭空增加CPU。WPX列出6个核心，并说明会监测账户CPU；持续高负载可能需要优化和支持。 其他托管平台的官方技术资料也指出：数据库、未缓存PHP、备份和结账请求更消耗CPU，而缓存展示流量轻得多。

200站可能在cron、备份、扫描、导入或活动流量同时发生时形成峰值。应错开任务，把最重的商店单独部署，并记录最忙一小时的CPU、延迟、缓存命中率和worker饱和，而不是只看月访客。

无限访客不等于无需规划并发

WPX把访客和带宽标为无限。 这减少了简单访客计费悬崖，但有限计算、存储和合理使用边界依然存在。集中迁移前，应收集至少一周的峰值数据：每分钟未缓存请求、p95响应时间、缓存命中率、结账/登录/API活动、cron和备份计划、数据库大小及历史饱和事件。

如果拿不到这些数据，应分批迁移，而不是一次搬入200站。

站位与资源消耗不是一回事

站位是管理计数，不是性能单位。WPX说明子目录不新增站位，一些多站点别名也可能不新增站位，但所有工作仍共享账户资源。 不能据此推导“免费容量”。

应书面询问每个staging是否占站位、4,000个数据库如何执行、迁移临时副本是否计数，以及workers是账户总池还是按环境治理。公开表格给出总量，但没有回答所有拓扑问题。

三种实际情景

**50个混合站：** 平均为6个workers、2GB RAM和6GB存储；余量可能较宽，但成本约为$8/站/月。

**100个以缓存为主的站：** 平均为3个workers、1GB RAM和3GB存储；若峰值已测且维护任务错开，可能适合，成本约$4/站/月。

**200个活跃站：** 达到广告中的$2/站，但平均降到1.5个workers和0.03个CPU核心。缓存站可能很轻，少数重站却能主导共享池，必须做验收测试。

什么时候应拆分

需要合同隔离、独立故障域、超大数据库、预留计算、独立账单归属或持续高动态并发的客户，适合留在账户外。GridPane建议大型组合用多个较小服务器分散风险，虽然架构与WPX不同。 原则仍有价值：单一控制台不能让一次事件影响整家机构。

支付$23,999.60前的四道门

1. **占用率：** 保守预测下仍有足够付费站点。 2. **并发：** 已测量峰值未缓存工作。 3. **拓扑：** WPX支持确认站位、staging、数据库与worker规则。 4. **退出：** 每个客户都有独立备份、DNS清单与迁移路径。

**结论：** 对可测量、缓存友好且会充分使用200站位的组合，WPX Agency可能很合适。但300个workers不是每站保证1.5个，低占用率也拿不到$2/站的经济性。应在退款期内验证代表性站点并取得书面支持答复，再集中整个组合。