アセットパフォーマンス調整ガイド

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 を使用できます。クラウドベースの環境では、同等の高速ストレージタイプを使用できます。例えば、AmazonEC2では、一時フォルダーにEphemeralドライブドライブを使用できます。

サーバーに十分なメモリがあるという前提で、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 コンソールで設定します。https://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 または共有ファイルデータストアの実装は、ディスク領域の節約と大規模な実装におけるネットワークスループットの向上に役立ちます。共有データストアの使用の長所と短所について詳しくは、『アセットサイズ設定ガイド』を参照してください。

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=<a href="https://s3.amazonaws.com/">s3.amazonaws.com</a>
 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 Sizing Guide』を参照してください。 ネットワークトポロジを分析してネットワークのパフォーマンスを評価するには、Assets のネットワークに関する考慮事項を参照してください。

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

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

ワークフロー

一時的なワークフロー

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

メモ

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

  1. 設定するAEMインスタンスで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作成者で、http://localhost:4502/system/console/slingeventに移動します。
  2. 実装に関連する各ワークフローキュー(Granite の一時的なワークフローキューなど)で「編集」をクリックします。
  3. 並列ジョブの最大数の値を変更し、「保存」をクリックします。

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

オフロード

ビデオトランスコードなど、リソースを大量に消費する大量のワークフローまたはワークフローの場合は、DAM更新アセットワークフローを2番目の作成者インスタンスにオフロードすることがあります。 オフロードに関するよくある問題点は、ワークフローの処理のオフロードによって節約される負荷はすべて、インスタンス間で互いにコンテンツをレプリケートするコストによって相殺される点です。

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

DAM アセットの更新設定

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

メモ

DAM アセットの更新ワークフローを集中的に実行すると、ファイルデータストアのサイズが急激に増加する可能性があります。アドビが実施した実験の結果によると、8 時間以内に約 5,500 のワークフローを実行した場合、データストアのサイズが約 400 GB 増加する可能性があります。

これは一時的な増加であり、データストアのガベージコレクションタスクを実行すると、データストアは元のサイズに戻ります。

通常、データストアのガベージコレクションタスクは、スケジュールされた他のメンテナンスタスクと共に毎週実行されます。

ディスク領域が限られている場合に、DAM アセットの更新ワークフローを集中的に実行する際は、ガベージコレクションタスクの実行頻度を増やすことを検討してください。

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

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

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

別のアプローチは、Dynamic Mediaクラシック技術を使用して、画像操作を完全にやめることです。 さらに、AEMインフラストラクチャのレンディションの生成責任を引き継ぐだけでなく、公開層全体を引き継ぐBrand Portalを展開できます。

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?lang=ja"/>
  <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​ファイル(または環境変数MAGIC_TEMPORARY_PATHを設定)内のImageMagickの一時フォルダーのパスを、十分な容量とIOPSを持つディスクパーティションに設定します。

注意

使用可能なすべてのディスク領域を ImageMagick で使用する場合、設定を誤るとサーバーの動作が不安定になるおそれがあります。ImageMagick を使用して大きなファイルを処理するために必要なポリシー変更をおこなうと、AEM のパフォーマンスに影響する可能性があります。詳しくは、ImageMagick のインストールと設定を参照してください。

メモ

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

Adobe Managed Services(AMS)でAEMを使用している場合は、大量のPSDまたはPSBファイルを処理する予定の場合は、Adobeカスタマーケアにお問い合わせください。 30000 x 23000ピクセルを超える高解像度のPSBファイルは、Experience Managerで処理されない場合があります。

XMP の書き戻し

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

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

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

ワークフロー実行フラグがチェックされている場合、大量のメタデータを読み込むと、リソースを集中的に使用する 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、およびプリフェッチインデックスファイル​を有効にします。これらの値は、AEM 6.2以降のバージョンでは、デフォルトで有効になっています。

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

  1. CRXDe /crx/de/index.jsp を開き、管理者ユーザーとしてログインします。
  2. /oak:index/lucene を探します。
  3. 追加​excludedPaths​という名前の文字列[]プロパティ。値は「/var」、「/etc/workflow/instances」、「/etc/replication」です。
  4. /oak:index/damAssetLucene を探します。
  5. 追加​includedPaths​という名前の文字列[]プロパティで、1つの値「/content/dam」が含まれます
  6. 保存

(AEM 6.1 および 6.2 のみ)ntBaseLucene インデックスを更新して、アセットの削除および移動のパフォーマンスを向上させます。

  1. /oak:index/ntBaseLucene/indexRules/nt:base/properties を参照します。

  2. 追加​/oak:index/ntBaseLucene/indexRules/nt:base/properties​の下の2つのnt:unstructuredノード​slingResource​と​damResolvedPath

  3. ノード上で以下のプロパティを設定します(orderedプロパティと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を監視して、インデックス作成が完了したかどうかを確認します。

    インデックスの再インデックスが完了しました:[/oak:index/ntBaseLucene]

  7. CRXDe で /oak:index/ntBaseLucene ノードを更新すると reindex プロパティが false に戻るので、インデックス構築が完了したかどうかを確認することもできます。

  8. インデックス作成が完了したら、CRXDeに戻り、type​プロパティを無効に設定します

    • /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 トラフィックスニッファーに対応する.
  • サイズの大きなアセットのアップロードには有線接続を使用する.
  • 最適な JVM パラメーターを設定する.
  • ファイルシステムデータストアまたは S3 データストアを設定する.
  • サブアセットの生成を無効にします。 この機能が有効な場合、AEMワークフローは、複数ページのアセット内の各ページに対して個別のアセットを作成します。 これらの各ページは、追加のディスク領域を消費し、バージョン管理や追加のワークフロー処理が必要な個々のアセットです。 別々のページが必要ない場合は、サブアセットの生成とページ抽出のアクティビティを無効にします。
  • 一時的なワークフローを有効化する.
  • Granite のワークフローキューを調整して同時に実行されるジョブ数を制限する.
  • ImageMagick を設定してリソースの消費を制限する.
  • DAMアセットの更新ワークフローから不要な手順を削除します。
  • ワークフローとバージョンのパージを設定する.
  • Luceneインデックスの設定を最適化します。
  • 最新のサービスパックとホットフィックスでインデックスを最適化する。利用可能なインデックスのその他の最適化については、Adobeカスタマーケアにお問い合わせください。
  • guessTotalを使用して、クエリのパフォーマンスを最適化します。
  • ファイルの内容からファイルの種類を検出するようにAEMを設定する場合(AEM WebコンソールでDay CQ DAM MIME Type Serviceを設定する)、操作がリソースを大量に消費するため、ピークでない時間帯に多くのファイルを一括アップロードします。

このページ

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now