パフォーマンスガイドライン performance-guidelines

このページでは、AEMデプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。AEM を初めて使用する場合は、パフォーマンスガイドラインを読む前に、次のページを確認してください。

以下に AEM で使用できるデプロイメントオプションを示します(すべてのオプションを表示するにはスクロールしてください)。

AEM

製品

トポロジ
オペレーティングシステム
アプリケーションサーバー
JRE
セキュリティ
マイクロカーネル
データストア
インデックス作成
Web サーバー
ブラウザー
Experience Cloud
Sites
非 HA
Windows
CQSE
Oracle
LDAP
Tar
セグメント
プロパティ
Apache
Edge
ターゲット
Assets
パブリッシュ - HA
Solaris™
WebLogic
IBM®
SAML
MongoDB
File
Lucene
IIS
IE
Analytics
Communities
オーサー - CS
Red Hat®
WebSphere®
HP
OAuth
RDB/Oracle
S3/Azure
Solr
iPlanet
Firefox
Campaign
Forms
オーサー - オフロード
HP-UX
Tomcat
RDB/DB2
MongoDB
Chrome
Social
モバイル
オーサー - クラスター
IBM® AIX®
JBoss®
RDB/MySQL
RDBMS
Safari
対象読者
Multi-site
ASRP
SUSE®
RDB/SQLServer
Assets
コマース
MSRP
Apple OS
アクティベーション
Dynamic Media
JSRP
モバイル
Brand Portal
J2E
AoD
LiveFyre
スクリーン
Doc Security
Process Mgt
デスクトップアプリケーション
NOTE
パフォーマンスガイドラインは主に AEM Sites に適用されます。

パフォーマンスガイドラインを使用するタイミング when-to-use-the-performance-guidelines

パフォーマンスガイドラインは次の状況で使用します。

  • 初回のデプロイメント:AEM Sites または Assets の初めてのデプロイを計画する場合は、使用可能なオプションを理解しておくことが重要です。特に、マイクロカーネル、ノードストアおよびデータストアを設定する場合(デフォルト設定と比較)。例えば、TarMK のデータストアのデフォルト設定をファイルデータストアに変更する場合などです。
  • 新しいバージョンへのアップグレード:新しいバージョンにアップグレードする場合は、実行中の環境と比較してパフォーマンスの違いを理解することが重要です。例えば、AEM 6.1 から 6.2 へ、または AEM 6.0 CRX2 から 6.2 OAK にアップグレードする場合などです。
  • 応答時間が遅い:選択したノードストアアーキテクチャが要件を満たしていない場合は、他のトポロジオプションと比較してパフォーマンスの違いを理解することが重要です。例えば、MongoMK の代わりに TarMK をデプロイしたり、Amazon S3 または Microsoft® Azure データストアの代わりにファイルデータストアを使用したりする場合です。
  • オーサーの追加:推奨 TarMK トポロジがパフォーマンス要件を満たさず、オーサーノードのサイズ拡張が使用可能な最大容量に達した場合は、パフォーマンスの違いを理解する必要があります。その際、3 つ以上のオーサーノードで MongoMK を使用する場合と比較します。例えば、TarMK の代わりに MongoMK をデプロイする場合などです。
  • コンテンツの追加:推奨されるデータストアアーキテクチャが要件を満たしていない場合は、他のデータストアオプションと比較してパフォーマンスの違いを理解することが重要です。 例えば、ファイルデータストアの代わりに Amazon S3 または Microsoft® Azure データストアを使用する場合などです。

はじめに introduction

この章では、AEM のアーキテクチャと AEM の最も重要なコンポーネントの大まかな概要を説明します。また、開発ガイドラインを示し、TarMK および MongoMK ベンチマークテストで使用されるテストシナリオについて説明します。

AEM のプラットフォーム the-aem-platform

AEM のプラットフォームは、次のコンポーネントで構成されています。

chlimage_1

AEM のプラットフォームについて詳しくは、AEM とはを参照してください。

AEM のアーキテクチャ the-aem-architecture

AEM のデプロイメントに重要な 3 つのビルディングブロックがあります。オーサーインスタンス ​は、コンテンツ作成者、編集者、および承認者がコンテンツの作成およびレビューを行うために使用します。コンテンツが承認されると、パブリッシュインスタンス ​という名前の 2 番目のインスタンスタイプに公開され、エンドユーザーはここからコンテンツにアクセスします。3 番目のビルディングブロックは Dispatcher で、これはキャッシュおよび URL フィルタリングを処理するモジュールとして、web サーバーにインストールされます。AEM のアーキテクチャについて詳しくは、典型的なデプロイメントシナリオを参照してください。

chlimage_1-1

マイクロカーネル micro-kernels

マイクロカーネルは AEM で永続性マネージャーとして機能します。AEM で使用されるマイクロカーネルには、TarMK、MongoDB、リレーショナルデータベース(制限付きサポート)の 3 つのタイプがあります。インスタンスの目的と検討しているデプロイメントタイプによって、ニーズに合うマイクロカーネルを選択します。マイクロカーネルについて詳しくは、推奨されるデプロイメントのページを参照してください。

chlimage_1-2

ノードストア nodestore

AEM では、バイナリデータをコンテンツノードとは別に格納できます。バイナリデータの格納先は​ データストア ​と呼ばれます。一方、コンテンツノードおよびプロパティの格納先は​ ノードストア ​と呼ばれます。

NOTE
アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方について、顧客がデフォルトで使用する永続性技術として TarMK を推奨します。
CAUTION
リレーショナルデータベースマイクロカーネルは制限付きでサポートされます。このタイプのマイクロカーネルを使用する前に、アドビカスタマーケアにお問い合わせください。

chlimage_1-3

データストア data-store

多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトで多数のメディアアセットが必要な場合は、それらをファイルデータストアまたは Azure/S3 データストアに格納すると、MongoDB 内に直接格納する場合よりも迅速にアセットにアクセスできます。

使用可能な設定オプションについて詳しくは、ノードストアとデータストアの設定を参照してください。

NOTE
アドビでは、Adobe Managed Services を使用して Azure または Amazon Web Services(AWS)に AEM をデプロイするオプションを選択することをお勧めします。お客様は、これらのクラウドコンピューティング環境で AEM をデプロイおよび運用する経験とスキルを持つチームのメリットを享受できます。Adobe Managed Services に関するドキュメントを参照してください。
Adobe Managed Services の外部で Azure または AWS に AEM をデプロイする場合のレコメンデーションは、クラウドプロバイダーと直接共同作業することです。または、任意のクラウド環境での AEM のデプロイをサポートするアドビのパートナーと協力することもできます。選択したクラウドプロバイダーまたはパートナーは、アーキテクチャのサイズ仕様、設計、および実装を担当し、顧客独自のパフォーマンス、負荷、スケーラビリティおよびセキュリティの要件が満たされるように支援します。
​>技術要件ページも参照してください。

検索 search-features

この節では AEM で使用されるカスタムインデックスプロバイダーを示します。インデックス作成について詳しくは、Oak クエリとインデックス作成を参照してください。

NOTE
アドビでは、ほとんどのデプロイメントで Lucene Index を使用することを推奨します。Solr は、特殊で複雑なデプロイメントでスケーラビリティを確保するためにのみ使用してください。

chlimage_1-4

開発のガイドライン development-guidelines

AEM は​ パフォーマンスとスケーラビリティ ​を目標として開発してください。指針にすることができるベストプラクティスを次に示します。

DO

  • 表示、ロジック、およびコンテンツを分離する
  • 既存の AEM API(Sling など)およびツール(レプリケーションなど)を使用する
  • 実際のコンテンツのコンテキストで開発する
  • キャッシュ可能性が最適になるように開発する
  • 保存の回数を最小限に抑える(一時的なワークフローなどを使用)
  • すべての HTTP エンドポイントが RESTful であるようにする
  • JCR 監視の範囲を制限
  • 非同期スレッドに留意する

DON'T

  • できる場合は、JCR API を直接使用しないでください。

  • /libs を変更せず、オーバーレイを使用します。

  • 可能な限りクエリを使用しない

  • Java™コードで OSGi サービスを取得する際には Sling バインディングを使用せず、次のように使用します。

    • DS コンポーネントの @Reference
    • Sling Model の @Inject
    • Sightly Use クラスの sling.getService()
    • JSP の sling.getService()
    • ServiceTracker
    • OSGi サービスレジストリへの直接アクセス

AEM での開発について詳しくは、開発の基本を参照してください。その他のベストプラクティスについては、開発のベストプラクティスを参照してください。

ベンチマークのシナリオ benchmark-scenarios

NOTE
このページに表示されているすべてのベンチマークテストは、ラボ設定で行われています。

以下で説明するテストシナリオは、TarMK、MongoMk、および TarMK と MongoMk の章のベンチマークの節で使用されています。特定のベンチマークテストで使用されているシナリオを確認するには、技術仕様表のシナリオフィールドを参照してください。

単一製品シナリオ

AEM Assets:

  • ユーザーインタラクション:アセットを参照/アセットを検索/アセットをダウンロード/アセットメタデータを読み取り/アセットメタデータを更新/アセットをアップロード/アセットのアップロードワークフローを実行
  • 実行モード:同時ユーザー、ユーザーごとの単一インタラクション

混合製品シナリオ

AEM Sites + Assets:

  • Sites ユーザーのインタラクション:記事ページを読み取り/ページを読み取り/パラグラフの作成/パラグラフを編集/コンテンツページを作成/コンテンツページをアクティブ化/作成者検索
  • Assets ユーザーのインタラクション:アセットを参照/アセットを検索/アセットをダウンロード/アセットメタデータを読み取り/アセットメタデータを更新/アセットをアップロード/アセットのアップロードワークフローを実行
  • 実行モード:同時ユーザー、ユーザーごとの混合インタラクション

垂直方向のユースケースのシナリオ

メディア:

  • Read Article Page (27.4%), Read Page (10.9%), Create Session (2.6%), Activate Content Page (1.7%), Create Content Page (0.4%), Create Paragraph (4.3%), Edit Paragraph (0.9%), Image Component (0.9%), Browse Assets (20%), Read Asset Metadata (8.5%), Download Asset (4.2%), Search Asset (0.2%), Update Asset Metadata (2.4%), Upload Asset (1.2%), Browse Project (4.9%), Read Project (6.6%), Project Add Asset (1.2%), Project Add Site (1.2%), Create Project (0.1%), Author Search (0.4%)
  • 実行モード:同時ユーザー、ユーザーごとの混合インタラクション

TarMK tarmk

この章では、最小のアーキテクチャ要件および設定を指定した TarMK の一般的なパフォーマンスガイドラインを示します。さらに明確にするためにベンチマークテストも示します。

アドビでは、すべてのデプロイメントシナリオにおいて、AEM オーサーインスタンスとパブリッシュインスタンスの両方に対し TarMK をデフォルトの優先使用する技術とすることを顧客に推奨します。

TarMK について詳しくは、デプロイメントのシナリオおよび Tar ストレージを参照してください。

TarMK 最小アーキテクチャガイドライン tarmk-minimum-architecture-guidelines

NOTE
以下に示す最小アーキテクチャガイドラインは、実稼動環境および高トラフィックサイト向けです。これらのガイドラインは、AEM を実行するための最小仕様では​ ありません

TarMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始してください。

  • 1 つのオーサーインスタンス
  • 2 つのパブリッシュインスタンス
  • 2 つの Dispatcher

以下に AEM Sites および AEM Assets でのアーキテクチャガイドラインを示します。

NOTE
ファイルデータストアを共有する場合は、バイナリなしのレプリケーションを​ オン ​にする必要があります。

AEM Sites での Tar アーキテクチャガイドライン

chlimage_1-5

AEM Assets での Tar アーキテクチャガイドライン

chlimage_1-6

TarMK 設定ガイドライン tarmk-settings-guideline

パフォーマンスを高めるには、次に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください

設定
パラメーター
説明
Sling ジョブキュー
queue.maxparallel
CPU コア数の半分の値に設定します。
デフォルトでは、ジョブキューあたりの同時スレッド数は、CPU コア数と同じです。
Granite 一時ワークフローキュー
Max Parallel
CPU コア数の半分の値に設定します。
JVM パラメーター

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

500000

100000

250000

True

大規模なクエリによってシステムが過負荷になることを防ぐため、AEM の起動スクリプトにこれらの JVM パラメーターを追加します。
Lucene インデックス設定

CopyOnRead

CopyOnWrite

Prefetch Index Files

Enabled

Enabled

Enabled

利用可能なパラメーターについて詳しくは、このページを参照してください。
データストア = S3 データストア

maxCachedBinarySize

cacheSizeInMB

1048576(1 MB)以下

最大ヒープサイズの 2~10%

データストアの設定も参照してください。
DAM アセットの更新ワークフロー
Transient Workflow
チェック済み
このワークフローではアセットの更新を管理します.
DAM メタデータの書き戻し
Transient Workflow
チェック済み
このワークフローでは、元のバイナリへの XMP の書き戻しを管理し、JCR で最終変更日を設定します。

TarMK パフォーマンスベンチマーク tarmk-performance-benchmark

技術仕様 technical-specifications

以下の仕様に基づいてベンチマークテストが実行されました。

オーサーノード
サーバー
ベアメタルハードウェア(HP)
オペレーティングシステム
Red Hat® Linux®
CPU/コア
Intel® Xeon® CPU E5-2407 @2.40GHz、8 コア
RAM
32 GB
ディスク
磁気
Java™
Oracle JRE バージョン 8
JVM ヒープ
16 GB
製品
AEM 6.2
ノードストア
TarMK
データストア
ファイル DS
シナリオ
単一の製品:アセット/30 個の同時スレッド

パフォーマンスベンチマーク結果 performance-benchmark-results

NOTE
以下に示す数値は、ベースラインとして 1 に正規化されており、実際のスループットの数値ではありません。

chlimage_1-7 chlimage_1-8

MongoMK mongomk

TarMK よりも MongoMK 永続性バックエンドを選択する主な理由は、インスタンスを水平方向にスケールできることです。つまり、常に 2 つ以上のアクティブなオーサーインスタンスが動作しており、MongoDB が永続性ストレージシステムとして使用されます。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では、同時に実行されるすべてのオーサリングアクティビティをサポートできないからです。

TarMK について詳しくは、デプロイメントのシナリオおよび Mongo ストレージを参照してください。

MongoMK 最小アーキテクチャガイドライン mongomk-minimum-architecture-guidelines

MongoMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャを出発点にする必要があります。

  • 3 つのオーサーインスタンス
  • 2 つのパブリッシュインスタンス
  • 3 つの MongoDB インスタンス
  • 2 つの Dispatcher
NOTE
実稼動環境では、MongoDB は常に、プライマリと 2 つのセカンダリを持つレプリカセットとして使用されます。プライマリで読み取りと書き込みが行われ、セカンダリでは読み取りが行われることがあります。ストレージを利用できない場合、セカンダリの 1 つをアービターに置き換えることができますが、MongoDB レプリカセットは常に奇数のインスタンスで構成する必要があります。
NOTE
ファイルデータストアを共有する場合は、バイナリなしのレプリケーションを​ オン ​にする必要があります。

chlimage_1-9

MongoMK 設定ガイドライン mongomk-settings-guidelines

パフォーマンスを高めるには、次に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください

設定
パラメーター
値(デフォルト)
説明
Sling ジョブキュー
queue.maxparallel
CPU コア数の半分の値に設定します。
デフォルトでは、ジョブキューあたりの同時スレッド数は、CPU コア数と同じです。
Granite 一時ワークフローキュー
Max Parallel
CPU コア数の半分の値に設定します。
JVM パラメーター

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

Doak.mongo.maxQueryTimeMS

500000

100000

250000

True

60000

大規模なクエリによってシステムが過負荷になることを防ぐため、AEM の起動スクリプトにこれらの JVM パラメーターを追加します。
Lucene インデックス設定

CopyOnRead

CopyOnWrite

Prefetch Index Files

Enabled

Enabled

Enabled

使用可能なパラメーターについて詳しくは、このページを参照してください。
データストア = S3 データストア

maxCachedBinarySize

cacheSizeInMB

1048576(1 MB)以下

最大ヒープサイズの 2~10%

データストアの設定も参照してください。
DocumentNodeStoreService

cache

nodeCachePercentage

childrenCachePercentage

diffCachePercentage

docChildrenCachePercentage

prevDocCachePercentage

persistentCache

2048

35(25)

20(10)

30(5)

10(3)

4(4)

。/cache,size=2048,binary=0,-compact,-compress

キャッシュのデフォルトサイズは 256 MB に設定されています。

キャッシュの無効化の実行にかかる時間に影響します。

oak-observation

thread pool

length

最小および最大 = 20

50000

MongoMK パフォーマンスベンチマーク mongomk-performance-benchmark

技術仕様 technical-specifications-1

以下の仕様に基づいてベンチマークテストが実行されました。

オーサーノード
MongoDB ノード
サーバー
ベアメタルハードウェア(HP)
ベアメタルハードウェア(HP)
オペレーティングシステム
Red Hat® Linux®
Red Hat® Linux®
CPU/コア
Intel® Xeon® CPU E5-2407 @2.40GHz、8 コア
Intel® Xeon® CPU E5-2407 @2.40GHz、8 コア
RAM
32 GB
32 GB
ディスク
磁気 - 1,000 IOPS を超える
磁気 - 1,000 IOPS を超える
Java™
Oracle JRE バージョン 8
該当なし
JVM ヒープ
16 GB
該当なし
製品
AEM 6.2
MongoDB 3.2 WiredTiger
ノードストア
MongoMK
該当なし
データストア
ファイル DS
該当なし
シナリオ
単一の製品:アセット/30 個の同時スレッド
単一の製品:アセット/30 個の同時スレッド

パフォーマンスベンチマーク結果 performance-benchmark-results-1

NOTE
以下に示す数値は、ベースラインとして 1 に正規化されており、実際のスループットの数値ではありません。

chlimage_1-10 chlimage_1-11

TarMK と MongoMK tarmk-vs-mongomk

この 2 つのうちのどちらかを選択する際に考慮すべき基本ルールは、TarMK はパフォーマンス重視で設計されており、MongoMK はスケーラビリティ重視で使用されているということです。アドビでは、AEM オーサーインスタンスと AEM パブリッシュインスタンスの両方について、すべてのデプロイメントシナリオで顧客がデフォルトで使用する永続性技術として TarMK をお勧めします。

TarMK よりも MongoMK 永続性バックエンドを選択する主な理由は、インスタンスを水平方向にスケールできることです。つまり、常に 2 つ以上のアクティブなオーサーインスタンスが動作しており、MongoDB が永続性ストレージシステムとして使用されます。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では、同時に実行されるすべてのオーサリングアクティビティをサポートできないからです。

TarMK と MongoMK の比較について詳しくは、推奨されるデプロイメントを参照してください。

TarMK と MongoMk のガイドライン tarmk-vs-mongomk-guidelines

TarMK の利点

  • コンテンツ管理アプリケーション専用に設計されています。
  • 常にファイルの一貫性が保たれ、任意のファイルベースのバックアップツールを使用してファイルをバックアップできます。
  • フェイルオーバーメカニズムを備えています。詳しくは、コールドスタンバイを参照してください。
  • 運用上のオーバーヘッドを最小限に抑えながら、パフォーマンスと信頼性の高いデータストレージを提供します。
  • TCO(総保有コスト)を削減します。

MongoMK を選択する基準

  • 1 日に接続する名前付きユーザーの数:数千人以上
  • 同時ユーザーの数:数百人以上
  • 1 日に取り込むアセットのボリューム:数十万件以上
  • 1 日あたりのページ編集のボリューム:数十万件以上
  • 1 日あたりの検索件数:数万件以上

TarMK と MongoMK のベンチマーク比較 tarmk-vs-mongomk-benchmarks

NOTE
以下に示す数値はベースラインとして 1 に正規化されており、実際のスループット数値ではありません。

シナリオ 1 技術仕様 scenario-technical-specifications

OAK オーサーノード
MongoDB ノード
サーバー
ベアメタルハードウェア(HP)
ベアメタルハードウェア(HP)
オペレーティングシステム
Red Hat® Linux®
Red Hat® Linux®
CPU/コア
Intel(R) Xeon(R) CPU E5-2407 @2.40GHz、8 コア
Intel(R) Xeon(R) CPU E5-2407 @2.40GHz、8 コア
RAM
32 GB
32 GB
ディスク
磁気 - 1,000 IOPS を超える
磁気 - 1,000 IOPS を超える
Java™
Oracle JRE バージョン 8
該当なし
JVM ヒープ 16 GB
16 GB
該当なし
製品
AEM 6.2
MongoDB 3.2 WiredTiger
ノードストア
TarMK または MongoMK
該当なし
データストア
ファイル DS
該当なし
シナリオ
単一の製品:Assets/実行あたり 30 個の同時スレッド

シナリオ 1 パフォーマンスベンチマークの結果 scenario-performance-benchmark-results

chlimage_1-12

シナリオ 2 技術仕様 scenario-technical-specifications-1

NOTE
1 つの TarMK システムを使用した場合と同じ数のオーサーを MongoDB で有効にするには、2 つの AEM ノードを含むクラスターが必要です。4 ノードの MongoDB クラスターで処理できるオーサーの数は、1 つの TarMK インスタンスの 1.8 倍です。8 ノードの MongoDB クラスターで処理できるオーサーの数は、1 つの TarMK インスタンスの 2.3 倍です。
TarMK オーサーノード
MongoMK オーサーノード
MongoDB ノード
サーバー
AWS c3.8xlarge
AWS c3.8xlarge
AWS c3.8xlarge
オペレーティングシステム
Red Hat® Linux®
Red Hat® Linux®
Red Hat® Linux®
CPU/コア
32
32
32
RAM
60 GB
60 GB
60 GB
ディスク
SSD - 10k IOPS
SSD - 10k IOPS
SSD - 10k IOPS
Java™
Oracle JRE バージョン 8
Oracle JRE バージョン 8
該当なし
JVM ヒープ 16 GB
30 GB
30 GB
該当なし
製品
AEM 6.2
AEM 6.2
MongoDB 3.2 WiredTiger
ノードストア
TarMK
MongoMK
該当なし
データストア
ファイル DS
ファイル DS
該当なし
シナリオ
垂直方向の使用例:メディア/2000 の同時スレッド

シナリオ 2 パフォーマンスベンチマークの結果 scenario-performance-benchmark-results-1

chlimage_1-13

AEM Sites および AEM Assets のアーキテクチャスケーラビリティのガイドライン architecture-scalability-guidelines-for-aem-sites-and-assets

chlimage_1-14

パフォーマンスガイドラインの概要 summary-of-performance-guidelines

このページに示されているガイドラインの概要は次の通りです。

  • ファイルデータストアを使用する TarMK - 大部分の顧客に対する推奨アーキテクチャ:

    • 最小トポロジ:1 つのオーサーインスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher
    • ファイルデータストアを共有する場合は、バイナリレスレプリケーションを有効にします
  • ファイルデータストアを使用する MongoMK - オーサー層の水平方向のスケーラビリティのための推奨アーキテクチャ:

    • 最小トポロジ:3 つのオーサーインスタンス、3 つの MongoDB インスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher
    • ファイルデータストアを共有する場合は、バイナリレスレプリケーションを有効にします
  • ノードストア - ネットワーク接続ストレージ(NAS)ではなくローカルディスクに格納

  • Amazon S3 を使用する場合:

    • Amazon S3 データストアは、オーサー層とパブリッシュ層の間で共有されます
    • バイナリレスレプリケーションを有効にする必要があります
    • データストアのガベージコレクションを使用するには、最初にすべてのオーサーノードとパブリッシュノードで実行してから、オーサーノードでもう一度実行する必要があります
  • 標準提供のインデックスに加えて、カスタムインデックスを作成する必要があります - 最も一般的な検索に基づく

    • カスタムインデックスには Lucene インデックスを使用する必要があります
  • ワークフローをカスタマイズすると、パフォーマンスを大幅に改善できます - 「アセットを更新」ワークフローのビデオ手順を削除したり、使用されていないリスナーを無効化したりします。

詳しくは、推奨されるデプロイメントのページも参照してください。

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2