透過找到瓶頸來消除 ONLYOFFICE 協同編輯延遲

如果 ONLYOFFICE 在自架的 Docker 伺服器上協同編輯速度很慢，首先要確定延遲是伺服器端、網路路徑還是特定文件的問題。在進行任何變更之前，請對相同編輯工作階段進行測試：檢查容器和主機資源使用情況，然後確認反向代理能夠正確傳遞即時編輯器連線。只有當這些測試結果顯示達到容量限制時，才需要新增 CPU、記憶體或其他基礎架構。

1. 重現延遲問題並檢查伺服器，然後再進行調整。

請兩位編輯同時開啟同一份文件並進行少量修改。觀察兩位用戶的輸入是否都出現延遲，是否有用戶延遲看到更新，以及該問題是出現在所有文件上還是僅出現在某個大型或複雜的文件中。這種簡單的比較有助於區分普遍存在的服務問題和特定文件的工作負載問題。

在 Docker 主機上，找到文件伺服器容器，並在出現延遲時觀察其資源使用：

docker ps
 docker stats <container_name_or_id>

觀察是否有持續的 CPU 飽和、記憶體接近主機或容器限制、交換空間活動或容器重新啟動等情況。如果儲存或文件載入暫停，也應檢查主機磁碟空間和 I/O。短暫的峰值不如與編輯緩慢同步的瓶頸更能說明問題。 ONLYOFFICE Docker 故障排除頁面指出，記憶體使用量會隨著開啟的文件數量和同時使用者數量的增加而增加；對於擁有數十個活躍使用者的伺服器，2-4 GB 的記憶體使用量屬於正常範圍，但這並非普遍適用的記憶體容量保證。

終端風格的 Docker 統計資訊視圖，顯示文件伺服器容器的 CPU 和記憶體列。 — 重現協同編輯延遲時，需要觀察的 CPU 和記憶體欄位的終端範例視圖。

請注意，ONLYOFFICE 將同時線上活躍使用者數定義為開啟文件的使用者數，無論其是正在編輯還是正在檢視文件。請將您的峰值開啟編輯器數量與特定版本的Community Docker 系統需求進行比較。公佈的資料為參考配置，文件中指出實際容量取決於文件類型和大小。

2. 如果編輯器重新連接，請檢查代理程式和網路路徑

如果編輯器載入完畢但其他編輯者反覆斷開連接，或延遲僅出現在您的公開 URL 上，請在新增伺服器資源之前檢查反向代理程式。 WebSocket 是用於即時編輯流量的持久連線。如果代理關閉或未能升級該連接，則可能導致編輯延遲或重新連接。

在一次延遲較高的會話期間，檢查代理程式的存取日誌和錯誤日誌。確認您的設定轉送了 HTTP Upgrade 和 Connection 標頭，並保留了原始主機和協定。對於 NGINX，請將您的設定與 ONLYOFFICE 的官方代理範例進行比較；該文件特別提到了轉送的X-Forwarded-Proto標X-Forwarded-Host頭。如果您的 TLS 終止、路徑前綴或代理拓撲結構不同，請勿直接複製範例。

深色設定編輯器顯示 proxy_http_version 1.1 和 WebSocket 升級及連線標頭 — 反向代理設定範例視圖，突出顯示 HTTP 升級標頭，以便在您自己的設定中進行驗證。

此外，還要從同一區域網路內的客戶端以及常用的遠端路由進行測試。如果區域網路會話回應迅速且公共路由速度緩慢，則需要檢查代理程式、防火牆、VPN、DNS 或廣域網路延遲。如果兩條路由同時出現延遲，則伺服器端負載過高的可能性較大。瀏覽器開發者工具可以提供協助：重複的 WebSocket 斷開連線表示連線處理有問題，而連線穩定但在負載過高的主機上編輯速度緩慢則表示主機容量或工作負載有問題。

終端風格的日誌窗口，其中包含重複的 WebSocket 斷開和重新連接條目 — 示例性日誌視圖，顯示了需要檢查代理程式和網路日誌的重複 WebSocket 重新連線模式。

3. 選擇「快速」或「嚴格」模式是針對工作流程，而不是作為伺服器端的修復方案。

ONLYOFFICE 提供快速協同編輯和嚴格協同編輯兩種模式。快速協同編輯是預設模式，可即時顯示其他使用者的編輯內容；嚴格協同編輯則會保留更改，直到使用者儲存為止。協同編輯文件詳細介紹了兩種模式在顯示變更方面的差異。嚴格協同編輯適合喜歡批次審核和應用變更的團隊；而快速協同編輯則是需要即時共享可見性時的理想選擇。

切換模式並不能解決 CPU 飽和、記憶體不足或 WebSocket 路由故障等問題。應將模式視為協作偏好，僅當團隊需要決定哪種工作流程更合適時，才比較每種模式下相同文件和使用者數量的情況。切勿將模式切換視為效能提升的保證。

兩個瀏覽器文件視窗分別顯示兩位合作者正在編輯各自高亮顯示的段落。 — 兩個使用者共同編輯同一文件的範例視圖；它代表協作流程，而不是衡量測試。

4. 僅在測量確定容量壓力後才進行標定

如果文件和使用者存取出現延遲，同時 CPU 佔用率居高不下、記憶體受限或容器重啟，請先為文件伺服器提供足夠的宿主機資源，並確認 Docker 的限制不會超出宿主機的資源限制。然後重新測試。已發布的 Docker 社群版參考文件列出了 4 GB 的記憶體和儲存需求，具體需求會根據並髮用戶數量而變化；對於超過 400 個並發活躍用戶，文件建議部署集群，並推薦使用 Kubernetes。請將這些數據作為規劃參考，而非保證特定伺服器能夠支援特定工作負載。

對於小型部署，增加可用 CPU 或記憶體通常比將服務拆分到多個主機上更容易操作。對於持續的高並發應用，獨立或叢集化的服務可以提供更大的效能空間，但也會增加網路依賴性、配置、監控和故障點。 ONLYOFFICE 目前的官方 Compose 範例包含對文件伺服器端點的健康檢查；應同時檢查容器健康狀況和應用程式回應速度，而不是假設運行中的容器就意味著編輯路徑正常。在診斷過程中保持鏡像版本固定，以避免部署更新影響前後對比測量結果。

使用相同的編輯測試驗證修復效果

使用相同的文件、用戶端路由和大致相同的負載，重複先前的雙人編輯測試。確認兩位編輯者的輸入回應都正常，所選的協同編輯模式下變更顯示一致，且不再出現重新連線或容器重新啟動的情況。docker stats在重新測試期間進行觀察，並檢查代理日誌，以確定問題是否與連接相關。如果小規模測試有效，但高峰時段的會話仍然存在延遲，請在更改更多設定之前收集容器映像/版本、主機和 Docker 版本、掛載的磁碟區、資源圖以及相關日誌；官方偵錯日誌指南解釋如何在 Docker 中啟用臨時偵錯日誌。收集完證據後，請將詳細日誌等級調低，因為它會增加日誌量。

根據結果選擇權衡：連接中斷時糾正代理，測量結果顯示資源壓力持續時增加容量，以及當只有一個複雜文件受到影響時，在隔離該工作負載之前不要幹預伺服器。