Confluence 8.5 長期サポート リリースのパフォーマンス レポート
ユーザーが自分でテストを行わずに Confluence Data Center のパフォーマンスを測定できるように、アトラシアンがベンチマークをご提供します。
Jira と Jira Service Management の各パフォーマンス レポートと同様に、Confluence Data Center パフォーマンス レポートはバージョン間の一般的なパフォーマンス ベンチマークを提供します。このレポートには、とりわけ次の項目が含まれます。
インデックス再作成、バックアップと復元などの影響の大きいタスク
さまざまなインフラストラクチャ構成での拡張テスト (垂直と水平)
このレポートは、Confluence Data Center 7.19 長期サポートリリースと Confluence Data Center 8.5 長期サポートリリースを比較しています。
長期サポート リリースについて
Confluence Data Center の定期的なアップグレードをお勧めします。組織の手続き上、年に 1 回程度しかアップグレードできない場合は、長期サポートリリースへのアップグレードが最適なオプションです。これによって、セキュリティ、安定性、データ整合性、パフォーマンスに関するクリティカルな問題に継続的にアクセスできます。
On this page
ハイライト
アトラシアンは、他のすべての長期サポートリリース (LTS) と同様に、これまでと同等か、それ以上のパフォーマンスを実現することを目標にしています。Confluence Data Center 8.5 LTS テストでは、いくつかの改善点を除いて、製品全体でほぼ安定した性能が示されています。
Confluence Data Center の水平方向と垂直方向の拡張動作にポジティブな進歩が見られました。サイトのインデックス再作成が 36 % 速くなり、管理者にとってテスト対象のデータセットで 2 時間以上の節約となります。Confluence ユーザーが 8.5 にアップグレードすれば、ダッシュボードと検索の読み込み時間の短縮という利点を享受できます。アトラシアンが実施したテストにおけるハイライトは次のとおりです。
サイトのインデックス再作成の速度が 36% 上昇
2 ノードによる水平方向の拡張によってサポートされるユーザーが 13% 増加
垂直方向の拡張によってサポートされるユーザーが 4～13% 増加
ダッシュボードの表示速度が 10% 上昇
検索速度が 8% 上昇
コメント速度が 7% 上昇
小さな添付ファイル付きのページの表示速度が 7% 上昇
こうした改善のほとんどは、プラットフォームとライブラリのアップグレードへの投資と、7.19 以降のキャッシュ効率によるものです。
ブログ投稿の表示速度は、パフォーマンスの低下 (13% の速度低下) が見られた数少ないエリアの 1 つでした。現在、この原因を調査しています。アトラシアンでは、チームがワークスペース内を簡単に移動でき、できるだけ多くのお客様が自信を持って拡張できるよう、パフォーマンスと拡張性のさらなる改善に向けて、今後も取り組んでいく予定です。
パフォーマンス
このセクションでは、Confluence Data Center 7.19 と Confluence Data Center 8.5 を比較します。どちらのバージョンでも、個々のアクションの応答時間を使用して、同様の広範なテスト シナリオを実行し、アクションを次のカテゴリに分類しました。
- 小規模なアクション
- 中程度の操作
- 重い操作 (実行に時間がかかる)
パフォーマンスは、5,000 ユーザーのインスタンスでピーク トラフィックと推定されるユーザー負荷下で計測されました。アクションやテスト方法に関する詳細は「テスト手法」をご参照ください。
小規模なアクション
グラフは、小規模なアクションの応答時間 (ミリ秒単位) の違いを示しています。グラフの作成に使用されたデータは、次の拡張可能なコンテンツで確認できます。
次のテーブルは、小規模なアクションの応答時間 (ミリ秒単位) を示しています。
操作 | 7.19 LTS | 8.5 LTS | 変更 |
|---|---|---|---|
ページを作成 (単一ユーザー) | 631 | 615 | 3% 速度上昇 |
ページを公開する | 485 | 483 | 変更なし |
ページを公開 (小さな添付ファイル付き) | 683 | 673 | 1% 速度低下 |
ページを公開 (大きな添付ファイル付き) | 676 | 686 | 1% 速度低下 |
ページを表示 | 569 | 565 | 1% 速度上昇 |
ページを表示 (小さな添付ファイル付き) | 669 |
| 7% 速度上昇 |
ページを表示 (大きな添付ファイル付き) | 663 | 663 | 変更なし |
公開後にページを表示 | 527 | 535 | 2% 速度低下 |
公開後にページを表示 (小さな添付ファイル付き) | 590 | 605 | 3% 速度低下 |
公開後にページを表示 (大きな添付ファイル付き) | 608 |
| 5% 速度低下 |
検索 | 682 |
| 8% 速度上昇 |
ログイン | 534 | 529 | 1% 速度上昇 |
ログアウト | 575 | 592 | 3% 速度上昇 |
中程度の操作
グラフは、中規模なアクションの応答時間 (ミリ秒単位) の違いを示しています。グラフの作成に使用されたデータは、次の拡張可能なコンテンツで確認できます。
次のテーブルは、中規模なアクションの応答時間 (ミリ秒単位) を示しています。
操作 | 7.19 LTS | 8.5 LTS | 変更 |
|---|---|---|---|
ページを作成 (コラボレーション) | 1,551 | 1,565 | 1% 速度低下 |
ブログ投稿を作成 | 1,190 | 1,209 | 2% 速度低下 |
ブログ投稿を表示 | 1,019 |
| 13% 速度低下 |
Edit page | 1,298 | 1,315 | 1% 速度低下 |
ページを編集 (共有リンクから) | 1,719 |
| 5% 速度低下 |
ページを編集 (添付ファイル付き) | 1,313 | 1,344 | 2% 速度低下 |
ダッシュボードの表示 | 1,178 |
| 10% 速度上昇 |
ページへのいいね! | 1,027 | 1,020 | 1% 速度上昇 |
添付ファイルをアップロード | 3,452 | 3,599 | 4% 速度低下 |
添付ファイルを表示 | 2,120 | 2,099 | 1% 速度上昇 |
コメント | 1,671 |
| 7% 速度上昇 |
重い操作
グラフは、大規模なアクションの応答時間 (時間単位) の違いを示しています。グラフの作成に使用されたデータは、次の拡張可能なコンテンツで確認できます。
次のテーブルは、1 つの大規模なアクションに要する時間 (時間単位) を示しています。
操作 | 7.19 LTS | 8.5 LTS | 変更 |
|---|---|---|---|
サイトのインデックス再作成 | 6 時間 38 分 |
| 36% 速度上昇 |
バックアップと復元に関する注意事項
7.19 LTS からアップグレードする場合の、パフォーマンスと拡張性に関するもう 1 つのメリットは、Confluence のバックアップと復元システムが大幅に改善されたという点です。以前は信頼性が低く、失敗しやすかったものの、Confluence 8.3 でリリースされたアップデートによって、次の改善が行われました。
サイト全体のバックアップの速度が、中規模のインスタンスで 10 倍上昇、非常に大規模なインスタンスで最大 48 倍上昇
スペースのバックアップの速度が 8 倍上昇
サイトの復元は、追加のメモリを必要とせずにスケーリングしながら、はるかに高速になり、信頼性が向上
技術的な障壁のため、7.19 LTS ではバックアップと復元のテストを実行できませんでした。そのため、7.19 LTS からアップグレードする場合にこれらの改善が適切であることを考慮して、代わりに 8.3 リリースからの情報を含めました。
次のテーブルは、バックアップと復元に要する時間を示しています。
操作 | 8.3 以前 | 8.3 | 変更 |
|---|---|---|---|
サイト全体のバックアップ | 96 時間 |
| 速度が 48 倍上昇 |
スペースのバックアップ | 1 時間 3 分 |
| 速度が 8 倍上昇 |
サイトの復元 | 完了できませんでした |
| 大幅に改善されました |
キャパシティ テスト
このセクションでは、さまざまなインフラストラクチャ構成をテストしました。ご利用のインフラストラクチャに最も近いものと比較できます。アクションを次のカテゴリに分類しました。
水平拡張 (ノードの追加)
垂直拡張 (キャパシティの追加)
これらのテストの目的は、Confluence のバージョン間でのベンチマーク測定です。そのため、これらのテスト構成は拡張オプションの比較には適していません。これらのテストは、Confluence のバージョン間の比較のみを示しています。
水平拡張
次のインスタンス タイプでテストしました。
m5.2xlarge インスタンス (1 ノード)
m5.2xlarge インスタンス (2 ノード)
m5.2xlarge インスタンス (4 ノード)
次のテーブルは、水平拡張時の最大ユーザー数を示しています。
操作 | 7.19 LTS | 8.5 LTS | 変更 |
|---|---|---|---|
1 ノード | 852 |
| 最大ユーザー数が 11 %増加 |
2 ノード | 1,608 |
| 最大ユーザー数が 13 %増加 |
4 ノード | 2,494 | 2,560 | 最大ユーザー数が 3 %増加 |
垂直拡張
次のインスタンス タイプでテストしました。
m5.xlarge インスタンス (4vCPU と 16GiB)
m5.2xlarge インスタンス (8vCPU と 32GiB)
m5.4xlarge インスタンス (16vCPU と 64GiB)
次のテーブルは、垂直拡張時の最大ユーザー数を示しています。
操作 | 7.19 LTS | 8.5 LTS | 変更 |
|---|---|---|---|
4vCPU & 16GiB | 734 |
| 最大ユーザー数が 8 %増加 |
8vCPU & 32GiB | 1,608 |
| 最大ユーザー数が 13 %増加 |
16vCPU & 64GiB | 2,712 | 2,812 | 最大ユーザー数が 4 %増加 |
テスト手法
次のセクションでは、アトラシアンのパフォーマンス テストで使用するテスト環境 (ハードウェア仕様を含む) とテスト手法を詳しくご説明します。
テスト方法
次のテーブルは、テストで使用したデータセットを表しています。
データ | 値 |
|---|---|
ページ | ~900,000 |
ブログ投稿 | ~100,000 |
添付ファイル | ~ 2,300,000 |
コメント | ~ 6,000,000 |
スペース | ~5,000 |
ユーザー | ~5,000 |
実行した操作
最も一般的なユーザーのアクションの例を表す、さまざまなアクションを選択しました。このコンテキストにおけるアクションとは、ブラウザ ウィンドウで課題を開くなどの、完全なユーザー操作です。次のテーブルでは、ペルソナのテスト用にスクリプトに含めたアクションの詳細と、1 回のテスト中に各アクションが何回繰り返されるかを示しています。
操作 | 1 回のテストで操作を実行した回数 |
|---|---|
ページを作成 (単一ユーザー) | 417 |
ページを公開する | 255 |
ページを公開 (小さな添付ファイル付き) | 37 |
ページを公開 (大きな添付ファイル付き) | 19 |
ページを表示 | 497 |
ページを表示 (小さな添付ファイル付き) | 124 |
ページを表示 (大きな添付ファイル付き) | 38 |
公開後にページを表示 | 259 |
公開後にページを表示 (小さな添付ファイル付き) | 41 |
公開後にページを表示 (大きな添付ファイル付き) | 20 |
検索 | 2,092 |
ログイン | 623 |
ログアウト | 311 |
ページを作成 (コラボレーション) | 623 |
ブログ投稿を作成 | 1,673 |
ブログ投稿を表示 | 311 |
Edit page | 623 |
ページを編集 (共有リンクから) | 623 |
ページを編集 (添付ファイル付き) | 18 |
ダッシュボードの表示 | 623 |
ページへのいいね! | 612 |
添付ファイルをアップロード | 1,217 |
添付ファイルを表示 | 1,041 |
コメント | 935 |
サイトのインデックス再作成 | 1 |
テスト環境
すべてのパフォーマンス テストは、一連の AWS EC2 インスタンス上で実行されました。テストのたびに環境全体をリセットして再構築し、各テストの最初にはインスタンス キャッシュをウォームアップするアイドル サイクルを実行しました。Confluence Data Center で使用された環境の詳細と、EC2 インスタンスの仕様を次に示します。
テストを実行するために、仮想ユーザーを表すスクリプトを組んだ 4 つのブラウザと、220 のバックグラウンド スレッドを使用して、アクションの実行にかかる時間を測定しました。各ブラウザのスクリプトは、定義済みのアクション リストからランダムにアクションを実行して、ただちに次のアクションに移る (つまり思考時間がゼロになる) ように記述されていました。各バックグラウンド スレッドも同様に、バックエンド API 呼び出しのリストからランダムなアクションを実行して、すぐに次の呼び出しに進むように記述されていました。その結果、各ブラウザ/スレッドは、実際のユーザーが実行できるよりもはるかに多くのタスクを実行していました。
各テストを実行する前に、5 分間のウォームアップから開始して、次に各テストを 60 分間実行しました。
キャパシティ テストでは、仮想ユーザーを表すバックグラウンド スレッドの数を、飽和点に達するまで徐々に増やしました。
一貫した結果を得るために、すべてのテストを何度も実行しました。
Confluence Data Center テスト環境の詳細は次のとおりです。
Confluence ノード 2 個
別のノード上にあるデータベース
別のノード上にあるロード ジェネレーター
別の NFS Server ノード上にある共有ホーム ディレクトリ
Load Balancer (AWS ALB Application Load Balancer)
Confluence Data Center (2 ノード)
ハードウェア | ソフトウェア | ||
|---|---|---|---|
EC2 タイプ | m5.2xlarge | Operating system | Amazon Linux 2 |
vCPU | 8 | Java プラットフォーム | Java 11.0.9.1 |
メモリ (GiB) | 32 | Java オプション | 8 GB ヒープ |
物理プロセッサ | Intel Xeon Platinum 8175 | ||
Clock Speed (GHz) | 3.1 | ||
CPU Architecture | x86_64 | ||
ストレージ | AWS EBS 200 GB gp2 | ||
データベース
ハードウェア | ソフトウェア | ||
|---|---|---|---|
EC2 タイプ | db.m5.xlarge | データベース: | PostgreSQL 10.17 |
vCPU | 4 | オペレーティング システム: | Amazon Linux 2 |
メモリ (GiB) | 16 | ||
物理プロセッサ | Intel Xeon Platinum 8175 | ||
CPU Architecture | 64-bit | ||
Clock Speed (GHz) | 2.5 | ||
ストレージ | AWS EBS 700 GB gp2 | ||
NFS サーバー
ハードウェア | ソフトウェア | ||
|---|---|---|---|
EC2 タイプ | m4.large | Operating system | Amazon Linux 2 |
vCPU | 2 | ||
メモリ (GiB) | 8 | ||
vCPU あたりのメモリ (GiB) | 4 | ||
物理プロセッサ | Intel(R) Xeon(R) CPU E5-2686 v4 | ||
Clock Speed (GHz) | 2.3 | ||
CPU Architecture | x86_64 | ||
ストレージ | AWS EBS 100 GB gp2 | ||
ロード ジェネレーター
ハードウェア | ソフトウェア | ||
|---|---|---|---|
vCPU | 5 | Operating system | Ubuntu 22.04.3 LTS |
メモリ (GiB) | 20 | Python Version | 3.11 |
物理プロセッサ | Intel(R) Xeon(R) Platinum 8375C | ||
Clock Speed (GHz) | 2.9 | ||
CPU Architecture | x86_64 | ||
注: キャパシティ テストでは、Confluence ノード 1/2/4 個、または適切な EC2 サイズ m5.xlarge/m5.2xlarge/m5.4xlarge のいずれかで構成される環境を使用しました