現在表示中:

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

共有データストア

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(アセット共有に代わるもので 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 があるディスクパーティションに設定します。

注意:

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

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

アセットのアップロード中に、AEM のワークフローによって、PDF および Office ドキュメントのページごとに個別のアセットが作成されます。これらのページはそれ自体がアセットであり、追加のディスク領域を消費するほか、バージョン管理や追加のワークフロー処理を必要とします。個別のページが必要ない場合は、サブアセットの生成とページの抽出を無効にしてください。

サブアセットの生成を無効にするには、次の手順を実行します。

  1. /libs/cq/workflow/content/console.html に移動して、ワークフローコンソールツールを起動します。
  2. モデル」タブを選択します。
  3. DAM アセットの更新」ワークフローモデルをダブルクリックします。
  4. サブアセットの処理」ステップを「DAM アセットの更新」ワークフローモデルから削除します。
  5. 保存」をクリックします。

ページの抽出を無効にするには:

  1. /libs/cq/workflow/content/console.html に移動して、ワークフローコンソールツールを起動します。
  2. ランチャー」タブを選択します。
  3. DAM Word ドキュメントの解析」ワークフローモデルを起動するランチャーを選択します。
  4. 編集」をクリックします。
  5. 無効にする」を選択します。
  6. OK」をクリックします。
  7. DAM Word ドキュメントの解析」ワークフローモデルを使用する他のランチャーアイテムに対して手順 3 ~ 6 を繰り返します。

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 に設定します。
  8. /oak:index/slingResource
  9. /oak:index/damResolvedPath
  10. 9. 「すべて保存」をクリックします。

 

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

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

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

ダウンロード

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

ネットワークのテスト

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

  • お客様のネットワーク内からネットワークのパフォーマンスをテストする
  • アドビのネットワーク内からネットワークのパフォーマンスをテストする。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 の規約内容は適用されません。

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