現在表示中:

アドビの Web Experience Management(WEM)堅牢性評価チームは、一連のパフォーマンスおよび処理能力テストを実施して、各種の一般的な設定での CQ/CRX の動作のベンチマークテストをおこないました。

読者はこの結果を参考にし、提示されたシステムの処理能力およびスケーラビリティを予測することができます。

また、このドキュメントには、次の 2 つのガイドラインも記載されています。

  • 個別のパフォーマンスプロファイリングテストを実行する方法
  • 結果を解釈し、既存のシステムを検証する方法

アプリケーションのシステムリソース使用率および最大スループットを特定できるように、一部の作成者および公開シナリオに限定したユーザーのスケーラビリティに関する結果も提供します。

テストシナリオ - 作成者

作成シナリオは、作成プラットフォームとしての CQ のパフォーマンスに重点を置いたものです。公開された CQ コンテンツへのエンドユーザーアクセスは考慮していません。

次の項目を調査します。

  • 更新操作のパフォーマンス
  • ページの作成、編集およびアクティベーション操作のスケーラビリティ

サイト作成シナリオ

各スレッドによって 1 つの CQ ページが作成されます。ページコンテンツは、画像と SWF ビデオを追加することで生成されます。その後、ページは、パブリッシュインスタンスへのレプリケートのためにアクティベートされます。レプリケーション後にこのページは削除されます。

このシナリオは、これらの操作の実行中にユーザーが生成するすべての GET および POST 要求で記録されます。

注意:

ブラウザーキャッシングは考慮されません。

スループットの定義

このドキュメントで報告されるすべてのベンチマークテストにおいて、スループットは 1 時間あたりのトランザクション件数として測定し、各トランザクションは、以下に詳述する特定の代表的なユーザーアクションで構成されます。特定の実際のシナリオと比較するには、1 時間あたりの更新件数でスループットを表すと役立つ場合があります。この場合、シナリオには 10 個の個別の更新操作が含まれるので、1 時間あたりの更新件数を表す数値のレポートを得ることもできます。

代表的なトランザクションは、次の手順で構成されます。

  • ログインし、Web サイトコンソールを開きます。
  • SWF を含むページを作成します。
  • 画像/テキストコンポーネントを追加します。
  • タグクラウドを追加します。
  • サイトマップを追加します。
  • コメントセクションを追加します。
  • 評価セクションを追加します。
  • ページをアクティベートします。
  • ページを削除します。

1 つのトランザクションに約 10 個のページ更新があります。

シナリオの完了

シナリオは、次の時点で完了としてマークされます。

  • すべての手順を 1,000 回繰り返し実行したとき
  • 公開キューが空になったとき
  • Sling イベントで処理を待機しているジョブがなくなったとき

シナリオの実行

このベンチマークテストを実施する目的は、現在のシステム設定で達成できる最大スループットを特定することです。 この最大スループットは、設定に変化を加えることにより、様々な負荷レベルで達成できます。 使用するアプローチは、最大スループットに達したことが明らかになるまで負荷レベルを徐々に上げながら、ベンチマークテストを実行するというものです。 システムの負荷を高くするために同時要求スレッドを追加していくことで、サーバー上の同時操作の件数を増やしていきます。

最初は所定の数のスレッドを使用し、実行ごとにスレッド数を増やして、一連のベンチマークテストを実施しました。 実行ごとにスループットを計算しました。そして、複数回の実行の結果を組み合わせ、次のような結果を得ました。

このグラフは、14 個のスレッドでの最大スループットを示しています。このスループットでは、スリープ/待機時間は考慮されていません。 マルチスレッドによる同時実行が増えるにつれて、ごくわずかな低下傾向も見られます。

  • シナリオのスループット:1 時間あたり 1,581 件のトランザクション
  • 各トランザクションに 10 個の更新があるので、時間単位の更新件数は 1 時間あたり 15,800 件になります。

スレッド数を増やす際に、システムリソースについて次のような傾向が確認されました。

スレッド数の増加に伴いメモリ使用率がわずかに上昇しますが、全体のヒープ使用率が 4,096 MB のヒープの 80 %を超えることはありません。 このベンチマークテストでは、CPU の使用率はそれほど高くありません。

最大スループット時の動作

  • 1,000 ページを追加する間にリポジトリが約 4.5 GB 増えました(Tar PM の最適化を実行する前)。
  • 公開キューは、約 90 %の時間が待機中のままでした。アクティベーション処理は高速で、同時に 14 個のスレッドがアクティベートしました。記録されたキューの最大長は 2 でした。
  • レプリケーションイベントの平均イベント処理時間は約 125 ms のままですが、平均待機時間は約 47 ms でした。合計 3,000 件のイベントが 1 時間で処理されました。

次のグラフに、イベント処理の傾向を示します。

平均処理時間も平均待機時間も実行全体で適切に推移していることは明らかです。平均処理時間と平均待機時間のどちらも、短縮傾向に対する安定化を示しています。

サイト変更シナリオ

このシナリオでは、1 つのスレッドで 10 件のトランザクションが実行されます。各トランザクションでは、次の操作が行われます。

  • ページを作成し、アクティベートします。
  • 8 つのページを変更し、アクティベートします。
  • ページを作成し、アクティベートします。
  • 同じページを変更し、再度アクティベートします。

このシナリオは、これらの操作の実行中にユーザーが生成するすべての GET および POST 要求で記録されます。

注意:

ブラウザーキャッシングは考慮されません。

スループットの定義

このシナリオのスループットは、1 時間あたりのトランザクション件数として定義します。各トランザクションには次の手順があります。

  • サイト作成シナリオの説明に従ってページを作成し、アクティベートします。
  • 8 つのページを変更し、アクティベートします。
  • サイト作成シナリオの説明に従ってページを作成し、アクティベートした後、同じページを変更し、再度アクティベートします。

各トランザクションで合計 29 個のページ更新が実行されます。

シナリオの完了

シナリオは、次の時点で完了としてマークされます。

  • すべての手順を約 200 回繰り返し実行したとき
  • 公開キューが空になったとき
  • Sling イベントで処理を待機しているジョブがなくなったとき

シナリオの実行

一連のベンチマークテストはそれぞれ次のものを使用して実施しました。

  • 所定の数のスレッド
  • 実行ごとに増やしたスレッド数 

実行ごとにスループットを計算しました。複数回の実行の結果を組み合わせ、次のような結果を得ました。

このグラフから、10 個のスレッドで最大スループットを達成したことがわかります。このスループットでは、スリープ/待機時間は考慮されていません。

  • シナリオのスループット:1 時間あたり 303 件のトランザクション
  • 各トランザクションに 29 個の更新があるので、時間単位の更新件数は 1 時間あたり 8,800 件になります。

スレッド数を増やす際に、システムリソースについて次のような傾向が確認されました。

ヒープ使用率はわずかに変化し、スループットが最も高い時点でヒープ使用率も最高になっています。 最大ヒープ使用率は、4,096 MB のヒープの 82 %です。 このベンチマークでは、CPU の使用率はそれほど高くありません。

最大スループット時の動作

  • 200 ページを追加し、約 1,800 ページを変更する間にリポジトリが約 2.7 GB 増えました(Tar PM の最適化を実行する前)。
  • 公開キューは、約 90 %の時間が待機中のままでした。同時に 10 個のスレッドがアクティベートしました。記録されたキューの最大長は 9 でした。
  • レプリケーションイベントの平均イベント処理時間は約 136.8 ms のままですが、平均待機時間は約 154.9 ms でした。合計 8,000 件のイベントが 40 分で処理されました。

次のグラフに、イベント処理の傾向を示します。

このグラフから、イベント処理は実行を通して一定していたことがわかります。

手動によるサイトブラウズ

このベンチマークの目的は、負荷がある場合とない場合、およびブラウザーキャッシングがある場合とない場合の UI の応答を測定することです。このシナリオをテストするために、一連のページを開いて、最初のページ要求から最後のページ要求までの時間を測定することにより読み込み時間を測定しました。このシナリオでは、次のページをテストしました。

  • ログインページ
  • ようこそページ
  • Siteadmin
  • 新しいページ(Geometrixx コンテンツページ)
  • 空白のページを開く(Geometrixx コンテンツページ)
  • 既存のページを開く(SWF、画像、サイトマップおよびタグクラウドが 1 つずつある Geometrixx コンテンツページ)
  • Damadmin
  • DAM 管理
  • PNG DAM アセットを開く

以上のページについて、シナリオを合計 4 回繰り返し実行しました。

  • 1 人のユーザー、初回(サーバー/クライアントキャッシュなし)
  • 1 人のユーザー、2 回目
  • 複数のユーザー、初回(クライアントキャッシュなし)
  • 複数のユーザー、2 回目

初期システム状態

初期システム状態は次のとおりです。

  • デフォルトデータを使用した CQ オーサーインスタンス
  • 「初回」テストケースに対してクリーンなブラウザーのキャッシュ
  • サーバーとクライアント間の 1 Gb/秒の回線

シナリオの実行

このシナリオは、4 回繰り返し実行しました。初回は、クリーンなサーバーキャッシュとクリーンなクライアントキャッシュで開始し、前述のページの読み込み時間を記録しました。2 回目には、ページの読み込み時間を再度測定しましたが、キャッシュをクリーンアップしませんでした。

ブラウザーおよびサーバー側キャッシュがあるので、2 回目は読み込み時間が大幅に短いことがわかります(ほとんどの場合)。

  • ブラウザーおよびサーバーキャッシュがある場合、所要時間は 40 %短縮されました。

繰り返しをもう 1 セット実行しましたが、このときは、(サイト作成シナリオで最大スループットを達成したスレッド数に近い)15 個のスレッドがサーバーにアクセスしていました。初回と 2 回目の両方の読み込み時間を記録しました。測定値は次のとおりです。

ここでは、15 人のユーザーによる負荷で、サーバーキャッシュが作成済みであることがわかります。また、ブラウザーのキャッシュによって、初回のアクセスと 2 回目のアクセスでは所要時間が約 10 %短縮されました。

このデータでは、サーバーキャッシュがどの程度貢献しているかがわかります。

このグラフから、サーバーキャッシュによって、サイトの応答が約 40 %向上していることがわかります。

コンテンツボリュームがパフォーマンスに与える影響

このテストの目的は、継続的に 50,000 ページを作成したときの CQ オーサーインスタンスのスループットの傾向を特定することです。このテストでは、CPU、ヒープ、リポジトリサイズなどのシステムリソースを記録します。

作成者のサイト作成シナリオで使用したスクリプトと同じものを使用して、ページを作成します。このシナリオは、これらの操作の実行中にユーザーが生成するすべての GET および POST 要求で記録されます。

注意:

ブラウザーキャッシングは考慮されません。

シナリオの実行

このシナリオでは、ページをバッチで作成しました。バッチの間には、CQ オーサーインスタンスを再起動しませんでした。代わりに、Tar PM の最適化を手動で起動しました。これらのページは、サイト作成シナリオについて記録したスクリプトを使用して作成されました。

ページは、次のバッチで作成されました。

バッチ ページ数 リポジトリ内の総ページ数
1 1,000 1,000
2 2,000 3,000
3 4,000 7,000
4 8,000 15,000
5 16,000 31,000
6 32,000 63,000

確認されたスループットの傾向は次のとおりです。

上のグラフから、次の場合にもアプリケーションのスループットは一貫していることがわかります。

  • 36 時間以上連続して実行した後
  • リポジトリ内のページ数が増加した後

リポジトリの増加に見られる傾向は次のとおりです。

このグラフは、次のことを明確に示しています。

  • CQ インスタンスに追加されるページが多いほど、
  • リポジトリサイズの増加速度が速くなります。

つまり、リポジトリの増加は線形ではありません。最適化の間に追加するノードの数によって異なります。 4,000 ページを追加すると、リポジトリは約 45 GB まで増加します。 必要なディスクストレージを減らすために、Tar PM の最適化を起動することが必要な場合があります。

次のグラフに、Tar PM の最適化がリポジトリの増加にもたらす効果を示します。このグラフの縦軸は対数で示されている点に注意してください。ワークロードトランザクションによってディスク容量が非常に急速に増加しますが、最適化によって、その容量の大部分が回収されます。 最適化後におけるリポジトリ容量の使用率の増加ははるかに緩やかで、8,000 ページでも約 2 GB に維持されています。

Tar PM の最適化の実行に要する時間における傾向は非常に明確であり、リポジトリ内のコンテンツの量に直接関連しています。 

次のグラフに、最適化の所要時間とページの総数との(ほぼ)線形の関係を示します。

テストシナリオ - 公開

公開に焦点を置いたシナリオは、作成アクティビティが関与しないエンドユーザー要求を処理するときの CQ のパフォーマンスを検討することを目的としています。 公開シナリオにデータの更新が関与することもありますが、作成者シナリオと比べると、更新や書き込みの頻度は大幅に低くなります。

公開の混合シナリオ(書き込みが多い)

このシナリオの各スレッドでは、パブリッシュ環境でサイズが様々なタスクが実行されます。このシナリオでは、1 件のトピックを作成して、2 件のコメントを追加し、5 件の記事を評価します。これをすべて、Geometrixx Web サイトをブラウズしながらおこないます。

このシナリオは、これらの操作の実行中にユーザーが生成するすべての GET および POST 要求で記録されます。ブラウザーキャッシングの動作はこのシナリオでは再現されないので、各クライアント要求は、キャッシュされていない初期要求のように機能します。

スループットの定義

このシナリオのスループットは、1 時間あたりのトランザクション件数として定義します。各トランザクションには次の手順があります。

  • パブリッシュインスタンスにログインします。
  • 件名と説明を指定して、トピックを作成します。
  • このトピックに 5 件のコメントを追加します。
  • Products/Circle ページに移動します。
  • このページで 10 件の評価を追加します。

トランザクションごとに 16 個の更新が行われます。

シナリオの完了

このシナリオは、すべての手順が、指定された回数繰り返し実行された時点で完了としてマークされます。

シナリオの実行

このベンチマークシナリオは、1 台の公開サーバーを使用して実行されました。 それぞれ所定の数のスレッドを使用し、実行ごとにスレッド数を増やして、一連のベンチマークテストを実施しました。 実行ごとにスループットを計算しました。 

複数回の実行の結果を組み合わせ、次のような結果を得ました。

このグラフから、約 16 個のスレッドで最大スループット(1 時間あたり 600 件をわずかに上回るシナリオトランザクション)を達成したことがわかります。

  • シナリオのスループット:1 時間あたり 619 件のトランザクション
  • 各トランザクションに 16 個の更新があるので、時間単位の更新件数は1時間あたり 9,900 件になります。

個々の負荷レベルで多少のスループットの変動はありましたが、サーバーは、試行されたすべての負荷レベルで 1 時間あたり 450 件以上のトランザクション(1 時間あたり約 7,200 件の更新)を処理できました。

スレッド数を増やす際に、システムリソースについて次のような傾向が確認されました。

ヒープ使用率は、同時実行のスレッド数によって多少異なりますが、負荷が高くなると、大部分は 4,096 MB のヒープの 90 %をわずかに超えています。 この公開ワークロードでの CPU 使用率は、純粋な作成で見られたものよりも少し高くなっています。

最大スループット時の動作

16 個のスレッドで 15 回繰り返すと(15 件のトピック、30 件のコメントおよび 75 件の評価が作成され)、Tar PM の最適化の前には、公開のリポジトリサイズが約 90 MB に増加しました。

ディスクのスループットは 1 秒あたり約 50 件のトランザクションで推移しましたが、このサーバーにおけるディスクの最大処理能力を大幅に下回りました。

サイトブラウズシナリオ(読み取りが多い)

このシナリオの各スレッドでは、Geometrixx Web サイトがブラウズされます。各スレッドでは、2 組のページがそれぞれ 5 回ブラウズされ、記事にコメントが 1 件追加されます。

このシナリオは、次の 2 つの方法で記録します。まず、これらの操作の実行中にユーザーが生成するすべての GET および POST 要求で記録します。 2 つ目の記録では、ブラウザーキャッシュの操作を有効にし、正常に動作するブラウザーが Web サイトへの 2 回目の訪問時に生成するページ読み込みのみを記録するように許可します。 コンテンツの大部分がブラウザーキャッシュから取得されるので、2 つ目のケースのスクリプトは最初のケースのスクリプトよりも大幅に小さくなります。

スループットの定義

このシナリオのスループットは、1 時間あたりのトランザクション件数として定義します。各トランザクションには次の手順があります。

  • パブリッシュインスタンスにログインします。
  • 最初の組の 5 ページをブラウズして、それぞれでページ読み込みを 5 回実行し、合計 25 回のページ読み込みを実行します。
  • 2 組目の 5 ページをブラウズして、それぞれでページ読み込みを 5 回実行し、さらに 25 回のページ読み込みを実行します。
  • 記事にコメントを追加します。

このシナリオでは全体で、50 回のページ読み込みが実行され、記録方法の違いに応じて、それぞれがキャッシュされる場合と、キャッシュされない場合があります。 それぞれの繰り返しで 1 つの更新が実行されます。

シナリオの完了

このシナリオは、すべての手順が、指定された回数繰り返し実行された時点で完了としてマークされます。

シナリオの実行 - ブラウザーキャッシュなし

この実行では、可能性があるすべての GET および POST 要求を記録したスクリプトを使用しました。

約 18 回実行しました。8 スレッドから開始し、実行ごとにスレッド数を増やしました。実行ごとにスループットを計算しました。18 回実行した後、次のような結果になりました。

このグラフから、約 30 個のスレッドで最大スループットを達成したことがわかります。各トランザクションには、2 組の 5 ページのブラウズとコメントの追加が含まれています。このスループットには、スリープ/待機時間は含まれていません。

  • シナリオのスループット:1 時間あたり 507.5 件のトランザクション
  • ページ表示のスループット:1 時間あたり 24,400 件以下のページ表示

スレッド数を増やす際に、システムリソースについて次のような傾向が確認されました。

シナリオの実行 - ブラウザーキャッシュあり

この実行では、可能性があるすべての GET および POST 要求を記録したスクリプトを使用しました。

合計 9 回実行し、8 スレッドから開始して、実行ごとにスレッド数を増やしました。実行ごとにスループットを計算しました。9 回実行した後、次のような結果になりました。

このグラフから、約 17 個のスレッドで最大スループットを達成したことがわかります。各トランザクションには、50 回のページ表示とコメントの追加が含まれています。このスループットには、スリープ/待機時間は含まれていません。

  • シナリオのスループット:1 時間あたり 1,848 件のトランザクション
  • ページ表示のスループット:1 時間あたり約 92,400 件以下のページ表示

スレッド数を増やす際に、システムリソースについて次のような傾向が確認されました。

ブラウザーキャッシュの効果

ユーザーがサイトに戻ったり、ページを複数回ブラウズしたりすることを想定した場合、ブラウザーキャッシュがページ読み込みの一部を扱います。 

これらのテストは、読み取りが多いシナリオでは、ブラウザーキャッシュを考慮せず、すべての静的要求をやり直したシナリオと比べると、スループットが 3.6 倍向上する可能性があることを示しています。

ブラウザーキャッシュ操作を有効にすると、1 時間あたりのページ表示が 92,000 件を超えています。これは、ブラウザーキャッシュの効果を除外したときに見られた、1 時間あたり 24,000 件のページ表示を大幅に上回ります。

テストシナリオ - 混合

これらのシナリオでは、作成者シナリオタイプと公開シナリオタイプを組み合わせて、エンドユーザーのブラウズと同時に作成とアクティベーションが行われる場合に見られるパフォーマンスを検討します。

パブリッシュインスタンス数の増加

このベンチマークテストの目的は、オーサーノードでアクティベーションをおこない、複数のパブリッシュインスタンスに更新内容をレプリケートする必要がある場合に発生するスケーラビリティの問題を検討することです。 作成者のサイト変更シナリオをもう一度実行しますが、ここではパブリッシュインスタンス数を増やします。これは、パブリッシュインスタンス数を増やしたときにオーサーおよびレプリケーション処理のスループットがどうなるかを調査するためです。パブリッシュインスタンスを 1 つ、2 つおよび 3 つにしてテストを実施しました。

作成者のサイト変更シナリオは、2 つのページを作成し、9 つのページを変更する混合シナリオです。それぞれの繰り返しに、合計 11 回のアクティベーションがあります。

ここでは、3 つのシナリオすべてのスループットの傾向が相互にかなり似ていることがわかります。 1 時間あたりのシナリオの件数が 300 件をわずかに上回るというピークシナリオは、ほとんど同じです。 スレッドを追加して負荷を高くすると、3 ノード設定の低下率がわずかに小さくなっています。ただし、スループットは、すべてのケースで 1 時間あたり 200 件のシナリオを超えました。

次のグラフに、ワークフロー処理への影響を示します。

ここでは、平均処理時間の傾向がすべての実行について類似していることがわかります。 ページのアクティベーションに関連するバックグラウンド処理は、パブリッシュノードの数が 1 つ、2 つまたは 3 つのいずれの場合も、ほとんど同じ傾向をたどっています。

パブリッシュインスタンスの数が増加すると、平均処理時間はごくわずかに長くなる傾向があります。 このグラフでは、1 つのノードの場合の 135 ms から時間が長くなり、3 つのノードの場合は 140 ms をわずかに超えていることがわかります。

ベンチマーク環境

ハードウェア環境

報告されているすべてのベンチマークは、同一のバックオフィスサーバータイプシステム群で実行されたものです。 サーバーは次のとおりです。

Hewlett Packard モデル DL360-G7

設定は次のとおりです。

オペレーティングシステム RHEL 5.5
CPU Intel(R) Xeon(R) CPU E5649 @ 2.53 GHz
メモリ 32 GB
ディスクコントローラー SAS RAID コントローラー
ディスク 4 × 146 GB 15,000 RPM SAS
JVM 引数 -Xms512m -Xmx4096m -XX:MaxPermSize=256m

このシステムには、非常に高性能なディスクサブシステムがあり、非常に高速の小さいディスクが RAID0 ストライプセットにまとめられています。 冗長性はなく、最大パフォーマンスが得られます。 このディスク設定が実稼働環境で使用されることはほぼないと思われますが、実稼働で使用される可能性もある、はるかに高価な 8 ボリュームの RAID0+1 設定のパフォーマンスを再現するために、RAID0 設定を使用しています。ただし、セットアップコストは大幅に抑えています。

初期システム状態

システムパフォーマンスの一部の要素は、CQ リポジトリ内のコンテンツの量にある程度左右されることがあります。 ここで報告するベンチマークテストは、次のように、かなりの量のベースラインコンテンツを使用して実施しています。

  • コンテンツの基本負荷 - 50,000 ページ
  • リポジトリサイズ - 28.91 GB
  • Tar PM の最適化 - 実行済み
  • 索引統合 - 実行済み
  • システムキャッシュ - クリーンアップ済み

トポロジ

方法

ステップテスト

最大スループットを達成した時点を明らかにするために、サーバーの負荷レベルを徐々に上げていくステップテストとして各ベンチマークテストを実施します。

スレッドを増やしていくテスト活動をパフォーマンステストハーネスに編成します。まず、コア数ごとに、テストする必要があるすべてのスレッド数を定義します。それぞれのスレッド数についてスループットを測定し、最大スループットを達成したスレッド数を比較に使用します。

作成のテスト活動の場合、次の入力を使用しました。

コア 最大スループットを特定するためにテストするクライアントスレッドの数
8 4,5,6,7,8,9,10,11,12,13,14
16 8,9,10,11,12,13,14,16,18
24 8,10,11,12,13,14,16,20

各スレッド数のテストの間に、サーバー全体をリフレッシュし、バックアップから復元します。パフォーマンステストハーネスでは、各実行のシステムリソースも測定されます。

実行時には、JMX、iostat およびその他の関連ツールを使用して、スループット、ディスク使用率、ヒープ使用率および CPU 使用率が監視されます。 サンプル実行(24 個の CPU での作成者シナリオ)の実際のシナリオデータを次に示します。

実行全体について重要な指標を確認できます。 ここでは、平均 CPU 使用率が 20 %をわずかに下回り、平均ディスク使用率が 2.5 %をわずかに下回っています。 メインの節に掲載している表は、個々の CPU 数およびシナリオタイプについて、このように収集されたデータから作成されたものです。

更新の定義

更新は、次のいずれかの結果になるユーザーアクションとして定義されます。

  • 新しいページまたは DAM アセットの作成
  • 既存のページまたは DAM アセットの変更

(前述の各テストで言及した)1 時間あたりの更新件数の値は、1 時間以内に作成または更新されたページ数に相当します。

その他の情報

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー