ONLYOFFICEの共同編集の遅延を解消するために、ボトルネックを見つけましょう

ONLYOFFICEの共同編集が、自己ホスト型のDockerサーバー上で遅く感じられる場合は、まず遅延の原因がサーバー、ネットワークパス、または特定のドキュメントのいずれにあるのかを特定してください。何も変更する前に、同じ編集セッションを測定します。コンテナとホストのリソース使用量を確認し、リバースプロキシがライブエディターへの接続を正しく通過させていることを確認してください。これらの測定結果から容量制限が明らかになった場合にのみ、CPU、メモリ、またはその他のインフラストラクチャを追加してください。

1. ラグを再現し、調整前にサーバーをチェックしてください。

2人の編集者に同じ文書を開いてもらい、同時に小さな変更を加えてもらう。両方のユーザーの入力に遅延が発生するか、どちらかのユーザーが更新内容を確認するのが遅れるか、また、この問題がすべてのファイルで発生するのか、それとも特定の大きなファイルや複雑なファイルでのみ発生するのかを確認する。この簡単な比較によって、一般的なサービスの問題と文書固有のワークロードの問題を区別することができる。

Dockerホスト上で、ドキュメントサーバーコンテナを特定し、ラグが発生している間のリソース使用状況を監視してください。

docker ps
 docker stats <container_name_or_id>

CPU の飽和状態が持続するか、メモリがホストまたはコンテナの制限に近づいているか、スワップが発生しているか、コンテナが再起動しているかを確認してください。保存やドキュメントの読み込みが一時停止する場合は、ホストのディスク容量と I/O も確認してください。短時間のスパイクは、編集の遅延と一致するボトルネックほど決定的なものではありません。ONLYOFFICEの Docker トラブルシューティング ページには、開いているドキュメントと同時使用ユーザー数が増えるとメモリ使用量が増加すると記載されています。数十人のアクティブユーザーがいるサーバーの場合、通常は 2～4 GB ですが、これは普遍的なサイジング保証ではありません。

ONLYOFFICEでは、同時アクティブユーザーとは、編集中か閲覧中かを問わず、ドキュメントを開いているユーザーとしてカウントされることに注意してください。ピーク時のオープンエディター数を、エディション固有のCommunity Dockerシステム要件と比較してください。公開されている数値は参考構成であり、実際の容量はドキュメントの種類とサイズによって異なるとドキュメントに記載されています。

2. エディターが再接続した場合、プロキシとネットワークパスを検査する

エディタは読み込まれるものの、共同編集者が繰り返し切断される場合、または遅延が公開URL経由でのみ発生する場合は、サーバーリソースを追加する前にリバースプロキシを確認してください。WebSocketは、ライブエディタのトラフィックに使用される永続的な接続です。この接続を閉じたり、アップグレードに失敗するプロキシは、編集の遅延や再接続の原因となる可能性があります。

ラグが発生したセッション中に、プロキシのアクセスログとエラーログを確認してください。設定でHTTP UpgradeヘッダーとConnectionヘッダーが転送され、元のホストとプロトコルが保持されていることを確認してください。NGINXの場合は、ONLYOFFICEの公式プロキシ例と設定を比較してください。ドキュメントには、転送されるヘッダーが具体的に記載X-Forwarded-ProtoされていますX-Forwarded-Host。TLS終端、パスプレフィックス、またはプロキシトポロジーが異なる場合は、サンプルをそのまま貼り付けないでください。

同じLAN上のクライアントと通常のリモートルートからもテストしてください。LANセッションは応答性が高いのにパブリックルートが遅い場合は、プロキシ、ファイアウォール、VPN、DNS、またはWANの遅延を調査してください。両方のルートが同時に遅延する場合は、サーバー側の負荷が原因である可能性が高くなります。ブラウザの開発者ツールが役立ちます。WebSocketの切断が繰り返される場合は接続処理に問題があることを示唆し、飽和状態のホストで編集が遅いものの安定した接続が維持されている場合は、容量またはワークロードに問題があることを示唆します。

3. ワークフローの設定として「高速」または「厳密」を選択してください。サーバーの修正として選択しないでください。

ONLYOFFICEでは、デフォルト設定で他のユーザーの編集内容をリアルタイムで表示する「高速共同編集」と、ユーザーが変更を保存するまで変更内容が保持される「厳密共同編集」の2つのモードを提供しています。共同編集に関するドキュメントでは、変更内容の表示方法の違いについて説明しています。変更内容をまとめて確認・適用したいチームには「厳密」モードが適しており、共有された変更内容をすぐに確認する必要がある場合は「高速」モードが最適です。

モードを変更しても、CPUの飽和状態、メモリ制限、またはWebSocketルートの破損は修復されません。モードはコラボレーションの優先順位として扱い、チームがどのワークフローが最適かを判断する場合にのみ、各モードで同じファイルとユーザー数を比較してください。モードの切り替えがパフォーマンス向上を保証するものとして提示することは避けてください。

4. 測定値から容量圧力が特定された後にのみスケールを作成する

CPUが飽和状態のまま、メモリが不足している、またはコンテナが再起動している状態で、ドキュメントやユーザー間で遅延が発生する場合は、まずDocument Serverに十分なホストリソースを割り当て、Dockerの制限がホストのリソースを不足させていないことを確認してください。その後、再度テストしてください。公開されているCommunity Edition Dockerのリファレンスには、4GBのRAMと、同時ユーザー数に応じて異なるストレージ要件が記載されています。同時アクティブユーザーが400人を超える場合は、クラスタ構成を推奨し、Kubernetesの使用を推奨しています。これらの数値は計画の参考値として使用し、特定のサーバーが特定のワークロードをサポートすることを保証するものではありません。

小規模なインストールの場合、サービスをホスト間で分割するよりも、利用可能なCPUまたはメモリを増やす方が通常は操作が簡単です。持続的な高同時実行性を実現するには、サービスを分離またはクラスタ化することで余裕が生まれますが、ネットワークの依存関係、構成、監視、および障害発生箇所が増加します。ONLYOFFICEの現在の公式Composeサンプルには、ドキュメントサーバーエンドポイントのヘルスチェックが含まれています。コンテナが稼働しているからといって編集パスが正常であると想定するのではなく、コンテナの健全性とアプリケーションの応答性を合わせて確認してください。デプロイメントの更新によって前後の測定結果が混乱しないように、診断中はイメージバージョンを固定してください。

同じ編集テストで修正内容を確認してください。

同じドキュメント、クライアント ルート、およびおおよその負荷を使用して、元の 2 ユーザー編集を再度実行します。両方のエディターで入力が応答性があり、選択した共同編集モードで変更が一貫して表示され、再接続やコンテナの再起動が停止していることを確認します。docker stats再テスト中は監視し、問題が接続関連であった場合はプロキシ ログを確認します。小規模なテストは成功してもピーク時のセッションで遅延が発生する場合は、設定を変更する前に、コンテナ イメージ/バージョン、ホストと Docker のバージョン、マウントされたボリューム、リソース グラフ、および関連するログを収集します。公式のデバッグ ログ ガイドでは、Docker で一時的なデバッグ ログを有効にする方法が説明されています。ログ ボリュームが増えるため、証拠を収集した後は、詳細なログ出力を下げてください。

結果に基づいてトレードオフを選択します。接続が切断された場合はプロキシを修正し、測定結果からリソースへの負荷が持続していることが示された場合は容量を追加し、複雑なドキュメントが1つだけ影響を受けている場合は、そのワークロードを分離するまでサーバーをそのままにしておきます。