引言
在当今快节奏的商业环境中，实时协作编辑已成为现代生产力应用不可或缺的核心功能。它让远程团队能够高效协作，共同完成创作和编辑任务。本报告深入评估了 Univer 协同引擎在处理多人实时协作编辑时的性能表现，并将其与市场上其他领先产品进行对比。
Real-time Collaborative Editors Performance.pdf
A Research for real-time collaborative editor performances.
在这篇论文中，提出了市场上流行的实时编辑服务中延迟性能测量。提出了协同编辑人数是影响实时编辑系统性能的主要因素，以下是主流实时编辑产品表现：
| Office 365 | 腾讯文档 | 石墨文档 | Google Sheet | 飞书表格 | |
|---|---|---|---|---|---|
| 协同编辑人数上限 | 365 | 200 | 200 | 200 | 200 |
注：上述数据截止于 2022 年。
Univer GitHub 地址：github.com/dream-num/u…
介绍 Univer 协同引擎
为了更好理解测试过程，让我们简要介绍一下 Univer 协同引擎的实现方案。
Univer 协同引擎非常注重扩展性，已支持分布式方案。但为便于叙述，我们将暂时采用单机部署方案来描述。
Univer 协同引擎主要使用两种编程语言：Golang 和 JavaScript。
- Golang 擅长处理高并发和快速网络 I/O，使 Univer 协作引擎能够轻松处理大量客户端连接请求；
- JavaScript（Node.js）使得后端与前端之间的代码共享变得容易，并极大减少了处理冲突错误的可能性。同时也为未来服务器端计算和渲染奠定了重要基础。
Univer 使用 OT（操作转换）作为协同冲突处理的方案。
为了加快单个请求处理速度，协同引擎被设计为有状态服务，即每篇活跃文档在内存中都有一份最新的拷贝，客户端的编辑请求会迅速应用和写入。
有状态服务 Collaboration-server 采用 Node.js 实现，与前端编辑器共享相同的冲突处理代码，包括两个核心方法：
- Transform：实施表格或文档的 OT 算法，对 changeset 进行操作转换；
- Apply：将转换后的 changeset 应用到表格/文档。
无状态服务 Universer 使用 Golang 实现，主要负责调度和网络
- Comb：基于 WebSocket 实现房间服务，用于广播和分发协同事件；
- Snapshot：基于 EventSourcing 模式提供文档快照服务，并高效还原任意版本文档。
以下是用户编辑事件如何被协同引擎处理的过程：
changeset 指的用户编辑后产生的一组变更，通常简称为 cs
性能测试
为全面评估 Univer 协同引擎的性能，我们精心设计了一系列测试，涵盖了关键指标和典型场景。
为方便叙述，介绍几个关键术语：
通俗讲，衡量协同体验最直接的指标是，A 的编辑多久后被 B 应用并展示。
这个过程涉及的变量很多，为简化压测过程，这里提取最关键的变量，并称为“协同延迟”。
协同延迟能有效地衡量 CS 的 transform, apply 的性能。
在当前协同引擎模型下，影响协同延迟的直接因素为 CS 的处理数量，不妨称为 协同并发数。
测试环境：
- ECS 配置为 4 核 8GB 内存
- 采用单机部署模式（docker compose）
预设条件：
- 每个客户端平均发送编辑事件频率约为 0.15 次每秒；
- 当协同编辑人数达到 200 时，协同并发数约为 30（CS QPS=30）；
测量方法：
- 逐步增加协同编辑人数，观察并记录协同延迟情况；
- 测量总时长为 5 分钟；
预期结果：研究协同编辑人数与协同延迟 (pct99) 之间的关系。
测量结果：
| Number of Users | 50 | 100 | 150 | 160 | 170 | 180 | 190 | 200 | 210 | 220 | 230 | 240 | 250 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Latency pct99 (ms) | 32 | 80.4 | 281.9 | 413.4 | 506 | 654.8 | 862.4 | 1352.8 | 2051.2 | 2706.7 | 3662.8 | 4674.6 | 5409.7 |
总结
- 图表显示，在一台普通的 4 核 8GB 服务器上处理 200 个并发用户时，协同引擎协作延迟保持在约 1.3 秒左右；
- 随着协同编辑人数变多，协同延迟逐渐出现非线性的增长，下面是对其指数拟合：
y = 3.92e^(0.03x)
凭借这些基准结果，Univer 协同引擎在实时协作中展现出不俗的性能，处理 200 个并发用户时，协同引擎成功将协作延迟保持在约 1.3 秒左右，接近业界主流产品水平。
同时随着协同人数增加，协同延迟出现指数增长的趋势。我们将继续改进引擎支持大量并发用户的能力，并尽量降低延迟。
下一步
本实验重点关注协同引擎外部的观测数据，如协同延迟和协同人数，然而当协同人数逐渐增多时，协同延迟出现较大幅度增长。分析其原因，需要增加更多的内部视角：如，随着人数增加，与 transform, apply 的处理延迟之间的关系；
此外，随着人数增加，网络吞吐量将成为一个关键因素。我们需要研究编辑人数、网络吞吐量和延迟之间的关系。
再者，多文档数量与延迟之间的关系。本研究仅对单个文档进行实验。在涉及多个文档时，在保持较低延迟的情况下，单个 Node.js 能够承载多少文档呢？由于 Node.js 的单线程特性极大地限制了其并发能力，在处理多个文档时，效率也会有所降低。
通过持续优化和创新，我们有信心让 Univer 协同引擎在实时协作领域脱颖而出，为用户带来更加流畅体验。
原文链接：https://juejin.cn/post/7355439624100855843 作者：阳络
