引言

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

Real-time Collaborative Editors Performance.pdf

A Research for real-time collaborative editor performances.

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

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

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

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

介紹 Univer 協(xié)同引擎

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

Univer 協(xié)同引擎非常注重?cái)U(kuò)展性，已支持分布式方案。但為便于敘述，我們將暫時(shí)采用單機(jī)部署方案來(lái)描述。

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

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

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

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

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

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

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

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

無(wú)狀態(tài)服務(wù) Universer 使用 Golang 實(shí)現(xiàn)，主要負(fù)責(zé)調(diào)度和網(wǎng)絡(luò)

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

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

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

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

性能測(cè)試

為全面評(píng)估 Univer 協(xié)同引擎的性能，我們精心設(shè)計(jì)了一系列測(cè)試，涵蓋了關(guān)鍵指標(biāo)和典型場(chǎng)景。

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

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

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

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

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

測(cè)試環(huán)境：

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

• 采用單機(jī)部署模式（docker compose）

預(yù)設(shè)條件：

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

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

測(cè)量方法：

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

• 測(cè)量總時(shí)長(zhǎng)為 5 分鐘；

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

測(cè)量結(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é)

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

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

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

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

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