引言

在當今快節(jié)奏的商業(yè)環(huán)境中，實時協(xié)作編輯已成為現(xiàn)代生產(chǎn)力應用不可或缺的核心功能。它讓遠程團隊能夠高效協(xié)作，共同完成創(chuàng)作和編輯任務。本報告深入評估了 Univer 協(xié)同引擎在處理多人實時協(xié)作編輯時的性能表現(xiàn)，并將其與市場上其他領(lǐng)先產(chǎn)品進行對比。

Real-time Collaborative Editors Performance.pdf

A Research for real-time collaborative editor performances.

在這篇論文中，提出了市場上流行的實時編輯服務中延遲性能測量。提出了協(xié)同編輯人數(shù)是影響實時編輯系統(tǒng)性能的主要因素，以下是主流實時編輯產(chǎn)品表現(xiàn)：

	Office 365	騰訊文檔	石墨文檔	Google Sheet	飛書表格
協(xié)同編輯人數(shù)上限	365	200	200	200	200

注：上述數(shù)據(jù)截止于 2022 年。

Univer GitHub 地址：github.com/dream-num/u…

介紹 Univer 協(xié)同引擎

為了更好理解測試過程，讓我們簡要介紹一下 Univer 協(xié)同引擎的實現(xiàn)方案。

Univer 協(xié)同引擎非常注重擴展性，已支持分布式方案。但為便于敘述，我們將暫時采用單機部署方案來描述。

Univer 協(xié)同引擎主要使用兩種編程語言：Golang 和 JavaScript。

• Golang 擅長處理高并發(fā)和快速網(wǎng)絡 I/O，使 Univer 協(xié)作引擎能夠輕松處理大量客戶端連接請求；

• JavaScript（Node.js）使得后端與前端之間的代碼共享變得容易，并極大減少了處理沖突錯誤的可能性。同時也為未來服務器端計算和渲染奠定了重要基礎。

Univer 使用 OT（操作轉(zhuǎn)換）作為協(xié)同沖突處理的方案。

為了加快單個請求處理速度，協(xié)同引擎被設計為有狀態(tài)服務，即每篇活躍文檔在內(nèi)存中都有一份最新的拷貝，客戶端的編輯請求會迅速應用和寫入。

有狀態(tài)服務 Collaboration-server 采用 Node.js 實現(xiàn)，與前端編輯器共享相同的沖突處理代碼，包括兩個核心方法：

• Transform：實施表格或文檔的 OT 算法，對 changeset 進行操作轉(zhuǎn)換；

• Apply：將轉(zhuǎn)換后的 changeset 應用到表格/文檔。

無狀態(tài)服務 Universer 使用 Golang 實現(xiàn)，主要負責調(diào)度和網(wǎng)絡

• Comb：基于 WebSocket 實現(xiàn)房間服務，用于廣播和分發(fā)協(xié)同事件；

• Snapshot：基于 EventSourcing 模式提供文檔快照服務，并高效還原任意版本文檔。

以下是用戶編輯事件如何被協(xié)同引擎處理的過程：

changeset 指的用戶編輯后產(chǎn)生的一組變更，通常簡稱為 cs

性能測試

為全面評估 Univer 協(xié)同引擎的性能，我們精心設計了一系列測試，涵蓋了關(guān)鍵指標和典型場景。

為方便敘述，介紹幾個關(guān)鍵術(shù)語：

通俗講，衡量協(xié)同體驗最直接的指標是，A 的編輯多久后被 B 應用并展示。

這個過程涉及的變量很多，為簡化壓測過程，這里提取最關(guān)鍵的變量，并稱為“協(xié)同延遲”。

協(xié)同延遲能有效地衡量 CS 的 transform, apply 的性能。

在當前協(xié)同引擎模型下，影響協(xié)同延遲的直接因素為 CS 的處理數(shù)量，不妨稱為 協(xié)同并發(fā)數(shù)。

測試環(huán)境：

• ECS 配置為 4 核 8GB 內(nèi)存

• 采用單機部署模式（docker compose）

預設條件：

• 每個客戶端平均發(fā)送編輯事件頻率約為 0.15 次每秒；

• 當協(xié)同編輯人數(shù)達到 200 時，協(xié)同并發(fā)數(shù)約為 30（CS QPS=30）；

測量方法：

• 逐步增加協(xié)同編輯人數(shù)，觀察并記錄協(xié)同延遲情況；

• 測量總時長為 5 分鐘；

預期結(jié)果：研究協(xié)同編輯人數(shù)與協(xié)同延遲 (pct99) 之間的關(guān)系。

測量結(jié)果：

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

總結(jié)

• 圖表顯示，在一臺普通的 4 核 8GB 服務器上處理 200 個并發(fā)用戶時，協(xié)同引擎協(xié)作延遲保持在約 1.3 秒左右；

• 隨著協(xié)同編輯人數(shù)變多，協(xié)同延遲逐漸出現(xiàn)非線性的增長，下面是對其指數(shù)擬合：y = 3.92e^(0.03x)

憑借這些基準結(jié)果，Univer 協(xié)同引擎在實時協(xié)作中展現(xiàn)出不俗的性能，處理 200 個并發(fā)用戶時，協(xié)同引擎成功將協(xié)作延遲保持在約 1.3 秒左右，接近業(yè)界主流產(chǎn)品水平。

同時隨著協(xié)同人數(shù)增加，協(xié)同延遲出現(xiàn)指數(shù)增長的趨勢。我們將繼續(xù)改進引擎支持大量并發(fā)用戶的能力，并盡量降低延遲。

作者：陽絡
鏈接：https://juejin.cn/post/7355439624100855843
來源：稀土掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。