Pressidium Starter 并发容量：用负载测试方案购买，不要猜 PHP Worker

1. 没有 Worker 数字，本身就是决策重点

不少托管 WordPress 对比会给出一套直观模型：套餐列出 PHP Worker 或线程数量，一个未缓存请求占用一个 Worker，超出的请求排队。Kinsta 的 PHP 文档可以解释这套通用原理，但它不能证明 Pressidium Starter 拥有相同数量。

Pressidium 的官方资源说明采用不同口径：网站不会被分配固定 CPU 或内存切片，而是在其托管集群上运行。当前 Starter 套餐表列出价格、访问量和 CDN 流量等商业边界，却没有公布固定 PHP Worker。诚实结论既不是“无限”，也不是复制竞争对手数字，而是：容量必须结合真实工作负载，并由 Pressidium 验证。

五万次缓存页面浏览，与五万次未缓存的账户操作并不相同。缓存命中可能绕过 PHP 应用处理；登录、购物车、结账、搜索、个性化后台、Webhook 和管理操作则可能绕过缓存并占用应用时间。

2. 把工作负载写成四项证据表

**流量形状。**记录平时每分钟请求、峰值每分钟请求、峰值持续时间，以及营销活动是否造成突然爆发。月访问量适合做预算，却会掩盖短时峰值。

**动态比例。**列出哪些路径预计为 HIT、MISS 或 BYPASS。Pressidium 的缓存分析文档使用这些分类。重点关注后台、登录、购物车、结账、搜索、账户、Webhook 和 API。

**业务路径。**选择三到五个必须可用的动作，例如打开商品、加入购物车、登录、搜索、提交表单、报名课程或完成支付。不要只测试首页。

**验收阈值。**事先规定响应时间、错误率和积压上限。例如“95% 的结账步骤低于两秒，服务器错误少于 1%，峰值后队列不继续增长”。这只是买方建议阈值，不是 Pressidium SLA。

随后可把 Requests Analytics 和 Performance Analytics 对齐到同一张表：请求路径和状态码说明发生了什么，性能数据说明应用如何响应。单次观察不能变成保证，但能把模糊猜测变成可审计的问题。

3. Starter 价格不等于并发保证

当前官方入门页列出 Starter **年付 299 美元**。它只能作为预算参考；最终税费、账期、购物车和附加项仍以真实订单为准。

常见错误是把 299 美元除以十二，再与公开 Worker 数量的主机比较，并认为两种套餐容量可直接互换。不同平台的架构、缓存、隔离和支持流程可能完全不同。

应分成两栏比较：

- **公开商业范围：**套餐名、年付总额、访问量、CDN 流量、存储与托管服务。 - **已验证应用范围：**动态路径、峰值并发、数据库行为、插件工作、错误率、响应时间和获批测试条件。

如果第一栏合适、第二栏未知，不应立刻升级。先修复慢查询、重复 Webhook 和低效插件，缓存公开响应，并把计划任务移出活动峰值；之后再询问修正后的负载是否仍适合 Starter。

4. 负载测试存在授权边界

Pressidium 的负载测试说明指出，正式负载测试面向 Enterprise 套餐，并要求提前协调和把源 IP 加入白名单。这是硬边界。买方不应直接对生产环境发起大规模合成流量，再把限速、安全防护或保护性动作误判为应用真实上限。

针对 Starter，应先书面询问：

1. 这份准确 Starter 订单是否允许合成负载测试？ 2. 若不允许，有哪些非生产或客服协助的验证方式？ 3. Pressidium 可以复核真实流量样本中的哪些指标和日志？

如果客服要求更高套餐或 Enterprise 流程，应把它当作新的商业决策。本文批准的链接关联 Starter，不代表更高套餐报价已获确认，也不保证自定义测试一定被接受。

5. 第三方测试的用途和边界

Review Signal 等历史评测可以说明 Pressidium 在某个时间、某种场景下的表现，并帮助提出问题：是否命中缓存？使用哪个套餐和区域？动态路径是什么？源 IP 是否获批？错误率达到多少时停止？

它们不能保证当前 Starter 容量。平台软件、硬件、路由、缓存策略、套餐包装和测试工具都会变化。一个历史汇总结果也无法预测拥有不同插件、查询和支付 Webhook 的 WooCommerce 商店。

同样，讨论明确 PHP Worker 数量的同意图对比适合解释模型，但数字仍属于竞争对手。本文因此把 Pressidium Worker 数量明确保留为**未知**，并在中英文正文中披露这一未解决缺口。

6. 实用的购买前验证流程

**第一步：分类页面。**在预发布环境或相近网站上，把关键路径标记为可缓存或动态，并写明原因。

**第二步：记录基线。**正常使用时记录请求量、缓存状态、响应时间、数据库时间和服务器错误，先消除明显应用缺陷。

**第三步：写峰值场景。**明确并发用户、业务动作组合、升压时间和持续时间。“100 个用户”并不完整，因为他们可能只访问缓存首页。

**第四步：申请授权。**把套餐名、源 IP、时间、工具、路径和停止条件发给 Pressidium；没有明确答复就不执行。

**第五步：测试业务路径。**若获批，应包含代表真实动态负载的登录或结账动作，同时排除破坏性操作并保护客户数据。

**第六步：观察恢复曲线。**峰值结束后确认延迟和队列回到基线。测试虽然结束但积压继续增长，不能算通过。

**第七步：记录决定。**保留客服答复、配置、结果日期和验收阈值；插件、主题、PHP 或流量发生重大变化后重新验证。

**有证据的优势及边界。**Pressidium 的**集群托管资源且不公布固定配额**，可避免把平台误解为独占服务器切片，但它并不承诺 Starter 的固定 CPU、内存或 Worker。其**缓存、请求和性能分析**有助于区分缓存命中与动态路径，但观察数据不是合同容量上限。其**客服协调的负载测试流程**有助于明确条件并保护平台，但正式测试文档面向 Enterprise，且必须提前协调。**明确的 Starter 商业入口**提供当前年付 299 美元参考，但价格、访问量和 CDN 额度不能证明动态并发。通用 PHP 线程模型只能帮助理解；同意图对比不能提供 Pressidium 数字；历史 Pressidium 测试只能帮助提问，不能作为当前保证。

7. 谁适合买 Starter？

如果网站以公开可缓存内容为主、动态操作不多、重视托管运维，并愿意验证少数关键路径，Starter 更合适。第一份订单保持可逆、迁移方案含回滚，也能降低风险。

如果收入依赖持续的未缓存并发、采购必须拿到固定 Worker 数量、上线活动要求正式合成测试，或客服无法确认准确套餐，就应暂停购买。应取得书面容量讨论，比较准确的更高套餐，而不是假设访问量额度能解决问题。

8. 最终结论

Pressidium Starter 应被视为具有当前商业范围的托管主机套餐，而不是一组看不见、可随意猜测的 Worker。没有固定配额并不代表无限容量。可靠流程是：分类缓存行为、定义动态业务路径、查看请求与性能证据、取得测试授权，并保存书面决定。

如果这种验证方式符合你的运维习惯，可继续使用已批准的 Pressidium Starter 链接，并在付款前核对最终购物车和套餐条款。若你需要合同化 Worker 数量或大规模活动测试，应暂停并取得具名替代方案。