Collabora OnlineとONLYOFFICEの比較:RAMと編集遅延の測定

Collabora OnlineのCODE 26.04リリース(2026年6月8日発表)には、ドキュメントの相互運用性とユーザビリティの改善が含まれていますが、リリースノートにはONLYOFFICE DocsとのRAM容量やレイテンシの比較データは掲載されていません。適切な判断を下すには、展開予定のビルドを同じホスト、同じドキュメント、ブラウザ、ストレージプラットフォーム、ユーザー操作でベンチマークテストを実施してください。ベンダーの最小要件は計画の指針であり、比較可能なパフォーマンス結果ではありません。

この参照手順では、サーバーリソースの使用量と、ユーザーが文書を開いて編集する際に感じる時間の2つの異なる要素を測定します。特定のソフトウェアスイートが常に最も高速であると主張するものではありません。ファイルの複雑さ、統合性、ネットワークパス、フォント、同時セッション数などによって結果が変わる可能性があります。

公開されている要件からわかることとわからないこと

ONLYOFFICEの現在のDocker要件では、最低4GBのRAMと4GBのスワップ領域が必要とされています。また、ドキュメントによると、実際の要件は同時アクティブユーザー数、ドキュメントの種類とサイズによって変動するとのことです。Dockerのトラブルシューティングガイドでは、数十人のアクティブユーザーの場合、2~4GBの使用量が正常であるとされています。これらはONLYOFFICE固有のサイジングに関する注記であり、Collaboraとの直接的な比較ではありません。

Collaboraによると、ハードウェア要件は同時ユーザー数によって異なり、FAQでは同時使用が増えるにつれてパフォーマンスが低下し、サーバーリソースに依存すると警告しています。CODEとサポートされているCollabora Online製品は、それぞれ異なる導入オプションです。小規模な家庭でのCODEテストは、本番環境のサブスクリプション導入を予測するものではなく、ONLYOFFICE Community Editionのテストが他のエディションやアーキテクチャを自動的に代表するものではないのと同様です。各実行について、エディション、リリース、導入方法、および統合を記録してください。

2026年10月現在、CODE 26.04はCollaboraの最新リリースです。リリースノートには、ドキュメントの相互運用性などの改善点が記載されていますが、ユーザーあたりのRAM使用量やONLYOFFICEとの編集遅延に関する具体的な数値は示されていません。そのため、最新の固定ビルドをテストする理由として捉えるべきであり、速度面での優位性を示す証拠として捉えるべきではありません。

公平で再現性のあるテストを作成する

  1. 同じホストと統合パスを使用してください。各スイートに同じCPUとメモリの制限、ストレージの場所、リバースプロキシ、TLS設定、ネットワークルートを設定してください。両方のコンテナを同時に実行すると、同じリソースを競合するため、一方のスイートを停止して動作を測定し、その後もう一方のスイートに置き換えてください。それ以外の場合は、ホストをアイドル状態に保ってください。
  2. ソフトウェアのバージョンを固定してください。イメージのタグまたはリリース、エディション、Dockerバージョン、ホストOS、ブラウザバージョン、および接続プラットフォームを正確に記録してください。latest比較中など、テスト間でソフトウェアが変更される可能性があるため、タグが変動する状態は避けてください。
  3. 代表的なファイルを用意してください。短いテキスト文書、数式とグラフを含むスプレッドシート、そしてユーザーがよく開く最大または最も複雑なファイルを含めてください。本番環境用のオリジナルではなく、テスト用の複製を使用してください。これらのファイルは、通常の業務で使用しているのと同じドキュメントプラットフォームに保存してください。
  4. クライアント側の環境を一定に保ってください。同じコンピューター、ブラウザ、ネットワーク接続、画面サイズ、ブラウザ拡張機能を使用してください。無関係なタブは閉じてください。各試行において、コールドオープン測定を開始する前にドキュメントが完全に閉じられていることを確認し、その後、ウォームオープン試行を別途実行してください。
  5. テスト前にタイミングを定義してください。ドキュメントを開いてから、完全にレンダリングされて編集可能になるまでの時間を測定します。編集の遅延時間については、短いフレーズを入力して、2人目の共同作業者にそのフレーズが表示されるまで待つなど、特定のアクションにかかる時間を計測します。単一の印象に頼るのではなく、各実行結果を記録してください。

サーバーの使用状況とユーザーが認識できる遅延を測定します。

メモリとCPU

サービスが安定した後、アイドル状態のベースラインを取得します。次に、1つのファイルを開いて編集し、開いたままにしている間のコンテナのメモリとCPUを記録します。想定されるワークロードに合わせて、複数の同時実行ドキュメントとユーザーでこれを繰り返します。Dockerの場合、docker stats --no-stream特定の時点のリソースのスナップショットが表示されます。各フェーズでこれを繰り返し使用するか、既存の監視システムで時系列データを収集してください。コンテナの報告された使用量だけではマシン全体に負荷がかかっているかどうかはわからないため、ホストレベルの利用可能なメモリも記録してください。

ピーク時のメモリ使用量、アクティブフェーズ中の平均メモリ使用量、およびドキュメントが閉じられた後のアイドル状態のメモリ使用量を報告してください。サンプリング間隔は一定に保ってください。1つのドキュメント後のメモリ使用量をチームのキャパシティと同一視しないでください。セッション、ファイルサイズ、レンダリングの複雑さ、同時編集など、すべてが重要です。デプロイメントがPrometheusメトリクスをサポートしている場合は、それらを一貫して収集してください。Collaboraは、Prometheus互換メトリクスとライブセッション監視についてドキュメント化しています。ONLYOFFICEについては、ドキュメント化されたコンテナ診断とリソースガイダンスを使用してください。ある製品の内部プロセスメトリクスを、別の製品のコンテナ全体の合計と比較することは避けてください。

レイテンシを開いて編集する

各代表ファイルについて、少なくとも5回のコールドオープンと5回のウォームオープンを実行してください。最良の結果だけでなく、観測された中央値と最遅時間も報告してください。コールドオープンには、ドキュメントの読み込みや初期表示などの処理が含まれます。ウォームオープンでは、キャッシュの効果が期待できます。両方のエディタで「準備完了」の定義を同じにしてください。

コラボレーションの遅延を測定するには、2つのブラウザセッションを接続し、一方のセッションでの特定の編集からもう一方のセッションでの表示更新までの時間を計測します。他のドキュメントを開かない状態と、想定される同時負荷の両方で、同じ操作を複数回繰り返します。これにより、エディタ、サーバー、ストレージ統合、およびネットワークの複合的な影響を把握できます。ブラウザとサーバーが異なるネットワーク上にある場合は、往復時間も記録してください。ネットワーク遅延は、エディタ自身の処理に大きな影響を与える可能性があります。

結果を誇張せずに読んでください

観察されたパターン考えられる解釈次のチェック
アイドル時の高RAM起動時のサービスやキャッシュされたセッションがベースラインとなる場合があり、製品によってはアイドル状態のドキュメントを異なる方法でクリーンアップする場合があります。一定のアイドル時間経過後に測定を行い、ホストメモリとコンテナメモリを比較します。
起動は速いが、負荷がかかると編集が遅くなる編集作業や共同作業は、CPU、ストレージコールバック、またはネットワークによって制約を受ける可能性があります。より低い同時実行数で同じ手順を繰り返し、CPU、ディスク、ネットワークを同時に検査してください。
1つのファイルだけが遅いファイル構造、数式、埋め込みオブジェクト、またはフォントが制限要因となる可能性があります。同じくらいのサイズの別のファイルでテストを行い、問題のあるファイルの具体的な特徴を調べてください。
コールドオープンは異なるが、ウォームオープンはそうではない初期化処理やキャッシュの動作が、この差の大部分を説明できる可能性がある。冷蔵と温蔵の結果は分けて保管し、平均化しないでください。

現実的な同時実行数で十分なメモリとCPUの余裕を残しつつ、レイテンシの目標を満たすスイートを選択してください。結果が近い場合は、ドキュメントの互換性、統合サポート、操作の習熟度、ライセンスを優先してください。メジャーアップグレードまたはインフラストラクチャの変更後に、同じテストを再実行してください。バージョン固有の詳細については、CollaboraのCODE 26.04リリースノート、CollaboraオンラインFAQ、セキュリティと監視の概要、およびONLYOFFICEのCommunity Edition Docker要件とDockerのトラブルシューティングとリソースガイダンスを参照してください。これらの資料は各製品を個別に説明しており、管理された直接比較ベンチマークではありません。

コメントを残す

Collabora OnlineとONLYOFFICEの比較:RAMと編集遅延の測定

Collabora OnlineとONLYOFFICEの比較:RAMと編集遅延の測定

Collabora OnlineとONLYOFFICE Docsを同一サーバー上で、メモリ使用量、ドキュメントのオープン時間、共同編集の遅延について、再現可能なテストを用いて比較します。

ONLYOFFICE DocsとMicrosoft 365 Web:どちらが書式設定を保持できるのか?

ONLYOFFICE DocsとMicrosoft 365 Web:どちらが書式設定を保持できるのか?

ONLYOFFICE DocsとMicrosoft 365のWebアプリにおける文書、スプレッドシート、レイアウトの動作を比較し、簡単なテストでファイルに適した安全なエディターを選択してください。

ONLYOFFICEとExcelでスプレッドシートの数式が変わる理由

ONLYOFFICEとExcelでスプレッドシートの数式が変わる理由

数式の不一致の原因を構文、地域区切り文字、再計算、日付システム、またはサポートされていない関数に絞り込み、ワークブックを共有する前に検証してください。

ONLYOFFICEとLibreOfficeの比較:パフォーマンステストの結果

ONLYOFFICEとLibreOfficeの比較:パフォーマンステストの結果

最新リリースのデータから何が証明でき、何が証明できないかを確認し、同じファイルとコンピューター上で両方のオフィススイートを比較してください。

Calc VLOOKUP vs XLOOKUP: 適切な検索式を選択する

Calc VLOOKUP vs XLOOKUP: 適切な検索式を選択する

完全一致、左辺参照、欠損値処理、バージョンサポートなどを比較して、信頼性の高いCalcの数式を選択してください。

WriterとWordのページ番号の違い:スタイル、セクション、および再開

WriterとWordのページ番号の違い:スタイル、セクション、および再開

WriterのページスタイルとWordのセクションリンクが、ドキュメントを移動したときに表紙、ローマ数字、および番号の再開にどのように影響するかを学びましょう。

Pardus Software CenterかAPTか?適切なツールを選ぶ

Pardus Software CenterかAPTか?適切なツールを選ぶ

Pardus Software CenterとAPTコマンドを比較して、タスクに適した方法でパッケージの検索、インストール、削除、更新を行ってください。

Pardus 25.2 XFCE vs GNOME:公平なRAM比較

Pardus 25.2 XFCE vs GNOME:公平なRAM比較

Pardusが公表しているRAM要件が何を意味するのかを確認し、同じPC上で再現性のあるMemAvailable値を用いてXFCEとGNOMEを比較してください。

HamoniKR OSは企業向けデスクトップのニーズを満たすことができるか?

HamoniKR OSは企業向けデスクトップのニーズを満たすことができるか?

HamoniKR 8.0がビジネス向けデスクトッププランの中でどのような位置づけになるのか、韓国語に特化した機能がどのようなサポートを提供しているのか、そして本格的な展開前に確認すべき事項について見ていきましょう。

Gooroomセキュリティ:トラステッドブートとアイソレーションの実際の機能

Gooroomセキュリティ:トラステッドブートとアイソレーションの実際の機能

Gooroomの起動検証と実行時保護がどのように連携しているのか、「サンドボックス」とは何を意味するのか、そしてデバイス上でどの設定を確認すべきかを理解しましょう。