現在表示中:

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

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

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

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

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

プラットフォーム

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

一時フォルダー

アセットのアップロード時間を短縮するには、Java 一時ディレクトリに高性能ストレージを使用します。Linux および Windows の場合は、RAM ドライブまたは SSD を使用できます。クラウドベースの環境では、同等の高速ストレージタイプを使用できます。例えば Amazon EC2 では、"ephemeral drive" ドライブを一時フォルダーに使用できます。

サーバーに十分なメモリがあるという前提で、RAM ドライブを設定します。Linux の場合、8GB RAM ドライブを作成するには、次のコマンドを実行します。

mkfs -q /dev/ram1 800000
mkdir -p /mnt/aem-tmp
mount /dev/ram1 /mnt/aem-tmp
df -H | grep aem-tmp

Windows OS の場合、サードパーティ製ドライバーを使用して RAM ドライブを作成するか、SSD などの高性能ストレージを使用する必要があります。

高性能一時ボリュームの準備ができたら、JVM パラメーター -Djava.io.tmpdir を設定します。例えば、AEM の bin/start スクリプト内の CQ_JVM_OPTS 変数の下に次の JVM パラメーターを追加できます。

-Djava.io.tmpdir=/mnt/aem-tmp

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 %に設定することをお勧めします。ただし、負荷テストやパフォーマンステストが理想的な設定を決定するのに役立ちます。

バッファーされる画像キャッシュの最大サイズの設定

多数のアセットを Adobe Experience Manager にアップロードするときは、メモリ消費の予期しないスパイクに対応するために、また OutOfMemoryErrors による JVM エラーを避けるために、バッファーされる画像キャッシュの最大サイズを減らしてください。例えば、最大ヒープ(-Xmx パラメーター)が 5 GB のシステムで、Oak BlobCache が 1 GB、文書キャッシュが 2 GB に設定されているとします。このときに、バッファーされるキャッシュが最大 1.25 GB のメモリを使用した場合、予期しないスパイクに使用できるメモリは 0.75 GB のみとなります。

バッファーされるキャッシュサイズは OSGi Web コンソールで設定します。http://host:port/system/console/configMgr/com.day.cq.dam.core.impl.cache.CQBufferedImageCache で、cq.dam.image.cache.max.memory プロパティをバイト単位で設定します。例えば、1073741824 は 1 GB です(1024 x 1024 x 1024 = 1 GB)。

AEM 6.1 SP1 以降で sling:osgiConfig ノードを使用してこのプロパティを設定する場合は、データタイプを必ず Long にします。詳しくは、CQBufferedImageCache がアセットのアップロード中にヒープを消費するを参照してください。

共有データストア

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

注意:

「DAM アセットの更新」ワークフローは、AEM 6.3 ではデフォルトで「一時的」に設定されます。この場合、以下の手順をスキップできます。

  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 もデプロイできます。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 があるディスクパーティションに設定します。

警告:

使用可能なすべてのディスク領域を ImageMagick で使用する場合、設定を誤るとサーバーの動作が不安定になるおそれがあります。

ImageMagick を使用して大きなファイルを処理するために必要なポリシー変更をおこなうと、AEM のパフォーマンスに影響する可能性があります。詳しくは、ImageMagick のインストールと設定を参照してください。

注意:

ImageMagick の policy.xml ファイルと configure.xml ファイルは、/etc/ImageMagick/ ではなく /usr/lib64/ImageMagick-*/config/ の下に含まれている場合があります。  設定ファイルの場所については、ImageMagick のドキュメントを参照してください。

注意:

Adobe Managed Services(AMS)で AEM を使用しており、大きな PSD ファイルまたは PSB ファイルを大量に処理する予定がある場合は、アドビサポートにお問い合わせください。

XMP の書き戻し

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

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

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

レプリケーション

Sites の実装などで、アセットを多数のパブリッシュインスタンスにレプリケートするときは、チェーンレプリケーションを使用することをお勧めします。この場合、オーサーインスタンスが単一のパブリッシュインスタンスにレプリケートし、そのパブリッシュインスタンスが代わりに他のパブリッシュインスタンスにレプリケートすることで、オーサーインスタンスを解放します。

チェーンレプリケーションの設定

  1.  レプリケーションのチェーン先に使用するパブリッシュインスタンスを選択します。
  2. そのパブリッシュインスタンスで、他のパブリッシュインスタンスを指すレプリケーションエージェントを追加します。
  3. 追加した各レプリケーションエージェントで、「トリガー」タブの「受信時」を有効にします。

注意:

アセットの自動アクティベートはお勧めしません。ただし、必要な場合は、ワークフローの最後の手順(通常は「DAM アセットの更新」)で実行することをお勧めします。

検索インデックス

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

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

Lucene Index の設定

Oak インデックス設定を最適化して、AEM Assets のパフォーマンスを向上させることができる場合があります。

LuceneIndexProvider 設定を更新します。

  1. /system/console/configMgrorg.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService に移動します。
  2. AEM 6.2 より前のバージョンでは、"CopyOnRead"、"CopyOnWrite" および "Prefetch Index Files" を有効にします。これらの値は、AEM 6.2 以降ではデフォルトで有効になっています。

 

インデックス設定を更新してインデックス再構築時間を短縮します。

  1. CRXDe /crx/de/index.jsp を開き、管理者ユーザーとしてログインします。
  2. /oak:index/lucene を探します。
  3. 値 "/var"、"/etc/workflow/instances"、"/etc/replication" を持つ String[] 型のプロパティ "excludedPaths" を追加します。
  4. /oak:index/damAssetLucene を探します。
  5. 値 "/content/dam" を持つ String[] 型のプロパティ "includedPaths" を追加します。
  6. 保存します。
 
(AEM 6.1 および 6.2 のみ)ntBaseLucene インデックスを更新して、アセットの削除および移動のパフォーマンスを向上させます。
  1. /oak:index/ntBaseLucene/indexRules/nt:base/properties を探します。
  2. 2 つの nt:unstructured ノード "slingResource" と "damResolvedPath" を /oak:index/ntBaseLucene/indexRules/nt:base/properties の下に追加します。
  3. ノードに以下のプロパティを設定します(順序付けられていて、propertyIndex プロパティは Boolean 型です)。
    slingResource
       name="sling:resource"
       ordered=false
       propertyIndex= true
       type="String"
    damResolvedPath
       name="dam:resolvedPath"
       ordered=false
       propertyIndex=true
       type="String"
  4. /oak:index/ntBaseLucene ノードで、プロパティ reindex=true を設定します。
  5. 「すべて保存」をクリックします。
  6. error.log で次のメッセージを監視して、インデックス構築が完了したかどうかを確認します。
    Reindexing completed for indexes: [/oak:index/ntBaseLucene]
  7. CRXDe で /oak:index/ntBaseLucene ノードを更新すると reindex プロパティが false に戻るので、インデックス構築が完了したかどうかを確認することもできます。
  8. インデックスの構築が完了したら、CRXDe に戻り、次の 2 つのインデックスに対して "type" プロパティを disabled に設定します。
    • /oak:index/slingResource
    • /oak:index/damResolvedPath
  9. 「すべて保存」をクリックします。

 

Lucene テキスト抽出の無効化:

ユーザーがアセットのコンテンツを検索(PDF ドキュメントに含まれるテキストの検索など)できる必要がない場合は、この機能を無効にして、インデックスのパフォーマンスを向上させることができます。

  1. AEM パッケージマネージャー(/crx/packmgr/index.jsp)に移動します。
  2. 以下のパッケージをアップロードしてインストールします。

ダウンロード

guessTotal

大きな結果セットを生成するクエリを作成するときは、クエリ実行時のメモリ消費を抑えるために guessTotal パラメーターを使用してください。

既知の問題

サイズの大きなファイル

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

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

パフォーマンスのテスト

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

ネットワークのテスト

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

  • お客様のネットワーク内からネットワークのパフォーマンスをテストする
  • アドビのネットワーク内からネットワークのパフォーマンスをテストする。AMS ユーザーの場合、CSE を使用してアドビのネットワーク内からテストしてください。
  • 別のアクセスポイントからネットワークのパフォーマンスをテストする
  • ネットワークのベンチマークツールを使用する
  • ディスパッチャーに対してテストする

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 の規約内容は適用されません。

リーガルノーティス   |   プライバシーポリシー