Confluence 3.0 has significant performance improvements over Confluence 2.10 and earlier versions. This page explains the performance characteristics of Confluence 3.0 and shows the improvements that were made when compared to its predecessor Confluence 2.10. In brief, compared to version 2.10, Confluence 3.0 response times in Standalone mode are down by 30% to 40%, and response times in a cluster are down by 50%. In other words, the clustered version of Confluence 3.0 is now twice as fast as before. Confluence also scales a lot better than before: More or faster CPU's are better utilised with Confluence 3.0 than they were with 2.10 and earlier versions.
We have fixed a few bottlenecks that were so specific that you might have encountered them while analysing logfiles and thread dumps. Even if you did not see them, they might have been slowing your system down, depending on your use-case.
ボード全体で小規模な改善を実装し、Confluence の応答時間と拡張性を向上させました。これらの改善点は小さく、数も多いため個別に提示することはできないため、全般的なパフォーマンス テストの結果を使用して効果を説明します。
In our general Confluence performance tests, we execute a standardised set of commonly-used functions that simulates the activity of concurrent users. We base this profile on the actual usage patterns of our public Confluence installation, a rather large and active instance. To cater for irregular usage spike, we increase the load by factor 10. On average, this load test performs 10 to 15 Confluence requests per second. Most customer installations do not even get close to these numbers during normal operation. Under normal (low) load, the response times are actually a lot better than what we present here. But we prefer to use this medium load scenario because it simulates cases which may occur infrequently, and in which Confluence still needs to perform reasonably well. In addition to this scenario, we defined two additional, more extreme scenarios that perform the same requests, but at 20 to 35 requests per second to simulate an even higher load.
統計の読み方と理解の仕方ここでは、Confluence へデータを要求または投稿するすべての操作に対して、"リクエスト" という言葉を使用します。そのため、Confluence ページの表示、検索の実行、およびコメントの投稿はすべてリクエストであり、クイック ナビゲーション ドロップダウンを使用する際にもリクエストを実行します。 データ テーブルテーブル内の各列は、1 つのユース ケースを表します。すべてのユース ケースは、5 分のランプアップ期間で、30 分間平行して実行されます。
最も重要なユース ケースは次のとおりです。
グラフグラフは、1 秒あたりに処理される同時リクエストを表示します。青い線は、1 秒あたりの平均移動を、緑の線は偏差を表します。要求されたページ数と操作数が CPU 使用量によって大幅に異なるため、青い線は一定ではありません。コメントの付いていない短いページでは、多くのマクロとコメントを含む長いページよりもレンダリングが高速となります。つまり、多くの通知をトリガーする page-edit よりもレンダリングが高速になります。これらの要求数の違いにより、時間の経過とともに CPU 負荷にも違いが生じます。 青色の平均線が安定していれば、ユーザー エクスぺリンスもより一定していることを示します。線が上の位置にあるほど、Confluence を同時にアクセスおよび使用できるユーザー数が多くなります。 |
このページの注記は、Confluence 2.10 の際と同じテストを使用して、2.10 と 3.0 のパフォーマンスの違いを示すことを目的としています。
すべてのテストは、次の仕様を満たす 2 台 〜 4 台のサーバーで実行されました。
名前 |
値 |
|---|---|
サーバー モデル |
Dell 2950 |
CPU のタイプ |
Intel(R) Xeon(R) CPU E5405 @ 2.00GHz (4 コア) |
サーバーあたりの CPU |
テストに応じて 1 または 2 基。テストの詳細を見る。 |
RAM |
32Gb (JVM は 2Gb、データベースは 3Gb を使用) |
ディスク |
2 x 15K、72Gb SAS |
ネットワーク |
1Gbps |
Web サーバー |
Tomcat 6、Java 6 |
データベース |
Postgres 8.2.4 |
When testing the Confluence Standalone version, one server acts as the application server and one as the database server, which is the setup we recommend to customers to enable high performance. A third server is used to generate the load, using JMeter. In the cluster, we use two application servers and one database server. In the cluster configuration we use the Pound load balancer, which runs on the same (fourth) server as the load generator JMeter. We do not use any webserver or caching proxy for our tests, and we cannot make any recommendations about which one to use. We want to measure the raw performance of the application server and suggest that you use the webservers/proxies with which you are most familiar.
使用された JVM 設定: -XX:MaxPermSize=192m -Xmx2000m -XX:+PrintGCTimeStamps -verbosegc -XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:NewSize=384m -XX:SurvivorRatio=2 -XX:+UseParallelGC -XX:+UseParallelOldGC.仕様
これらのテストの際、パフォーマンスの問題があることが知られているため、使用状況追跡プラグインは無効化されます。高負荷デプロイメントでは、この機能をオフにすることをお勧めします。
最もよくあるのが、Confluence が 1 台の物理マシンにインストールされる場合です。クラスターを使用することがわかっている (または使用する計画がある) 場合、このセクションの対象となります。
Confluence 3.0 Standalone has significantly better performance characteristics than Confluence 2.10 Standalone. We compare three load scenarios and give the details below.
アトラシアンでは、中程度の負荷を、loadtest からの 1 秒あたりのリクエスト数がおよそ 15 件の場合と定義します。ユーザー ベースがこれよりも小さいほとんどの顧客は、この使用率には遠く及びません。そのため、応答時間は、以下に示されている例よりも大幅に短くなります。ただし、まれに、アクティブ ユーザー数が 1000 未満の顧客であっても、使用率の急増が発生することがあります。そのため、中程度の負荷シナリオとして 1 秒あたり 15 リクエストを選択します。
ここでは、中規模の企業が使用するであろう仕様として想定した、Xeon CPU 1 基、4 コアのみの中程度のハードウェア (上記を参照) を使用しています。
最も重要なシナリオ (「ページの表示」) では、この処理に約 900ms (Confluence 2.10) かかっていましたが、3.0 では、これが 600ms まで短縮されました (約 50% のパフォーマンス改善)。それ以外のほぼすべてのシナリオも同様に改善されました。中には 100% 以上 (例: 2 倍以上) 改善したものもあります。このシナリオのスループットは、約 13/秒から 14/秒に変化しただけでした。ただし、これは、テスト自体が多数のリクエストを行っていなかったためです。ここでの改善点は、たとえば、非常に複雑なページや多数のページをレンダリングする際などに、スループットの偏差 (上下) が削減されたことです。調整のページで説明したように、別のガベージ コレクターを使用して、線をより滑らかにすることも可能です。
アトラシアンでは、1 秒あたり約 25 のリクエストに等しい負荷を生成するシナリオを、高負荷シナリオとして定義します。このテストでは、2 CPU という点以外は上記と同じハードウェアを使用しています。1 秒あたり 20 件以上のリクエストが想定される企業は、たとえそれが短いタイム フレーム内に発生する場合であっても、このテストに使用した場合より強力なハードウェア リソース (同等のコストの) を所有すると想定します。
このシナリオは、Confluence 2.10 と 3.0 のパフォーマンス改善を最も良く表しています。Confluence 2.10 は 1 秒あたり約 22 件のリクエストを処理していたのに対し、Confluence 3.0 は 1 秒あたり約 27 件のリクエストを処理します。これは大きな改善ですが、応答時間はさらに劇的に変化しています。1 秒あたりのリクエストが 20 件になることがあれば、Confluence の応答時間は短くなり、ユーザーは違いに気付きます。
アトラシアンでは、ピーク時の負荷を、ロード ジェネレーターからの 1 秒あたりの要求数がおよそ 35 件のものとして定義します。これらの1 秒あたりのリクエスト件数がこれらの高レベルに到達する顧客はほとんどありませんが、100.000 のユーザーがいて、そのユーザーの多くが同時にページを表示する場合、ピーク時の負荷シナリオに到達することがまれにあります。このテストも、2 CPU ハードウェアで実行されました。
このテストは、同一コンピューター上のロード ジェネレーターによってわずかに歪められています。実際の結果はこれよりも少し良くなります。
Confluence 2.10 is able to deliver about 22 requests per second, but response times are not so good. Rendering a page takes 3s and rendering the dashboard takes 2s on average. Confluence 3.0 delivers improved throughput of about 28 requests per second and response times are significantly better than 2.10 (rendering a page is down to 2s, and rendering the dashboard is down to 1.4s). However, response times under Peak Load in 3.0 are still not ideal. Even with 2 CPUs Confluence 3.0 starts reaching its limits here. While standalone is able to deliver results, what we really recommend for this peak load scenario is a clustered solution. Read on for more details.
Confluence を多数のユーザーにロールアウトする際、負荷の急騰のバランスをとるためには、クラスター化が重要となります。最も一般的なデプロイメントでは、3 台の物理マシンマシンで実行されている (2 台 サーバーが 1 台のデータベース サーバーに接続されている) 2 ノードです。
クラスター化を行っても、低負荷シナリオでは 1 つのリクエストが早く処理される訳ではありませんが、クラスター化は並列して大量のリクエストを処理するシステムをサポートし、パフォーマンスが低下しません。
上記のように、中程度の負荷を、1 秒あたり約 15 件のリクエストとして定義します。このテストでは、1 台あたりの CPU は 1 のみです。
As you can see, the response time of each request is a lot better in Confluence 3.0. On average the performance has doubled, leading to response times that are just 50% of what they used to be. This means that a clustered installation provides the same responsiveness as a standalone installation, while still being much better at scaling, which will be shown below. In this example the load was so low that throughput did not increase very much.
上記のように、高負荷を、1 秒あたり約 25 件のリクエストが作成される状況として定義します。1 秒あたりのリクエスト数がこのレベルに到達する顧客はほとんどいませんが、数万ユーザーがいる場合は、ピーク営業時間に、これらのレベルに到達する可能性があります。このテストは、1 マシンあたり 2 CPU のサーバーで実行されます。
このテストでは、高負荷インスタンスのクラスターを使用することによって、どのようにスループットを高め、応答時間を削減できるかについて示しています。Confluence 3.0 には、クラスター バージョンにメリットのある多くの改善点があります。上記のテストの例では、負荷が大きくなると、Confluence は 8 コア マシンでより利用可能な CPU パワーをさらに活用し、非常に優れた応答時間で高い負荷を処理できることがわかります。これにより、クラスター化が
上記のように、ピーク時負荷を、1 秒あたり約 35 件のリクエストを作成するロード ジェネレーターとして定義します。このテストの間、1 台あたり 2 の CPU を使用しました。
このテストは、Confluence 3.0 がどの程度うまく拡張できるようになったかを示しています。負荷が大きくなっても、応答時間を短く維持します。Confluence 3.0 は、Confluence 2.10 よりも強力なハードウェアを活用できます。このことは、ページ ビューやダッシュボードなどの主要なシナリオでの応答時間を改善することで示されています。
フィードバックを歓迎します。このドキュメントはわかりやすかったですか? 最も関心を持っていた分野はカバーされていましたか?このページについてのコメントを残してください。