SpreadJS 协同容量估算：别只看在线人数和 CPU 核数

完成 SpreadJS 单文档 1000 人测试后，我们还需要评估：编辑更频繁时，现有配置是否适用。SpreadJS 协同服务要接收编辑、维护文档状态，并向其他客户端广播操作。相同的在线人数，可以对应不同的消息负载。

我们已完成“1000 人、每人每 30 秒编辑一次”的目标测试。下面以单一文档房间为例，讨论怎样估算更高负载，以及为什么不能只按 CPU 核数选服务器。文中 ACK 指服务端的提交确认，op/s 指每秒编辑操作数；presence 指光标和选区等状态同步，LB 指负载均衡器。

用编辑频率估算广播量

设同一文档有 U 个在线用户，每人平均每 T 秒编辑一次，操作速率约为 U/T。若每次操作广播给房间内约 U 个会话，投递量可估算为：

F ≈ U ×（U / T）= U² / T

同一文档的负载	编辑速率估算	编辑消息投递量估算	验证状态
1000 人，每人 30 秒一次	33.3 op/s	约 3.3 万次/秒	已完成该档目标测试
1000 人，每人 15 秒一次	66.7 op/s	约 6.7 万次/秒	未完成该档 1000 人测试
1000 人，每人 6 秒一次	166.7 op/s	约 16.7 万次/秒	未完成该档 1000 人测试
1000 人，每人 2 秒一次	500 op/s	约 50 万次/秒	未完成该档 1000 人测试

同样是 1000 人，30 秒一次改成 6 秒一次，估算投递量增加到 5 倍。表中计算值用于安排测试，不能当成已达到的吞吐。

图中箭头密度表示负载变化趋势，不代表某个配置已经通过对应容量测试。

平方模型在什么条件下成立

这个模型假设每个人都按同样的平均频率编辑，每次操作需要发给约整个房间。更一般的表达是：

编辑消息投递量 F_edit ≈ 编辑操作速率 λ × 平均接收会话数 R
presence 投递量 F_presence ≈ 状态更新速率 r × 平均状态订阅数 R_presence

如果实际只有部分用户编辑，可以直接使用真实的 λ；如果实现仅向部分订阅者发送消息，R 也会变化。本文没有验证 SpreadJS 按可见范围过滤编辑广播的能力，不能把它当作已有优化代入。

多文档应逐个房间估算后求和。对同样一批用户，如果各房间业务独立、用户只订阅自己的房间，平均接收人数可能降低；但不能随意拆分需要共享编辑的同一份文档来满足模型。消息投递量也不等于带宽，还需结合实际包长、协议开销和网络包速率。

先把不同条件下的实测分开

下面将已有记录放在一起，便于查找依据。p95、p99 分别描述约 95%、99% 的记录所对应的延迟上界；不同拓扑的行不能合并成同一轮性能结果。

记录与条件	节点数	单进程编辑投递量粗估	ACK p95	ACK p99
最终分机有线，1000 人/30 秒，presence 关	4	约 8.3k 次/秒	79.3 ms	126.2 ms
最终分机有线，1000 人/30 秒，presence 开	4	约 8.3k 次/秒	193.8 ms	1,278.8 ms
早期单机，1000 人/30 秒	4	约 8.3k 次/秒	628 ms	约 3.7 s
早期单机路径测试，400 人/6 秒	4	约 6.7k 次/秒	约 3～7 s	本文未列
同一组 400 人/6 秒路径测试	8	约 3.3k 次/秒	987 ms	本文未列

单进程投递量按全房间广播且连接均分估算，只计编辑，不含 presence；它不是节点实际计数。这张表也说明，不能从早期路径测试提取一个通用的“每进程最多 3.3k 条/秒”：最终分机测试的条件不同，表现也不同。

CPU 有余量时，为什么仍可能慢

我们在早期单机阶段检查过压测端计时开销、节点事件循环、PostgreSQL、demo 业务库和 LB。数据库没有记录到超过 150 ms 的慢语句或锁等待，事件循环探针也没有解释秒级长尾。

随后，在 400 人、每人 6 秒一次的路径测试中，我们保持总广播量相同，把节点从 4 个增加到 8 个。单进程承担的量约减半，ACK p95 从数秒降到约 987 ms。这提示当时的尾延迟与单进程广播负载有关，但没有定位出适用于所有环境的精确拐点。

一般来说，多核总 CPU 是各进程、各时间段的汇总，不能直接代表某个进程或发送队列的情况。操作可能等在单进程工作队列、socket 发送缓冲或网络出口；一次较短的忙碌也可能被长采样窗口平均掉。事件循环和 GC 也应监控，但不能因此就说它们是本项目已定位的原因。

因此，我们会同时看进程级 CPU、队列和发送情况、网络包速率、压测端积压，以及 ACK/广播尾延迟。加节点可以分担连接与本地投递，不能保证所有等待都随节点数线性下降。

把估算变成配置决策

最终分机测试中，4 个协同节点 CPU 合计约 0.82 核，但它们与 PostgreSQL、Redis 同机，且客户端直连节点。这能作为已测场景的资源基线，不能据此直接承诺两节点足够、再乘倍数支持更高频率，或认为已包含 LB 容量和故障冗余。

如果为实际项目选配置，我们会按以下顺序准备：

1. 明确每个房间人数、活跃编辑速率、操作类型、文档复杂度、presence 频率及网络。
2. 用 λ × R 估算编辑投递量，单独计入 presence，确认压测机也能接收和应用这些消息。
3. 选择起始节点数，在目标 LB、数据库和网络拓扑上跑小规模正确性检查，再逐步加压。
4. 预先写下 ACK/广播 p95、p99、失败率和一致性阈值；稳态达到目标速率且不持续积压后，才比较配置是否合格。
5. 单独做长时间运行和节点故障测试，检查恢复时间、重连后编辑以及剩余节点的负载。

现有数据支持单文档 1000 人、每人每 30 秒一次编辑的基线。对于更高频率，我们会用模型决定测试资源和加压档位，再用目标环境实测确定配置。

（注：部分内容由豆包工作 AI 生成）