1000 人协同压测的环境瓶颈排查：CPU 争用与 Wi\-Fi

这次 SpreadJS 单文档 1000 人压测，我们设置每人每 30 秒编辑一次，总计约 33.3 op/s，也就是每秒 33.3 次编辑操作。测试还包含 presence，即协作者状态、光标和选区同步。

早期将服务端和模拟客户端放在同一台机器上时，presence 开启后的编辑 ACK p95 达到 36.8 秒，一致性检查也失败。ACK 是服务端对编辑提交的确认，p95 表示约 95% 的记录不超过该值。我们把协同节点从 4 个增加到 8 个，p95 反而达到 44.9 秒。增加节点没有解决问题，接下来需要确认负载到底在哪里积压。

转向压测端的依据是 CPU 采样

一个模拟用户除了提交操作，还要接收其他用户的广播、解码消息、应用到本地文档，并参与一致性检查。1000 人每人每 30 秒编辑一次，按全房间广播估算，约产生 3.3 万次消息投递/秒。模拟客户端需要实际处理这部分工作。

资源记录显示，16 个客户端进程已占用约 19 核 CPU。它们与服务端运行在同一台 22 逻辑核笔记本上；当整机接近饱和时，服务端调度和客户端处理都会受到影响。把服务节点从 4 个加到 8 个，并没有减少客户端接收与应用消息的工作量。

因此，我们将服务端和压测端分到两台机器。这个调整既减少资源争用，也让两端的采样可以分别解释。同机端到端延迟只能说明整条链路变慢，不能单独代表协同服务的容量。

分机后，用接收积压继续检查网络

分机测试先使用 Wi-Fi。presence 关闭时，ACK p95 仍达到约 55 秒，客户端积压约 1800 条消息。两端不再争用同一台机器的 CPU，但接收队列持续增长，这给出了继续检查网络的依据。

协同广播包含大量小包。网络带宽表示每秒能传输多少字节，但包速率、无线重传和排队也会影响延迟。仅看出口没有达到网卡标称带宽，无法排除网络受限。这里的消息投递次数、TCP 段数和实际网络包数也不是同一个指标，不能直接互换。

随后，我们将两台机器改用同交换机的有线千兆连接，测得 RTT（网络往返时间）小于 1 ms，未观测到丢包。presence 关闭时，ACK p95 降为 79.3 ms。网络方式改变后，延迟和负载达成结果发生变化，支持本项目将此前的分机 Wi-Fi 环境判为测试瓶颈；但我们没有逐包拆分无线重传和排队各自的耗时。

这是环境示意图，没有数值坐标轴。上方表示压测端受限或使用 Wi-Fi 的情况，下方表示压测端与服务端分离并使用有线连接；图中的告警图标不代表服务端进程已经故障。各组实测数据见下表。

几组结果放在一起看

测试条件	Presence	编辑 ACK p95	同期观测
服务端与压测端同机，4 节点	开启	36.8 s	压测进程约占 19 核，一致性检查失败
仍同机，服务节点增至 8 个	开启	44.9 s	客户端负载未降低
两台机器，通过 Wi-Fi 连接	关闭	约 55 s	客户端积压约 1800 条消息
两台机器，同交换机有线连接	关闭	79.3 ms	达到 33.3 op/s，正确性检查通过
同样的分机有线条件	开启，每 5 次编辑更新状态	193.8 ms	达到 33.3 op/s，正确性检查通过

这是一张排查记录表，各组并非全部只改变一个变量，不能把首尾差值全归因于某一个改动。较直接的网络对照是 presence 关闭的 Wi-Fi 与有线两组。

最终有线测试采用 SDK 模拟客户端，覆盖协议、编辑和广播处理，不包含浏览器界面渲染。用户在 60 秒内逐步加入，再保持 180 秒稳态；它也没有经过负载均衡器（LB），不能据此判断 LB 的容量。

我们现在怎样检查一轮压测

排查这几组结果后，我们会同时保留以下证据，而不是只保存一张延迟汇总表：

检查项	至少保留的记录	用途
负载是否达到	实际加入人数、加入曲线、稳态时长、实际 op/s	避免目标设为 1000 人，实际未达到
压测端是否跟得上	每进程 CPU、接收与应用速率、持续积压情况	判断模拟器是否先受限
服务端和网络情况	节点、数据库和 Redis 资源，RTT、丢包、带宽及包速率	查找计算、存储或传输瓶颈
操作与内容是否正确	提交数、ACK、失败、断线、远端操作记录、最终版本及哈希	区分响应完成与内容一致

如果再安排类似测试，我们会先跑小规模正确性检查，再逐步加压；一旦延迟增长，就同步查看两端资源和接收积压。只有压测端能够产生并处理目标流量，才适合继续讨论被测服务的容量。

对于跨地域或无线接入的真实业务，仍应按实际网络复测。有线低延迟环境提供的是一个基线，不意味着真实用户必须都在同一交换机，也不能保证其他网络下获得相同延迟。