現在表示中:

Adobe Experience Manager(AEM)Assets のセットアップには、数多くのハードウェア、ソフトウェアおよびネットワークコンポーネントが含まれています。導入のシナリオによっては、パフォーマンス上のボトルネックを排除するために、ハードウェア、ソフトウェアおよびネットワークコンポーネントに対して特殊な設定変更が必要になる場合があります。

また、特定のハードウェアおよびソフトウェアを最適化するガイドラインを識別してそれに従うことで優良な基盤を構築し、AEM Assets の導入によりパフォーマンス、スケーラビリティおよび信頼性の面で期待通りの結果を得られます。   

AEM Assets のパフォーマンスが低下すると、インタラクティブパフォーマンス、アセット処理、ダウンロード速度などの領域におけるユーザーエクスペリエンスに影響します。 

パフォーマンスの最適化は、すべてのプロジェクトでターゲット指標を確立する前に実行する、基本的なタスクです。

ユーザーに影響を及ぼす前にパフォーマンス上の問題を検出して修正する必要がある主な領域は次の通りです。

プラットフォーム

AEM は数々のプラットフォームでサポートされていますが、Linux や Windows ではパフォーマンスを最適化し実装を簡単にする優れたネイティブツールがサポートされています。AEM Assets のデプロイメントでは、高いメモリ要件を満たすために 64 ビットのオペレーティングシステムを採用するのが理想です。あらゆる AEM のデプロイメントにおいて、可能である場合は TarMK を実装してください。TarMK は単一のオーサーインスタンスを超えて拡張できませんが、パフォーマンスは MongoMK よりも優れています。TarMK オフロードインスタンスを追加すると、AEM Assets のデプロイメントのワークフローの処理能力を高めることができます。

Java の設定

Java バージョン

2015 年 4 月を最後に Oracle は Java 7 の更新プログラムのリリースを停止しているので、AEM Assets を Java 8 にデプロイすることをお勧めします。場合によってはパフォーマンスの改善が見られます。

JVM パラメーター

次の JVM パラメーターを設定してください。

  • -XX:+UseConcMarkSweepGC
  • -Doak.queryLimitInMemory=500000
  • -Doak.queryLimitReads=100000
  • -Dupdate.limit=250000
  • -Doak.fastQuerySize=true

データストアの設定

ファイルデータストアの設定

すべての AEM Assets のユーザーに、データストアをセグメントストアから分離することをお勧めします。また、maxCachedBinarySize パラメーターと cacheSizeInMB パラメーターを設定することでパフォーマンスを最大化するのに役立ちます。キャッシュに含めることができるように、maxCachedBinarySize を最小のファイルサイズに設定します。cacheSizeInMB 内でデータストアで使用するインメモリキャッシュのサイズを指定します。この値は合計ヒープサイズの 2 ~ 10 %に設定することをお勧めします。ただし、負荷テストやパフォーマンステストが理想的な設定を決定するのに役立ちます。

共有データストア

S3 または共有ファイルデータストアの実装は、ディスク領域の節約と大規模な実装におけるネットワークスループットの向上に役立ちます。共有データベースの使用に関するメリットとデメリットについて詳しくは、Assets サイジングガイドを参照してください。

S3 データストア

次の S3 データストアの設定(org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.cfg)は、アドビが 12.8 TB のバイナリラージオブジェクト(BLOB)を既存のファイルデータストアから顧客サイトの S3 データストアに抽出するのに役立ちました。

accessKey=<snip>
secretKey=<snip>
s3Bucket=<snip>
s3Region=us-standard
s3EndPoint=s3.amazonaws.com
connectionTimeout=120000
socketTimeout=120000
maxConnections=80
writeThreads=60
concurrentUploadsThreads=30
asyncUploadLimit=30
maxErrorRetry=1000
path=/opt/author/crx-quickstart/repository/datastore
s3RenameKeys=false
s3Encryption=SSE_S3
proactiveCaching=true
uploadRetries=1000
migrateFailuresCount=400

ネットワークの最適化

多くの企業には HTTP トラフィックをスニッフィングするファイアウォールがあり、ファイルのアップロードに干渉しファイルを破損するので、HTTPS を有効にすることをお勧めします。サイズの大きなファイルのアップロードについては、Wi-Fi ネットワークでは簡単に飽和する恐れがあるので、必ず有線でネットワークに接続してください。ネットワークのボトルネックを特定するガイドラインについては、Assets サイジングガイドを参照してください。 ネットワークトポロジを分析してネットワークのパフォーマンスを評価するには、Assets のネットワークに関する考慮事項を参照してください。

第一に、ネットワークの最適化戦略は使用できる帯域幅や、AEM インスタンスに対する負荷によって変わります。ファイアウォールやプロキシなどの一般的な設定オプションは、ネットワークのパフォーマンスの改善に役立ちます。留意点は次の通りです。

  • インスタンスタイプ(小、中、大)によって、AEM インスタンスに十分なネットワーク帯域幅があることを確認します。AEM が AWS にホストされている場合、帯域幅が適切に分散されていることが特に重要です。 
  • AEM インスタンスが AWS にホストされている場合、広い用途に対応するスケールポリシーがあると便利です。 高い負荷が予想される場合は、インスタンスのサイズを大きくします。負荷が標準的または低い場合は、インスタンスのサイズを小さくします。
  • HTTPS:ユーザーの多くはHTTP トラフィックをスニッフィングするファイアウォールを装備しており、ファイルのアップロード操作に干渉しファイルを破損することもあります。
  • サイズの大きなファイルのアップロード:必ず有線でネットワークに接続してください(Wi-Fi 接続は簡単に飽和する恐れがあります)。

ワークフロー

一時的なワークフロー

可能な限り、「DAM アセットの更新」ワークフローを「一時的」に設定します。この設定にすると、ワークフローが通常のトラッキングやアーカイブ処理をパススルーする必要がなくなるので、ワークフローの処理に必要なオーバーヘッドが大幅に削減されます。

  1. 設定される AEM インスタンスの /miscadmin に移動します(例:http://localhost:4502/miscadmin)

  2. ナビゲーションツリーで、ツールワークフローモデルdam と展開します。

  3. DAM アセットの更新」をダブルクリックします。

  4. フローティングツールパネルで、「ページ」タブに切り替えて「ページプロパティ...」をクリックします。

  5. 一時的なワークフロー」を選択し、「OK」をクリックします。

    注意:

    一部の機能は一時的なワークフローをサポートしません。AEM Assets のデプロイメントにこれらの機能が必要な場合は、一時的なワークフローを設定しないでください。

    一時的なワークフローを使用できない場合は、定期的にパージされるワークフローを実行してアーカイブされた「DAM アセットの更新」ワークフローを削除し、システムのパフォーマンスが低下しないようにします。 

    通常、パージワークフローは毎週実行する必要があります。ただし、大規模なアセットの取り込みが行われている間など、リソースが限られているシナリオではより頻繁に実行できます。

    ワークフローのパージを設定するには、OSGi コンソールで新しい Adobe Granite のワークフローのパージ設定を追加します。次に、ワークフローを週別メンテナンスウィンドウの一部としてスケジュールを設定します。 

    パージの実行時間が長すぎる場合、タイムアウトします。このため、ワークフローの数が多すぎることが原因でパージワークフローが終わらない状況を避けるために、パージジョブが確実に終わるようにする必要があります。 

    例えば、一時的でない多数のワークフロー(ワークフローのインスタンスノードを作成する)を実行した後に、ACS AEM Commons Workflow Remover をアドホックベースで実行できます。これにより、冗長および完了したワークフローのインスタンスが即座に削除されるので、Adobe Granite のワークフローのパージスケジューラーが実行されるのを待つ必要がありません。

並列ジョブの最大数

デフォルトでは、AEM は最大でサーバー上のプロセッサーと同じ数の並列ジョブを実行できます。この設定の問題点は、負荷が高い期間ではすべてのプロセッサーが「DAM アセットの更新」ワークフローに占有されるので、UI の応答が遅くなり、AEM がサーバーのパフォーマンスや安定性を保護するその他の処理を実行できなくなる点です。次の手順を実行して、この値をサーバーで使用できるプロセッサーの半分の値にすることをお勧めします。

  1. AEM Author で、http://localhost:4502/system/console/slingevent に移動します。

  2. 実装に関連する各ワークフローキュー(Granite の一時的なワークフローキューなど)で「編集」をクリックします。

  3. 並列ジョブの最大数の値を変更し、「保存」をクリックします。

まずは、キューを使用できるプロセッサーの半分に設定してください。ただし、場合によっては最大のスループットを得るためにこの値をお使いの環境に合わせて増減させる必要があります。一時的および一時的でないワークフローには別個のキューが用意されているほか、外部ワークフローなどその他の処理も存在します。プロセッサーの 50 %に設定された複数のキューが同時にアクティブになると、システムはすぐにオーバーロードします。頻繁に使用されるキューは、ユーザーの実装により大きく異なります。このため、サーバーの安定性を損なうことなく効率を最大化するには、これらを慎重に設定する必要がある場合があります。

オフロード

高いボリュームのワークフローやリソースの限られたワークフロー(ビデオのトランコーディングなど)では、「DAM アセットの更新」ワークフローを 2 番目のオーサーインスタンスにオフロードできます。オフロードに関するよくある問題点は、ワークフローの処理のオフロードによって節約される負荷はすべて、インスタンス間で互いにコンテンツをレプリケートするコストによって相殺される点です。

AEM 6.2 と AEM 6.1 の機能パックでは、バイナリなしのレプリケーションでオフロードを実行できます。このモデルでは、オーサーインスタンスが共通のデータストアを共有し、転送のレプリケーションを通じて互いにメタデータの送信のみをおこないます。このアプローチは共有ファイルデータストアに適していますが、S3 データストアでは問題が発生することがあります。背景でのスレッドの書き込みは遅延を誘発する恐れがあるので、オフロードジョブが開始する前にアセットがデータストアに書き込まれないこともあります。

DAM アセットの更新設定

「DAM アセットの更新」ワークフローには、Scene7 PTIFF の生成や InDesign サーバーの統合など、タスク向けに設定された一連の手順がすべて含まれています。ただし、大多数のユーザーにとってこれらの手順のうちのいくつかは不要です。アドビでは「DAM アセットの更新」ワークフローモデルのカスタムコピーを作成し、不要な手順はすべて削除することをお勧めします。この場合、DAM アセットの更新のランチャーを更新して新しいモデルを参照するようにします。

実行時のレンディションの生成

お客様は Web サイトやビジネスパートナーへの配布に様々なサイズや形式の画像を使用します。各レンディションによりリポジトリ内のアセットの足跡が増加するので、この機能は適切なタイミングで使用することをお勧めします。画像の処理と保存に必要なリソースを減らすために、これらの画像を取り込み中にではなく実行時にレンディションとして生成できます。 

多くの Sites のお客様はリクエストされた時点で画像のサイズを変更および切り抜く画像サーブレットを実装しています。これにより、パブリッシュインスタンスにさらに負荷がかけられます。ただし、これらの画像をキャッシュできる限り、問題を減らすことができます。

もう 1 つの方法では、Scene7 テクノロジーを使用して画像の操作をすべて引き渡します。また、Brand Portal(アセット共有に代わるもので Scene7 の機能を搭載)をデプロイすることも可能です。Brand Portal は、レンディションを生成する責務だけでなく、パブリッシュ層全体を AEM インフラストラクチャから受け継ぎます。

ImageMagick

「DAM アセットの更新」ワークフローを ImageMagick を使用してレンディションを生成するようにカスタマイズした場合、/etc/ImageMagick/ にある policy.xml ファイルを変更することをお勧めします。デフォルトでは、ImageMagick は OS ボリュームで使用できるディスク領域と空きメモリをすべて使用します。これらのリソースを制限するには、policy.xml の policymap セクション内で次のように設定を変更します。

<policymap>

  <!-- <policy domain="system" name="precision" value="6"/> -->

  <policy domain="resource" name="temporary-path" value="/ephemeral0/imagemagick_tmp"/>

  <policy domain="resource" name="memory" value="1000MiB"/>

  <policy domain="resource" name="map" value="1000MiB"/>

  <!-- <policy domain="resource" name="area" value="1gb"/> -->

  <policy domain="resource" name="disk" value="10000MiB"/>

  <!-- <policy domain="resource" name="file" value="768"/> -->

  <policy domain="resource" name="thread" value="1"/>

  <policy domain="resource" name="throttle" value="50"/>

  <!-- <policy domain="resource" name="time" value="3600"/> -->

</policymap>

さらに、configure.xml ファイルにある ImageMagick の一時フォルダーのパス(または環境変数 MAGIC_TEMPORARY_PATH)を、十分な空き領域と IOPS があるディスクパーティションに設定します。

サブアセットの生成とページの抽出

PDF からページを抽出するとき、AEM は元の PDF の各ページにつき別個の PDF ファイルを作成します。これらのページはそれ自体がアセットであり、追加のディスク領域を消費するほか、バージョン管理や追加のワークフロー処理を必要とします。別個のページを必要としない場合は、個々のページの抽出を無効化することで PDF の取り込みのオーバーヘッドを大幅に減らします。

InDesign や Acrobat など、ファイルのサブアセットを生成するとき、AEM はリポジトリでクエリを実行して取り込まれたファイルを構成するアセットが既にリポジトリにあるかどうかを判定し、それらにリンクさせます。アセットのサイズが大きなリポジトリでは、これらのクエリがかなりのリソースを消費し、アセットの取り込みに必要な時間が大幅に増加します。リポジトリにサブアセットがない場合、それらは抽出され、ページの抽出と同様に別個のアセットとして扱われます。結果として、PDF ファイルの個々のページの抽出に関連するオーバーヘッドと同様のものが発生します。この機能が必要でない場合は、この機能を無効化することをお勧めします。

XMP の書き戻し

XMP の書き戻しにより、AEM でメタデータが変更されたときは常に元のアセットが更新されます。これにより、次のような結果になります。

  • アセット自体が変更されます
  • アセットのバージョンが作成されます
  • 「DAM アセットの更新」がアセットに対して実行されます

リストに記載の結果は、大量のリソースを消費します。このため、この機能が必要でない場合、XMP の書き戻しを無効化することをお勧めします。

レプリケーション

Sites の実装などで、アセットを多数のパブリッシュインスタンスにレプリケートするときは、チェーンレプリケーションを使用することをお勧めします。この場合、オーサーインスタンスが単一のパブリッシュインスタンスにレプリケートし、そのパブリッシュインスタンスが代わりに他のパブリッシュインスタンスにレプリケートすることで、オーサーインスタンスを解放します。アセットの自動アクティベートはお勧めしません。ただし、必要な場合は、ワークフローの最後の手順(通常は「DAM アセットの更新」)で実行することをお勧めします。アセットの移行中にレプリケーションを実行するためのガイダンスについては、Assets 移行ガイドを参照してください。

検索インデックス

システムインデックスの更新が含まれている場合が多いので、最新のサービスパックやパフォーマンス関連のホットフィックスを実装してください。AEM のバージョン別に適用できるインデックスの最適化については、パフォーマンスチューニングヒント | 6.x を参照してください。

頻繁に実行するクエリにカスタムインデックスを作成します。詳しくは、スロークエリの分析手法(英語)カスタムインデックスの作成を参照してください。 クエリやインデックスについての追加のインサイトやベストプラクティスについては、クエリとインデックスに関するベストプラクティスを参照してください。

Lucene Index の設定

OSGi コンソールの設定マネージャーで LuceneIndexProviderService を設定し、AEM 6.2 より前のバージョンで CopyOnRead、CopyOnWrite および Prefetch Index Files を有効化します。これらの値は AEM 6.2 ではデフォルトで有効化されています。さらに、/var、/etc/workflow/instances および /etc/replication を /oak:index/lucene から実行します。

guessTotal

特に Asset Share の実装でサイズの大きな結果セットを生成するクエリを作成するときには、guessTotal パラメーターを使用してそれらの実行の際に大量のメモリが使用されるのを回避します。

WebDAV

AEM Desktop の使用

Assets Desktop App を使用するときは、マウントされたファイルシステムからファイルを直接編集しないでください。ファイルが保存されるたびに、サーバーにすべてを再アップロードする必要があります。非効率な WebDAV により、ファイルの転送が何回も繰り返される結果になる場合があります。さらに、複数のアプリで作業しているとき、一時ファイルがローカルのファイルシステムに作成されます。Desktop App はほとんどの一般的な一時ファイルを無視しますが、すべてのユースケースが予測できるわけではありません。この理由から、ファイルをファイルシステムの別の場所にコピーし、そこで作業して、完了したらファイルを AEM に戻すことをお勧めします。

AEM Desktop App のトラブルシューティングについて詳しくは、https://helpx.adobe.com/jp/experience-manager/kb/troubleshooting-companion-app.html を参照してください。

Windows

Windows 7 の場合、Internet Explorer の設定をいくつか変えると WebDAV のパフォーマンスが向上します。詳しくは、次の記事を参照してください。

既知の問題

サイズの大きなファイル

AEM では、サイズの大きなファイルに関連する既知の問題が主に 2 つあります。ファイルのサイズが 2 GB 以上に到達すると、コールドスタンバイの同期でメモリ不足のエラーが発生することがあります。場合によっては、スタンバイの同期が実行されなくなります。また、プライマリインスタンスのクラッシュを引き起こすこともあります。このシナリオは、コンテンツパッケージを含む、AEM 内の 2 GB を超えるすべてのファイルが該当します。

同様に、S3 共有データストアを使用している間にファイルのサイズが 2 GB に到達すると、キャッシュからファイルシステムにファイルが完全に保持されるまで、少し時間がかかることがあります。結果として、バイナリなしのレプリケーションを使用しているとき、レプリケーションが完了する前にバイナリデータが保持されていなかった可能性があります。この状況は、オフロードのシナリオなど、データの可用性が特に重要である場合に問題を引き起こす可能性があります。

パフォーマンスのテスト

すべての AEM のデプロイメントでボトルネックをすばやく特定し解決できるように、パフォーマンステストの体制を確立してください。留意点は次の通りです。

ネットワークのテスト

お客様からのネットワークのパフォーマンスに関するすべての懸念については、次のタスクを実行してください。

  • お客様のネットワーク内からネットワークのパフォーマンスをテストする
  • アドビのネットワーク内からネットワークのパフォーマンスをテストする
  • 別のアクセスポイントからネットワークのパフォーマンスをテストする
  • ネットワークのベンチマークツールを使用する
  • ディスパッチャーに対してテストする

AEM インスタンスのテスト

CPU を効率的に使用し、負荷を分割することで遅延を最小限に抑え、高いスループットを実現するには、AEM インスタンスのパフォーマンスを定期的に監視してください。具体的には、次のことを実行します。

  • AEM インスタンスに対して負荷テストを実行する
  • アップロードのパフォーマンスと UI の応答性を監視する

AEM Assets のパフォーマンスチェックリスト

  • HTTPS を有効化して企業の HTTP トラフィックスニッファーに対応する
  • サイズの大きなアセットのアップロードには有線接続を使用する
  • Java 8 にデプロイする
  • 最適な JVM パラメーターを設定する
  • ファイルシステムデータストアまたは S3 データストアを設定する
  • 一時的なワークフローを有効化する
  • Granite のワークフローキューを調整して同時に実行されるジョブ数を制限する
  • ImageMagick を設定してリソースの消費を制限する
  • 「DAM アセットの更新」ワークフローから不要な手順を削除する
  • ワークフローとバージョンのパージを設定する
  • 6.2 より前のバージョンの場合は Lucene Index の設定を最適化する
  • 最新のサービスパックとホットフィックスでインデックスを最適化する。 その他のインデックスの最適化方法については、アドビサポートに問い合わせてください。
  • guessTotal を使用してクエリのパフォーマンスを最適化する

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

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