Collabora Online 與 ONLYOFFICE：資源使用與延遲測試

在 Collabora Online 和 ONLYOFFICE Docs 之間進行選擇通常被視為功能或檔案格式的問題，但基礎架構團隊通常會在部署後發現第二個需要考慮的問題：每個平台消耗多少 CPU 和記憶體？隨著往返時間和並發量的增加，編輯回應速度還能維持多久？由於文件複雜性、字體、轉換工作量、儲存延遲、瀏覽器行為、反向代理以及同時開啟的文件數量等因素都會影響結果，因此對於這兩個產品，都沒有一個可靠的通用數值。

截至 2026 年 10 月，兩家廠商均未發布彼此之間可直接比較的最新基準測試。這一點至關重要。因此，公平的比較應區分兩種證據：廠商提供的資源配置指南（告知您每個專案預期所需的資源配置）以及在相同硬體上執行的可重複的延遲/資源測試。以下測試方案旨在產生可用於您自身部署的數據，而無需假設某個實驗室結果適用於所有情況。

官方資源指南的實際內容是怎麼說的？

供應商會發布一些有用的資源配置訊息，但這些數值並不完全等同。 Collabora 的 SDK 手冊中包含一個 Kubernetes/Helm 生產環境範例，建議資源請求為 4 個 CPU 和 6 GiB 內存，上限為 8 個 CPU 和 8 GiB 內存。手冊還描述了一種機制num_prespawn_children，即保持子進程就緒，以便新會話能夠更快地啟動，但代價是會佔用額外的記憶體。請參閱Collabora Online SDK 手冊。 Collabora 目前的配置範本也公開了記憶體比例限制和每個文件的並發控制；該專案的官方原始碼可在Collabora Online 配置範本中找到。

ONLYOFFICE 為 Docker 版 Docs Community Edition 發布了更明確的配置指南。其目前的指南建議至少需要 4 GB 內存，並列出了參考配置：對於少於 100 個並發活躍用戶，建議使用一個 2.8 GHz 的核心；對於 100-200 個並發活躍用戶，建議使用兩個核心；對於 200-400 個並發用戶，建議使用四個核心配置，所有參考內存要求至少 4 內存。 ONLYOFFICE 特別提醒，實際容量取決於文件​​的數量、類型和大小。請參閱ONLYOFFICE Docs Community Edition Docker 的要求。

為什麼空閒記憶體螢幕截圖不能當基準測試？

常見的比較方法是同時啟動兩個容器，不開啟任何文檔，然後判定記憶體佔用較低的容器勝出。這種方法只能衡量基準記憶體佔用，而忽略了真正重要的工作：開啟檔案、必要時進行檔案轉換、渲染頁面或工作表、傳輸變更、重新計算電子表格、為多個編輯器提供服務以及將結果儲存回儲存。

Collabora 的流程模型可以事先準備好子流程。這雖然會增加空閒資源佔用，但可以減少文件可用前的延遲。 ONLYOFFICE 將文件編輯與轉換等服務分開；其架構文件描述了文件編輯器、編輯服務、命令服務、轉換服務和建構器服務。請參閱ONLYOFFICE 文件的工作原理。換句話說，基準 RSS 是一個有用的運行指標，但不足以預測使用者可見的速度。

公平的資源和延遲測試設置

請在同一台主機上或兩台配置完全相同的虛擬機器上依序執行這兩個產品。避免在主機預熱並快取檔案後立即測試其中一個產品，而在主機啟動後立即測試另一個產品。請確保 Linux 發行版、Docker 版本、CPU 配額、記憶體限制、儲存類別、反向代理、TLS 終止、瀏覽器版本和文件儲存路徑完全相同。

使用三種文件工作負載

• 文字檔案：一個具有標題、表格、圖像、追蹤更改和註釋的代表性 DOCX 檔案。
• 電子表格：一個包含公式、條件格式、多個工作表以及足夠資料以觸發有意義的重新計算的 XLSX 檔案。
• 簡報：包含圖片、圖表和多張投影片的 PPTX 文件，而不是幾乎空白的簡報。

兩個平台都應使用相同的文件。如果某個文件在一個產品中需要格式轉換，請務必記錄下來，因為格式轉換會佔用大量開啟時間。不要專門針對某個編輯器最佳化文件，然後將結果作為通用平台的比較依據。

在多個並發層級進行測試

一個實用的測試順序是：依序開啟 1、5、10 和 20 個編輯器，然後達到與預期峰值相符的更高開啟數。 「使用者」在每次測試中應指同一使用者：一個文件完全開啟的編輯器標籤頁。在進行預熱測試後，每個開啟數等級至少重複三次，並報告中位數和最慢的測試結果。這樣可以降低短暫的背景高峰對結論的干擾。

要記錄的資源指標

Docker 提供了一個與廠商無關的第一層遙測資料。官方 Docker 統計文件解釋說，docker stats它會報告 CPU 使用率、記憶體使用情況、網路 I/O、區塊 I/O 和進程 ID (PID)。它既可以捕獲工作負載期間的即時資料流，也可以在定義的檢查點捕獲無流樣本。

docker stats collabora --no-stream
docker stats onlyoffice --no-stream

對於每個並發級別，記錄打開任何文件之前的空閒內存、所有文件打開後的穩定內存、打開文件期間的 CPU 峰值、會話穩定後的 CPU 使用率以及每個會話關閉後的內存使用率。同時觀察冷卻期後記憶體使用率是否恢復至基線水準。較高的測試後記憶體使用率並不一定意味著記憶體洩漏——快取和共享記憶體可能仍然有效——但如果在重複相同的測試週期中記憶體使用率持續上升，則需要進行調查。

如果某個容器的 CPU 或記憶體限制與其他容器不同，請勿只比較容器的百分比。請將實際的主機或 cgroup 限制與基準測試結果一起記錄。 Docker 的 Linux 記憶體佔用情況也包含快取統計的細微差別，因此請確保兩個產品使用相同的 Docker 和 cgroup 環境。

如何測量開啟延遲

在測試前定義開啟延遲。一個合理的定義是：從使用者開啟編輯器到編輯器明顯準備好接受輸入且文件內容穩定到可以開始輸入所需的時間。對兩個產品測量相同的指標。相較於依賴產品特定的內部事件，帶有時間戳記的簡單螢幕錄製更具可比性。

收集兩種形式的開啟延遲。冷打開是指在重新啟動 Office 容器並清除測試會話後啟動。熱打開是指在不重啟服務的情況下重複打開同一個文件。 Collabora 的 prespawn 設定使得這種差異尤其重要，因為更多的等待子程序可以減少啟動延遲，但同時也會增加記憶體使用量。如果您調整了該設置num_prespawn_children，請將其值與結果一起列出，而不是隱藏它。

如何衡量協作延遲

對於即時協同編輯而言，有效的指標並非普通的 ICMP ping 請求。應測量瀏覽器 A 中的編輯操作與瀏覽器 B 中可見變化之間的延遲。使用兩個不同的瀏覽器設定檔或計算機，並同步它們的時鐘。記錄 20 到 50 次簡單的編輯操作，例如在同一段落中添加一個字符，然後計算可見傳播延遲的中位數和第 95 個百分位數。

ONLYOFFICE 的官方協同編輯描述確認，變更會從一位編輯器傳輸到文件編輯服務，然後再傳輸到另一位編輯器。請參閱ONLYOFFICE 協同編輯工作流程。其伺服器配置也公開了與 WebSocket 相關的設置，包括重連行為和最大有效負載大小，詳見ONLYOFFICE 伺服器配置參考。同樣，Collabora 也依賴透過反向代理的持久 WebSocket 流量，因此代理緩衝、逾時行為、TLS 終止和網路往返時間 (RTT) 應視為測試環境的一部分，而不是背景細節。

增加受控網路延遲

如果您的用戶是遠端用戶，請重複協作測試，並控制往返延遲，例如分別設定為約 20 毫秒、80 毫秒和 150 毫秒。對兩個系統應用相同的網路整形，並準確記錄整形引入的位置。這可以揭示本地區域網路基準測試可能隱藏的差異：編輯人員在 1-5 毫秒的往返延遲下可能感覺良好，但對於分支機構或國際團隊而言，響應速度明顯較慢。

節省延遲需要單獨的測量方法

保存延遲與輸入延遲並不相同。 ONLYOFFICE 文件中描述了一種工作流程：編輯服務編譯更改，並在編輯結束後向儲存服務發送回調；其文件指出預設的轉換開始延遲為五秒，並表示最終時間還取決於轉換時間、文件複雜性和伺服器效能。請參閱ONLYOFFICE 儲存文件文檔。這意味著「保存耗時數秒」不應自動解釋為互動延遲。

對於這兩款產品，保存完成時間應從最後一位編輯者完成操作開始，直到後端儲存確認更新後的檔案為止。請確保儲存位置和磁碟類型保持一致。否則，Nextcloud、ownCloud、物件儲存、資料庫或反向代理速度緩慢的問題可能源自於辦公室套件本身。

結果表：那些重要的數字

如何解讀結果

如果 Collabora 在您的配置中佔用更多空閒內存，但冷啟動延遲更低，那麼如果用戶頻繁打開文檔且伺服器有剩餘內存，這可能是一個可以接受的權衡。如果 ONLYOFFICE 的基線 CPU 使用率較低，但在轉換過程中 CPU 使用率峰值更高，那麼 CPU 資源餘裕可能比記憶體更重要。相反的情況也可能出現；關鍵在於將每條資源曲線與使用者可見的事件連結起來。

對於小型自託管部署，應專注於空閒記憶體佔用、首次開啟時間以及一兩個大型文件是否會導致交換空間。對於擁有數十名活躍編輯人員的企業級部署，則應優先考慮記憶體成長斜率、CPU 飽和度、p95 協同編輯延遲以及負載復原。對於地理位置分散的用戶，網路往返時間 (RTT) 和代理程式配置的影響可能超過伺服器端的微小差異。

因此，最理想的產品應該是既能滿足您的 CPU 和記憶體預算，又能滿足您實際文件延遲目標的產品。廠商提供的規格參數頁面僅供參考，並非基準測試結果。運行相同的工作負載，保持環境可控，將測試配置與測試資料一同發布，切勿僅憑一次空閒記憶體測試結果就斷言整體效能。