Collabora Online vs ONLYOFFICE：リソース使用量とレイテンシのテスト

Collabora OnlineとONLYOFFICE Docsのどちらを選ぶかは、機能やファイル形式の問題として捉えられがちですが、インフラチームは導入後に2つ目の課題に直面することがよくあります。それは、各スタックがどれだけのCPUとメモリを消費するか、そしてラウンドトリップ時間と同時実行数が増加しても編集の応答性はどの程度維持されるか、という点です。ドキュメントの複雑さ、フォント、変換処理、ストレージの遅延、ブラウザの動作、リバースプロキシ、同時に開いているドキュメントの数など、様々な要因によって結果が変わるため、どちらの製品にも信頼できる普遍的な数値はありません。

2026年10月現在、どちらのベンダーも、他社製品と完全に同等の性能を比較できるベンチマークを公開していません。これは重要な点です。公平な比較を行うには、2種類の証拠を区別する必要があります。1つは、各プロジェクトで必要なリソース構成を示すベンダーのサイジングガイダンス、もう1つは、同一のハードウェア上で実行できる再現可能なレイテンシ/リソーステストです。以下のテストプランは、ラボの結果があらゆる状況に当てはまると誤解することなく、自社の導入環境で活用できる数値を算出することを目的としています。

公式リソースガイダンスには実際に何が書かれているのか

ベンダーは有用なサイジング情報を公開していますが、数値は直接的に同等ではありません。Collabora の SDK マニュアルには、4 CPU と 6 GiB のメモリを推奨する Kubernetes/Helm の運用例が含まれており、制限値は 8 CPU と 8 GiB です。同じマニュアルにはnum_prespawn_children、子プロセスを準備状態にして新しいセッションを高速に開始できるようにする機能についても説明されていますが、これは追加のメモリを消費します。詳しくはCollabora Online SDK マニュアルを参照してください。Collabora の現在の構成テンプレートでは、メモリ比率の制限とドキュメントごとの同時実行制御も公開されています。プロジェクトの公式ソースはCollabora Online 構成テンプレートで入手できます。

ONLYOFFICEは、Docker版Docs Community Editionのより明確なリファレンスティアを公開しました。現在のガイドラインでは、4GB以上のRAMを推奨しており、同時アクティブユーザー数が100人未満の場合は2.8GHzコア1つ、100～200人の場合は2コア、200～400人の場合は4コアというリファレンス構成をリストアップしています。いずれの構成でもRAMは4GBとなっています。ベンダーは、実際の処理能力はドキュメントの数、種類、サイズによって異なると明示的に警告しています。ONLYOFFICE Docs Community EditionのDocker要件を参照してください。

アイドル状態のメモリのスクリーンショットがベンチマークにならない理由

よくある比較方法としては、両方のコンテナを起動し、ドキュメントを一切開かずに、RAM使用量が少ない方を勝者とするというものがありますが、これはあくまで基本的なフットプリントを測定するものであり、重要な処理、つまりファイルのオープン、必要に応じた変換、ページやシートのレンダリング、変更の転送、スプレッドシートの再計算、複数のエディタへの対応、そして結果のストレージへの保存といった処理は考慮されていません。

Collabora のプロセス モデルでは、子プロセスを事前に準備しておくことができます。これにより、アイドル状態のフットプリントが増加し、ドキュメントが使用可能になるまでの遅延が短縮されます。ONLYOFFICE は、ドキュメント編集と変換などのサービスを分離しています。そのアーキテクチャ ドキュメントでは、ドキュメント エディター、編集サービス、コマンド サービス、変換サービス、およびビルダー サービスについて説明しています。ONLYOFFICE Docs の仕組みを参照してください。つまり、ベースライン RSS は有用な運用指標ですが、ユーザーが認識できる速度を予測するには十分ではありません。

適切なリソースとレイテンシーのテスト設定

2つの製品は、同一ホスト上または同一の構成の仮想マシン上で、それぞれ1つずつ実行してください。キャッシュされたファイルを含むウォームアップ済みのホストで一方をテストし、もう一方を起動直後にテストすることは避けてください。Linuxディストリビューション、Dockerバージョン、CPUクォータ、メモリ制限、ストレージクラス、リバースプロキシ、TLS終端、ブラウザバージョン、およびドキュメントの保存パスはすべて同一にしてください。

3つのドキュメントワークロードを使用する

• テキスト文書：見出し、表、画像、変更履歴、コメントを含む代表的なDOCXファイル。
• スプレッドシート：数式、条件付き書式、複数のワークシート、および意味のある再計算を実行するのに十分なデータを含むXLSXファイル。
• プレゼンテーション：ほぼ空のスライドではなく、画像、グラフ、複数のスライドを含むPPTXファイル。

両方のプラットフォームで同じファイルを使用してください。ファイルによっては、一方の製品でフォーマット変換が必要な場合があります。変換処理によってファイルを開く時間が長くなる可能性があるため、その旨を記録してください。特定の編集ソフト向けにファイルを最適化しておきながら、その結果を一般的なプラットフォーム比較として扱うのは避けてください。

複数の同時実行レベルでテストする

実用的な手順としては、同時に開くエディタの数を1、5、10、20と増やしていき、その後、実際のピーク値に見合ったより高いレベルへと進めていきます。「ユーザー」とは、どの実行時でも同じ意味、つまりドキュメントが完全に開いた状態のエディタタブを指します。ウォームアップ実行後、各レベルを少なくとも3回繰り返し、中央値と最も遅い結果を報告してください。これにより、短いバックグラウンドスパイクが結論を歪める可能性が低くなります。

記録するリソースメトリクス

Dockerは、ベンダーに依存しないテレメトリの第1層を提供します。公式のDocker統計ドキュメントによると、docker statsCPU使用率、メモリ使用量、ネットワークI/O、ブロックI/O、およびPIDがレポートされます。ワークロード実行中のライブストリームと、定義されたチェックポイントでのストリームなしのサンプルを両方キャプチャします。

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

各同時実行レベルについて、何も開く前のアイドル状態のメモリ、すべてのドキュメントを開いた後の定常状態のメモリ、開いている間のCPUピーク値、セッションが安定した後のCPU値、およびすべてのセッションを閉じた後のメモリ値を記録してください。また、クールダウン期間後にメモリがベースライン付近に戻るかどうかも確認してください。テスト後の値が高いからといって必ずしもメモリリークが発生しているとは限りません（キャッシュや共有メモリは引き続き有効な場合があります）が、同じサイクルを繰り返してもメモリの下限値が継続的に上昇する場合は、調査が必要です。

コンテナのCPUまたはメモリ制限が異なる場合は、コンテナの割合だけを比較しないでください。ベンチマーク結果とともに、実際のホストまたはcgroupの制限を記録してください。DockerのLinuxメモリの数値にはキャッシュアカウンティングのニュアンスもあるため、両方の製品で同じDockerおよびcgroup環境を使用してください。

オープンレイテンシーの測定方法

テスト前に、オープンレイテンシを定義してください。妥当な定義としては、ユーザーがエディタを開いてから、エディタが入力可能な状態になり、ドキュメントの内容が安定して入力を開始できるまでの時間です。両方の製品で同じ指標を測定してください。製品固有の内部イベントに頼るよりも、タイムスタンプ付きのシンプルな画面録画の方が比較しやすいでしょう。

2 種類のオープンレイテンシを収集します。コールドオープンは、オフィス コンテナを再起動してテスト セッションをクリアした後に開始します。ウォームオープンは、サービスを再起動せずに同じファイルを繰り返します。Collabora の prespawn 設定では、待機中の子プロセスが増えると起動遅延が短縮される一方でメモリ使用量が増加するため、この区別が特に重要になります。 を調整する場合はnum_prespawn_children、その値を非表示にするのではなく、結果の横に表示してください。

コラボレーションの遅延を測定する方法

リアルタイムの共同編集において、意味のある指標は通常のICMPピングではありません。ブラウザAでの編集からブラウザBでの変更が反映されるまでの遅延を測定します。2つの異なるブラウザプロファイルまたはマシンを使用し、クロックを同期させます。同じ段落に文字を追加するなど、20～50回の簡単な編集を記録し、中央値と95パーセンタイル値の可視伝播遅延を計算します。

ONLYOFFICEの公式共同編集の説明では、変更内容はエディターからドキュメント編集サービス、そしてもう一方のエディターへと伝達されることが明記されています。詳しくは、ONLYOFFICEの共同編集ワークフローをご覧ください。また、 ONLYOFFICEサーバー構成リファレンスでは、再接続動作や最大ペイロードサイズなど、WebSocket関連の設定も公開されています。Collaboraも同様にリバースプロキシを介したWebSocketトラフィックに依存しているため、プロキシバッファリング、タイムアウト動作、TLS終端、ネットワークRTTは、背景の詳細​​ではなく、テスト環境の一部として扱う必要があります。

制御されたネットワーク遅延を追加する

ユーザーがリモート環境にいる場合は、約20ms、80ms、150msといった制御された往復遅延時間でコラボレーションテストを繰り返してください。両方のシステムに同じネットワークシェーピングを適用し、それがどこで導入されたかを正確に記録してください。これにより、ローカルLANベンチマークでは見落とされがちな違いが明らかになります。例えば、編集者は1～5msのRTTで快適に感じるかもしれませんが、支店や海外チームでは明らかに遅延を感じるでしょう。

セーブレイテンシには独自の測定が必要です

保存処理は、入力遅延とは異なります。ONLYOFFICEでは、編集サービスが変更内容をコンパイルし、編集終了後にストレージサービスにコールバックを送信するワークフローが説明されています。また、変換開始時のデフォルトの遅延時間は5秒であり、最終的な所要時間は変換時間、ファイルの複雑さ、サーバーのパフォーマンスによっても異なると記載されています。詳しくは、ONLYOFFICEのファイル保存に関するドキュメントをご覧ください。つまり、「保存に数秒かかった」という報告は、必ずしも対話的な遅延と解釈すべきではありません。

どちらの製品でも、保存完了までの時間は、最後のエディターが作業を終了してから、更新されたファイルがバックエンドストレージで確認されるまでの時間で計測してください。ストレージは同じネットワークパスとディスククラスを使用してください。Nextcloud、ownCloud、オブジェクトストア、データベース、またはリバースプロキシの動作が遅い場合、原因はオフィススイートにある可能性があります。

結果シート：重要な数字

結果の解釈方法

Collaboraがシステム構成においてアイドル時のメモリ使用量が多いものの、コールドオープン時のレイテンシが低い場合、ユーザーが頻繁にドキュメントを開き、サーバーに十分なRAM容量があれば、それは許容できるトレードオフと言えるでしょう。ONLYOFFICEのベースラインが低いものの、変換中にCPU使用率が急上昇する場合は、メモリよりもCPUの余裕の方が重要になるかもしれません。その逆のパターンも考えられます。重要なのは、それぞれのリソース曲線をユーザーから見えるイベントに結びつけることです。

小規模なセルフホスト型インストールの場合、アイドル時のメモリ使用量、初回起動時間、および1つまたは2つの大きなドキュメントがスワッピングを引き起こすかどうかに注目してください。数十人のアクティブなエディターがいるビジネス展開の場合は、メモリ増加率、CPU飽和度、p95共同編集遅延、および負荷後の回復を優先的に考慮してください。地理的に分散したユーザーの場合、ネットワークRTTとプロキシ構成は、サーバー側のわずかな違いよりも重要になる場合があります。

したがって、最も有用な製品は、CPUとRAMの予算内で、実際のドキュメントにおけるレイテンシ目標を満たす製品です。ベンダーのサイジングページはあくまで出発点であり、ベンチマーク結果ではありません。同じワークロードを実行し、環境を一定に保ち、数値の横にテスト構成を公開し、単一のアイドルメモリの読み取り値を全体的なパフォーマンスに関する主張に一般化することは避けてください。