現在表示中:

概要

Adobe では、一連のパフォーマンスおよび処理能力テストを実施して、各種の一般的な設定での CQ DAM の動作のベンチマークテストをおこないました。読者はこの結果を参考にし、提示されたシステムの処理能力およびスケーラビリティを予測することができます。

セットアップの詳細

ハードウェア設定

報告されるすべてのベンチマークは、同一のバックオフィスサーバータイプシステム群で実行されたものです。サーバーは、次のように設定された Hewlett Packard モデル DL360-G7 です。

オペレーティングシステム  RHEL 5.5 
CPU  Intel(R) Xeon(R) CPU E5649 @ 2.53 GHz 
メモリ  32 GB 
ディスクコントローラー SAS RAID コントローラー 
ディスク  4 x 146 GB 15,000 RPM SAS 
Java バージョン  Java 1.6.0_26(64 ビット) 

ローカルストレージ

このシステムでは、非常に高性能なディスクサブシステムをローカルストレージに使用しており、非常に高速の小さいディスクが RAID0 ストライプセットにまとめられています。ディスク設定は、実稼働に適した 8 ボリュームの RAID0 + 1 設定のパフォーマンスを再現するように設計されています。

ストレージエリアネットワーク

DAM の大容量ストレージが、高性能 EMC ストレージエリアネットワークおよびネットワーク接続ストレージアプライアンスに配置されています。DAM ストレージには、NFS を介してアクセスします。アプリケーションサーバーと SAN サーバーは、2 GBit/秒の効果的なスループットをストレージサーバーに提供するギガビットイーサネット接続のボンディングペアを介して専用ストレージネットワークに接続されています。EMC ストレージアプライアンスは、アプリケーションベンチマークの実行中はそのためにのみ使用されるので、他のアプリケーションからの同時負荷が発生することはありません。

トポロジ

次の図に、パフォーマンスベンチマークに使用したネットワーク設定を示します。

ソフトウェア設定

ソフトウェア設定はすべてデフォルト/標準でしたが、ベンチマーク用に特別に次の設定をおこないました。

カスタム設定 説明
メモリ引数 Xms512m - Xmx4096m - XX : MaxPermSize = 512m

このシナリオではメモリ引数を大きくする必要があります。引数が小さいと、メモリが不足する可能性があります。
ワークフロースレッドの数 6

デフォルトのワークフロースレッド数は、オペレーティングシステムで認識される CPU の数と同じです。この場合、サーバーには 12 のコアと 12 の追加ハイパースレッドがあるので、デフォルトでは 24 です。サーバーで確認された CPU 使用率、およびフォアグラウンドプロセスとバックグラウンドプロセス間の環境設定に従って、この数を変更することをお勧めします。使用可能な各プロセッサーがワークフローを処理している場合、ワークフロー処理のスループットは向上しますが、フォアグラウンド処理の速度は低下することがあります。ここで使用した設定で許可されるスレッドの数は 6 つまでです。これは、ハイパースレッドを無視すると、使用可能な CPU の約半分です。
Tar PM の最適化 オフ

ベンチマークの実施に対する影響を回避するために、ベンチマークの実行中は、午前 2 時から午前 5 時までのスケジュールされた時間に実行される Tar PM の自動実行をオフにしました。

FFmpeg の設定

DAM では、ビデオアセットを処理するために FFmpeg をサーバーにインストールする必要があります。報告されるベンチマークで使用したバージョンは、バージョン 0.10.2 です。

カスタム設定 説明
コーデック alac オーディオおよびビデオコーデックに変更されたオーディオコーデックは、サーバーにインストールされた FFmpeg ビルドに従って変更する必要があります。
エンコード 1 パス

デフォルトの 2 パス設定で発生した機能上の問題により、ここに示すベンチマークは、デフォルトではない 1 パス設定を使用して実施しました。
FFmpeg プロセスによって生成されるスレッド数 2

デフォルト設定では CPU 使用率が 100%まで急上昇したので、FFmpeg によって生成されるスレッド数を 2 に制限する必要がありました。

データボリューム

DAM パフォーマンスベンチマークはすべて、一貫した構成およびフォルダー構造のデータを使用して、一貫した初期データ量で実施します。

分布

第 1 レベルには 2 つのフォルダーがあり、それぞれ第 2 レベルの 10 個のフォルダーが含まれます。10 個のフォルダーにはそれぞれ、第 3 レベルの 300 個の DAM アセットが含まれます。第 3 レベルの各フォルダーの 75 %が JPG ファイル、20 %が TIFF ファイル、5 %が MP4 ファイルです。基本負荷に加えて、追加のフォルダーが 1 つ作成され、各タイプ(JPG、TIFF および MP4)の 5 つのファイルが含まれます。このフォルダーは、表示操作のベンチマークテストに使用されます。このフォルダーは第 2 レベルに作成されるので、最初のフォルダーの第 2 レベルには 11 個のフォルダーが含まれることになります。

ファイルのタイプ サイズ アセット数による割合 アセットサイズによる割合
JPG 2 MB 4,500 75 % 16.3 %
TIFF 28.7 MB 1,200 20 % 59.4 %
MP4 47 MB 300 5 % 24.3 %

一意性

DAM は、複数の名前で保存されている同じ画像など、アセットの重複を検出する機能を備えており、同じオブジェクトが複数コピーされることを防ぐことによりストレージを最適化します。ただし、パフォーマンスベンチマークでは、一貫性を確保しながらベンチマークを繰り返し実行できるように、一連の固定されたアセットが必要です。パフォーマンスベンチマークで重複するアセットが検出されないようにするには、DAM の操作が一意のアセットを使用した実際の操作を表すように、アセットを他のインスタンスと区別するための方法が必要です。

サンプルアセットを取り出し、同じアセットの一意のコピーを作成するために、そのタイトルおよび作者名メタデータを変更します。タイトルはアセットごとに一意です。作者名プロパティは、250 の単語からランダムに選択します。このプロパティは、検索ベンチマークケースでフルテキスト検索に使用されます。

画像ファイルは、EXIF ツールを使用して変更します。ビデオの場合、カスタム java コードを使用して、一部のメタデータタグ(XMP と非 XMP の両方)をランダムな辞書の単語に置き換えます。

タグ

各アセットに 10 個のタグを適用します。これらのタグは、CQ のデフォルトのインストールに付属している、あらかじめ定義されたタグのサブセットから選択します。これらのタグのうち、9 個はランダムに選択しますが、1 つのタグは固定されています。これは、負荷としてアップロードされる 6,000 個のアセットを、後でリポジトリにアップロードされるアセットから分離し、新しくアップロードされたベンチマークアセットが検索結果に影響しないようにするためです。負荷に適用されるタグのサブセットは、ベンチマークの一環としてアセットに適用されるタグのサブセットとは相互に排他的です。

初期システム状態

一部のベンチマークには、DAM へのアセットの追加が含まれます。各ベンチマークケースで、次の初期条件がベースラインとして規定されています。

  • 上記で定義した構成による合計 6,000 個の一意の DAM アセットがあります。
  • アップロードされたすべてのアセットについてワークフロー処理が完了しています。
  • データストアのガベージコレクションが完了しています。
  • 索引が統合され、Tar PM の最適化が完了しています。Tar PM の自動スケジューリングがオフになっていても、手動で開始する Tar PM の最適化が必要に応じて実行される点に注意してください。
  • システムキャッシュがクリーンアップされています。

バッチアップロードおよびタグ付けシナリオ

このベンチマークシナリオは、多数のアセットを間断なく挿入する必要がある、DAM の一般的なバルク読み込みをシミュレートすることを目的としています。多数のアセット挿入を含む他のアプリケーションワークロードもシミュレートします。このワークロードでは、各スレッドで 1 つのアセットがアップロードされ、10 個のタグが適用されます。

実装の詳細

 

画像とビデオが混在する合計 3,000 個のアセットを DAM にアップロードします。これらのアセットは、3 レベルの構造にアップロードされます。第 1 レベルでは、フォルダーの総数はスレッド数と同じで、各スレッドが一意のフォルダーに対して操作をおこないます。第 3 レベルには、300 ファイルという上限があります。したがって、第 2 レベルのフォルダー数は、スレッドの数によってある程度決まります。

次の図に、ベンチマークフォルダーにアップロードされるファイルの分布を示します。

 

アップロードされるアセットの中で、それぞれのファイル形式の割合は、データボリュームの節で定義したものと同じです。適用されるタグは、CQ のデフォルトのインストールで使用可能なタグのサブセットから選択されます。

スループットの定義

DAM へのアセットのアップロード時には必ず、非同期ワークフロー操作のバックグラウンド実行がトリガーされて、アセットのレンディションが作成され、アセットからメタデータが抽出されます。ワークフローの実行は初期アップロード操作に対して非同期で、通常は完了までに時間がかかるので、システムのスループットを評価するには、これらのワークフローのバックグラウンド実行を監視する必要があります。

このベンチマークは、スループットを 1 分あたりのトランザクション件数で測定することを目的としています。次の 2 つの異なるスループットを測定します。

  • 同期操作のスループット。アップロードとタグ付けが完了するまでの所要時間を測定します。
  • 全体のスループット。非同期ワークフロー実行が完了するまでの所要時間も考慮されます。

シナリオのワークロードは一連のトランザクションで構成され、それぞれに次の手順が含まれます。

  • 15 個の JPG ファイルのアップロードとタグ付け(75 %)
  • 4 個の TIFF ファイルのアップロードとタグ付け(20 %)
  • 1 つの MP4 ファイルのアップロードとタグ付け(5 %)

アセットの内訳は、データボリュームの節で説明したサイズとタイプによる割合と同じです。各トランザクションで 20 個のファイルがアップロードされ、その結果のスループットは 1 分あたりのトランザクション件数または 1 分あたりのファイル数で表すことができます。

このベンチマークシナリオでは、次の時点を完了と見なします。

  • アップロードおよびタグ付けの同期操作が終了したとき
  • Sling イベントで処理を待機している非同期ワークフローがなくなったとき

最大スループットを達成するスレッド数の特定

このベンチマークにおけるスループットは、アセットの同期アップロードおよびタグ付けを要求する同時スレッド数によって変化します。最大スループットを達成した時点を特定するために、スレッド数を増やしながら、ベンチマークを繰り返しました。

 

このグラフから、同期操作のスループットが 8 スレッドまで上昇し、その後はほぼ一定になることがわかります。最大スループットは 1 分あたり約 8.9 件のトランザクションで、要求スレッドが 40 個のときでした。全体のスループットについては、すべての同時実行レベルで 1 分あたりのトランザクション件数が 0.8 件付近で推移しています。アセットのアップロードは約 20 分以内に終了しますが、ワークフローが完了するまでには 3 時間近くかかる点に注意してください。

  • 同期操作の最大スループット:1 時間あたり 537 件のトランザクション、つまり 1 時間あたり 10,700 個のアセット
  • 全体の最大スループット:1 時間あたり 53 件のトランザクション、つまり 1 時間あたり 1,070 個のアセット

次のグラフに、非同期ワークフローのキューの増加と最終的な処理の完了を時間の経過に沿って示します。

このグラフから、スレッド数の増加に伴って、キューが空になるまでの所要時間がわずかに長くなっていることがわかります。2 本の縦のマーカー線は、30 スレッドという代表的な実行について同期トランザクションの送信フェーズが完了した時点とバックグラウンドワークフロープロセスが完了した時点を示しています。

次のグラフに、このベンチマークにおけるワークフローイベント処理の統計を示します。

このグラフから、スレッド数が増えると、平均待機時間と平均処理時間が最初は増加しますが、後で一定になることがわかります。

システムリソースの傾向

次のグラフに、ベンチマークの各実行時に確認されたシステムリソースの使用率を示します。

ピーク CPU 使用率は、すべての実行について約 70 %です。CPU 使用率はボトルネックにはなりません。 ヒープ使用率は様々ですが、設定した 4,096 MB のヒープの 95 %を超えることはありません。

上のグラフは、SAN インターフェイスを介した最大データ転送速度を示したものです。IOZONE ベンチマークを使用して測定された EMC SAN サーバーへの最大データ転送速度は、約 40 MB/秒です。したがって、使用される要求スレッドが 8 個以上になると、このシナリオでは EMC SAN やストレージネットワークが完全に飽和状態になると結論付けることができます。

リポジトリの増加

バルク読み込みシナリオは、多数のアセットの追加に伴うリポジトリストレージの増加を測定するために使用されます。

  • アセットを 3,000 個アップロードすると、データストアは約 41 GB 増加します。データストアサイズの増加は、書き込まれるファイルの総数によって左右されるので、スレッド数によって変わることはありません。アップロードされるデータの合計サイズは 28 GB なので、データストアに必要なストレージは初期サイズの約 1.5 倍です。
  • アセットを 3,000 個アップロードすると、リポジトリディレクトリ(データストアを除く)は約 15 GB 増加しました。これは、リポジトリのサイズがアセットあたり約 5 MB 増加したことを示しています。このデータがアップロードされる階層はスレッド数によって決まるので、リポジトリディレクトリのサイズはスレッド数によって多少変化しますが、変動は全体で 200 MB 以下です。
  • ベンチマークが完了した後、リポジトリのサイズの最終的な増加量を測定するために、Tar PM の最適化を実行します。最適化時にリポジトリのサイズが 14 GB 小さくなったので、リポジトリサイズの純増加量は約 1 GB です。Tar PM の最適化の実行には 47 分かかりました。これは、アセットあたりのリポジトリサイズの純増加量が 0.3 MB になることを意味します。

アセットのアップロードに伴うリポジトリ増加のパターン

本来、アップロードされるデータに対してリポジトリフォルダーが線形に増加することはないので、連続的なアセットのアップロードに伴うリポジトリ増加のパターンを調べるために、別の作業をおこないました。データボリュームの節で定義したファイル形式の分布および構造と同じものを使用して、600 個から 3,000 個までアセットを連続的に増やしながら、クリーンなリポジトリにアップロードしました。ワークフロー処理が完了したら、リポジトリのサイズとデータストアのサイズを測定し、その後、Tar PM の最適化によってリポジトリを最適化しました。その後、リポジトリのサイズを測定して、最適化後の純増加量を確認しました。

次のグラフに、リポジトリとデータストアのサイズ増加の推移を示します。どちらの軸も対数軸であることに注意してください。

このグラフは、大規模な DAM の実装によるファイルシステムの使用率に関する重要な側面を示しています。

  • 必要なストレージはすべて、DAM に存在するコンテンツの量に比例しています。
  • 使用されているストレージのほとんどはデータストアの部分であり、特定のサイズしきい値を超えるものも含まれています。Tar PM の最適化は、このストレージには影響しません。
  • コンテンツの読み込み(およびワークフローによるレンダリング)の際には、リポジトリストレージが急激に増加しますが、Tar PM の最適化によって、その領域のほとんどが回収されます。

リポジトリに必要なストレージを見積もるときに留意すべき重要な点は、定常状態の容量のみを把握するのではなく、Tar PM の最適化を実行するまでの間に必要なすべてのストレージを考慮に入れるということです。通常、Tar PM の最適化は 24 時間に一度スケジュールされます。

このグラフから、リポジトリにアップロードされるアセットの数とタイプによってリポジトリサイズの増加と曲線の傾斜が異なることがわかります。さらに、DAM アプリケーションのデザインは、アセットについて作成されるレンディションに影響を及ぼします。このドキュメントで報告するシナリオが、すべての状況を代表するものであるとは限りません。

読み取り専用シナリオ

このシナリオは、検索および取得操作からなる、DAM の読み取り専用の使用パターンをシミュレートすることを目的としています。

実装の詳細

このシナリオの各スレッドでは、3 つの表示操作と 7 つの検索操作が実行されます。

表示

DAM ベンチマークのベースラインデータには、表示操作に使用される 15 個のファイルが含まれます。その内容は「データボリューム」の節に記載しています。

表示操作が view フォルダー内の 15 個のファイル(ファイル形式ごとに 5 個ずつ)に対して実行され、表示ベンチマークケースを実施するときに、各操作で 1 つのファイルがランダムに選択されます。

表示操作で取得されるファイルの内訳は、3 分の 1 が JPG、3 分の 1 が TIFF、3 分の 1 が MP4 です。

検索

次の 3 種類のクエリーがベンチマークに含まれます。

  • タイプ 1:フルテキスト検索 AND タグに基づく検索
  • タイプ 2:タグに基づく検索
  • タイプ 3:フルテキスト検索 AND タグに基づく検索 AND ファイル形式に基づく検索

各タイプの 5 つの異なるクエリーが記録され、その中からトランザクションごとにクエリーがランダムに選択されます。

検索基準は、何も見つからない検索、少数の結果が見つかる検索、多数の一致を返す検索のバランスを確保するように構成されています。すべての検索クエリーに、AND と初期ベースラインの 6,000 個のアセットに適用された一意のタグを含む AND 句が含まれています。これは、バルク読み込みベンチマークの一環として追加アセットがアップロードされたときも、検索クエリーの結果が同じになるようにするためです。

スループットの定義

このベンチマークの作業単位は、代表的な組み合わせの操作を実行する次のシナリオです。スループットは、1 秒間に完了したシナリオの件数で測定します。この組み合わせの操作に基づいて、1 秒あたりの検索件数または 1 秒あたりの表示件数でスループットを表すこともできます。

トランザクションの定義 説明
1 TIFF ファイルの表示
2 タイプ 1 の検索操作
3 タイプ 1 の検索操作
4 JPG の表示
5 タイプ 2 の検索操作
6 タイプ 2 の検索操作
7 MP4 ファイルの表示
8 タイプ 3 の検索操作
9 タイプ 3 の検索操作
10 3 つのタイプからランダムに選択された検索操作

この表示および検索シナリオには非同期操作やバックグラウンド操作は含まれないので、同期ワークロード実行に要した時間のみに基づいてスループットを測定できます。

最大スループットを達成するスレッド数の特定

このベンチマークにおけるスループットは、表示および読み取りシナリオを実行する同時スレッドの数によって変化します。最大スループットを達成した時点を特定するために、スレッド数を増やしながら、ベンチマークを繰り返しました。

このグラフによると、40 個前後のスレッドで最大スループットが確認されていますが、スレッドが 30 個を超えると、スループットはほぼ一定です。1 秒あたり 1.4 件のトランザクションというスループットが最大です。各トランザクションには、7 つの検索と 3 つの表示操作が含まれています。

システムのスループット能力は次のとおりでした。

  • 1 時間あたり 5,040 件のトランザクション
  • 1 時間あたり 15,100 件の表示
  • 1 時間あたり 35,300 件の検索

システムリソースの傾向

以下の各グラフに、ベンチマーク実行時における平均 CPU 使用率、ヒープ使用率および SAN インターフェイスを介した平均データ転送速度を示します。

これらのグラフは、重要なサーバーリソースの使用率がいずれも高くなかったことを示しています。SAN の使用率が低いのは、15 個という少数のファイルが表示操作に使用され、主にシステムキャッシュから提供されているからです。

これらのグラフから、純粋な読み取り操作ではシステムリソースが過度に使用されないことがわかります。このベンチマークにおける最終的なスループットの限界は、負荷生成ネットワークで使用可能なネットワーク帯域幅でした。1 秒あたり 1.4 件のシナリオという速度では、サーバーから 1 秒あたり約 100 MB の速度でコンテンツが返され、使用可能な 1 GBit イーサネットリンクが飽和状態になります。

通常負荷生成ネットワークとストレージネットワークの両方を介して負荷を提供するようにネットワークを再設定すると、スループットが 1.35 TPS から 2.2 TPS に向上しました。その結果、この設定を使用したシステムのスループット能力は次のようになりました。

  • 1 時間あたり 7,900 件のトランザクション
  • 1 時間あたり 23,800 件の表示
  • 1 時間あたり 55,400 件の検索

混合シナリオ

このシナリオの目的は、その他のシナリオの読み取りおよび書き込み操作を、DAM の日々の使用パターンをより的確に表す、バランスのとれたものに組み合わせることです。

実装の詳細

このシナリオの各スレッドでは、6 つの検索、3 つの表示および 1 つのアップロード操作が実行されます。シナリオの表示および検索部分は、前述の読み取り専用シナリオで記載した手順と同様です。

表示

DAM ベンチマークのベースラインデータには、表示操作に使用される 15 個のファイルが含まれます。その内容は、データボリュームの節に記載しています。表示操作で取得されるファイルの内訳は、3 分の 1 が JPG、3 分の 1 が TIFF、3 分の 1 が MP4 です。

検索

読み取り専用シナリオと同様に、検索のパフォーマンスを測定するために、3 つのタイプのクエリーと各タイプの 5 つのクエリーがランダムに選択されます。読み取り専用シナリオとは異なり、シナリオの手順のうち 6 つのみが検索です。

アップロード

各トランザクションには 1 つのアセットアップロード手順があり、1 つのアセットがアップロードおよびタグ付けされます。実行される操作は、前述のバッチアップロードおよびタグ付けシナリオでアップロードされたアセットについて記載したものと同様です。

アップロードされるアセットは、データボリュームの節に記載した個々のファイル形式の比率に従って選択されます。JPG が 75 %のトランザクション、TIFF が 20 %のトランザクション、MP4 が 5 %のトランザクションでアップロードされます。 

アップロードされたアセットのフォルダー構造内の分布は、バッチアップロードおよびタグ付けシナリオとは異なります。スレッドレベルのフォルダーを使用する代わりに、ベンチマークフォルダーにフォルダーが直接格納され、その各フォルダーが 300 個のアセットのターゲットとなります。次の図に、この混合シナリオのアセットの分布構造を示します。

スループットの定義

このベンチマークの作業単位は、代表的な組み合わせの操作を実行する次のシナリオです。バッチアップロードアクティビティと同様に、次の 2 つのタイプのスループットを測定します。

  • 同期操作のスループット。アップロードとタグ付けが完了するまでの所要時間を測定します。
  • 全体のスループット。非同期ワークフロー実行が完了するまでの所要時間も考慮されます。
トランザクションの定義 説明
1 アセットのアップロード
2 TIFF ファイルの表示
3 タイプ 1 の検索操作
4 タイプ 1 の検索操作
5 JPG の表示
6 タイプ 2 の検索操作
7 タイプ 2 の検索操作
8 MP4 ファイルの表示
9 タイプ 3 の検索操作
10 タイプ 3 の検索操作

このベンチマークシナリオでは、次の時点を完了と見なします。

  • アップロードおよびタグ付けの同期操作が終了したとき
  • Sling イベントで処理を待機している非同期ワークフローがなくなったとき

最大スループットを達成するスレッド数の特定

このベンチマークにおけるスループットは、サーバーに対して要求をおこなう同時スレッドの数によって変化します。最大スループットを達成した時点を特定するために、スレッド数を増やしながら、ベンチマークを繰り返しました。

このグラフから、同期操作のスループットが約 40 スレッドまで上昇し、その後はほぼ一定になることがわかります。最大スループットは 1 秒あたり約 1.2 件のトランザクションでした。ワークフロー完了のスループットは、0.3 トランザクション/秒付近で推移しています。

同期操作の最大スループットは次のとおりでした。

  • 1 時間あたり 4,360 件のトランザクション
  • 1 時間あたり 13,100 件の表示
  • 1 時間あたり 26,200 件の検索

全体の最大スループットは次のとおりでした。

  • 1 時間あたり 1,010 件のトランザクション、つまり 1 時間あたり 1,010 個のアセット

このシナリオでは、大量の読み取りおよび検索操作があるにもかかわらず、新しいアセットを受け入れ、レンディションを生成するサーバーの全体的な処理能力は 1 時間あたり 1,000 個をわずかに上回り、バッチアップロードシナリオで確認された速度とほぼ同じです。

次のグラフに、全体的なキューの増加を時間の経過に沿って示します。

ワークフロー完了のスループットはほぼ一定であり、トランザクションの件数もほとんど一定しているので、各実行における合計所要時間は同じです。上のグラフから、スレッド数によってキューの増加の傾向が異なることがわかります。2 本の縦のマーカー線は、30 スレッドでの実行を代表として、ベンチマークが完了した時点とワークフロープロセスが完了した時点を示しています。

次のグラフに、このベンチマークにおけるワークフローイベント処理の統計を示します。

上のグラフから、スレッド数が増えると、平均待機時間と平均処理時間が最初は増加しますが、後で一定になることがわかります。平均処理時間は、バッチアップロードシナリオで確認されたものと同様であることから、アセットのレンダリングの生成にかかる時間はほぼ同じであることがわかります。ただし、このシナリオでは、処理を待機しているアセットの全体数がバッチアップロードの場合よりも大幅に少ないので、キューにおける平均待機時間は短くなっています。

システムリソースの傾向

次のグラフに、ベンチマークの各実行時に確認されたシステムリソースの使用率を示します。

上のグラフは、様々なスレッド数でのベンチマーク実行時における平均 CPU 使用率およびヒープ使用率を示しています。ヒープ使用率は、スレッド数が 30 個になるまで多少上昇しますが、すべての実行において、4,096 MB のヒープの 55 %以下に維持されています。CPU 使用率は、すべての負荷レベルで約 45 %です。

上のグラフは、様々なスレッド数でのベンチマーク実行時における SAN インターフェイスを介した平均データ転送速度を示しています。アセットの挿入とワークフロータスクの処理でリポジトリストレージがより多く使用されるので、全体的な SAN トラフィックは、読み取り専用シナリオで確認されたものより大幅に多くなっています。

データボリュームの増加

このシナリオの目的は、追加の量のコンテンツがある場合に DAM のパフォーマンスがどのように変化するかを測定することです。

実装の詳細

このシナリオでは、ベースラインデータの負荷を 6,000 個のアセットから 24,000 個のアセットまで増やし、混合シナリオのトランザクション負荷を使用して、アセット数が増えたときのスループットに対する影響を測定します。

データは、アセットの数量に関係なく、ベンチマークケースの検索クエリーから同じ結果セットが返されるように調整されています。そのために、最初の 6,000 個の負荷のすべてのアセットに共通のタグでタグ付けした後、このタグを指定して各検索クエリーを AND で結合しました。このタグは、後で読み込まれたアセットには適用していません。

結果

以下のグラフに、リポジトリサイズの増加に伴うスループットの変化を示します。これらの各グラフから、6,000 個と 12,000 個のスループットを比較した場合、低下はごくわずかですが、24,000 個の場合は低下が顕著になることがわかります。同時スレッドの数が増えると、低下の幅が大きくなっています。

6,000 個と 12,000 個の場合、スループットの差異は 0 %から 7 %です。12,000 個と 24,000 個の場合、スループットの差異は 5 %から 20 %です。

全体のスループットは、すべてのリポジトリボリュームで常にほぼ同じです。スループットは、1 秒あたり約 0.28 個のアセット、つまり 1 時間あたり約 1,010 個のアセットです。

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

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