Collabora Online 與 ONLYOFFICE：測量記憶體和編輯延遲

Collabora Online 於 2026 年 6 月 8 日發布了 CODE 26.04 版本，該版本改進了文件互通性和易用性，但其發布說明並未提供與 ONLYOFFICE Docs 的受控內存或延遲比較數據。為了做出有效的決策，建議您在同一台主機上使用相同的文件、瀏覽器、儲存平台和使用者操作，並對計劃部署的版本進行基準測試。供應商提供的最低要求僅供參考，不代表實際的性能表現。

此參考流程衡量兩個不同的指標：伺服器資源使用情況以及使用者開啟和編輯文件時感知到的時間。它並不聲稱某個軟體套件在所有方面都更快。文件複雜性、整合、網頁路徑、字體和並發會話等因素都會影響結果。

已公佈的要求能告訴你什麼，不能告訴你什麼？

ONLYOFFICE 目前的 Docker 要求至少需要 4 GB 記憶體和 4 GB 交換空間，其文件指出實際需求會根據並發活躍用戶數、文件類型和大小而變化。其 Docker 故障排除指南指出，對於數十個活躍用戶，2-4 GB 的記憶體佔用量屬於正常範圍。這些是 ONLYOFFICE 特有的容量規劃說明，並非與 Collabora 的直接比較。

Collabora 表示，硬體需求取決於同時使用者數量；其常見問題也提醒，隨著同時使用者數量的增加，效能會下降，並且取決於伺服器資源。 CODE 和支援的 Collabora Online 產品是不同的部署選項。小型家庭版 CODE 測試並不能預測生產訂閱部署，正如 ONLYOFFICE 社群版的測試也不能自動代表其他版本或架構一樣。每次運行都應記錄版本、發行版、部署方法和整合方式。

截至 2026 年 10 月，CODE 26.04 是 Collabora 的最新版本。其版本說明描述了多項改進，包括文件互通性，但並未量化每個使用者的記憶體佔用或與 ONLYOFFICE 相比的編輯延遲。因此，請將此視為測試目前版本（已鎖定版本）的理由，而非速度優勢的證據。

建構一個公平、可重複的測試

使用相同的主機和整合路徑。為每個測試套件分配相同的 CPU 和記憶體限制、儲存位置、反向代理、TLS 設定和網路路由。如果同時運行兩個容器，它們會爭用相同的資源；正確的做法是，停止其中一個測試套件，對其進行測試，然後用另一個替換它。保持主機處於空閒狀態。
固定軟體版本。記錄確切的鏡像標籤或發布版本、版本號、Docker 版本、主機作業系統、瀏覽器版本以及連接的平台。避免使用浮動標籤（例如latest在對比測試期間），因為軟體在不同測試之間可能會發生變化。
準備代表性文件。包括一份簡短的文字檔案、一個包含公式和圖表的電子表格，以及使用者經常打開的最大或最複雜的文件。使用測試副本，而非正式生產用原件。將它們儲存在與日常工作相同的文件平台中。
保持客戶端環境穩定。使用相同的電腦、瀏覽器、網路連線、螢幕尺寸和瀏覽器擴充功能。關閉無關的標籤頁。每次試驗前，確保文件完全關閉後再進行冷啟動測量；然後分別進行熱啟動試驗。
測試前先確定計時參數。測量從開啟文件到文件完全渲染並可編輯所需的時間。對於編輯延遲，可以對特定操作進行計時，例如輸入短語並等待其顯示給另一位協作者。記錄每次運行的結果，而不是僅依賴單次測試的結果。

衡量伺服器使用情況和用戶可見延遲

記憶體和CPU

服務穩定後，捕獲一個空閒基線。然後，在開啟一個檔案、編輯該檔案並保持其開啟的情況下，記錄容器的記憶體和 CPU 使用情況。重複此操作，使用多個並發文件和用戶，並達到與預期工作負載相符的等級。對於 Docker，docker stats --no-stream它會顯示時間點的資源快照；在每個階段重複使用此快照，或使用您現有的監控系統收集時間序列資料。同時記錄主機層級的可用內存，因為僅憑容器報告的使用情況無法判斷整台機器是否處於高負載狀態。

報告峰值記憶體、活動階段的平均記憶體以及文件關閉後的空閒記憶體。保持相同的採樣間隔。不要將單一文件後的記憶體消耗等同於團隊的記憶體容量：會話數、檔案大小、渲染複雜度和並發編輯等因素都會影響記憶體使用量。如果部署支援 Prometheus 指標，請持續收集這些指標；Collabora 提供了與 Prometheus 相容的指標和即時會話監控文件。對於 ONLYOFFICE，請使用其提供的容器診斷和資源指南。避免將一個產品的內部流程指標與另一個產品的整個容器的整體指標進行比較。

開啟和編輯延遲

對每個代表性文件至少運行五次冷打開和五次熱打開。報告中位數和最慢的運行時間，而不僅僅是最佳結果。冷打開包括載入文件和渲染其初始視圖等操作；熱開啟可能受益於快取。在兩個編輯器中使用相同的“就緒”定義。

為了評估協作延遲，連接兩個瀏覽器會話，測量從一個會話中的特定編輯操作到另一個會話中可見更新所需的時間。重複此操作數次，每次都確保沒有打開其他文檔，並在預期的並發負載下進行。這樣可以捕捉編輯器、伺服器、儲存整合和網路等因素的綜合影響。如果瀏覽器和伺服器位於不同的網路上，請記錄往返延遲；網路延遲可能會嚴重影響編輯器本身的處理速度。

客觀解讀結果，不要誇大其詞。

觀察到的模式	可能的解釋	下一步檢查
空閒時記憶體佔用過高	啟動服務或快取會話可能構成基準；產品清理空閒文件的方式可能不同。	在固定的空閒時間間隔後進行測量，並比較主機記憶體和容器記憶體。
負載下快速打開，緩慢編輯	編輯或協作工作可能會受到 CPU、儲存回呼或網路的限制。	以較低的並發性重複上述步驟，並同時檢查 CPU、磁碟和網路。
只有一個文件運行緩慢。	文件結構、公式、嵌入物件或字體可能是限制因素。	測試另一個類似大小的文件，然後檢查問題文件的特定特徵。
冷場開場有所不同，暖場開場則不然。	初始化或快取行為或許可以解釋大部分差距。	冷熱測試結果要分開測定，不要將它們取平均值。

選擇滿足延遲目標且在實際並發情況下留有足夠的記憶體和 CPU 餘裕的套件。如果結果接近，請優先考慮文件相容性、整合支援、操作便利性和授權協議。在進行重大升級或基礎架構變更後，請重新執行相同的測試。有關權威的版本特定詳細信息，請參閱 Collabora 的CODE 26.04 發行說明、Collabora Online 常見問題解答以及安全和監控概述，以及 ONLYOFFICE社區版 Docker 要求和Docker 故障排除及資源指南。這些資源分別描述了每個產品；它們並非受控的直接對比基準測試。