AEM 6.x | パフォーマンスチューニングのヒント

オーサーインスタンスとパブリッシュインスタンスの両方で、現実的なシナリオをシミュレートする負荷テストを実装し、実行します。 期待される負荷を調査して定義することは、このプロセスの重要な手順です。 この手順は、AEM アプリケーション、アーキテクチャおよびAEMのインストールが実稼動環境で稼動した後に適切に動作するかどうかを示すのに役立ちます。
この演習の結果は、設定の誤り、アプリケーションの問題、サイジング、ハードウェアの問題、またはシステムのパフォーマンスに影響を与えるその他の問題があるかどうかを判断するのに役立ちます。 パフォーマンスガイドラインおよび 監視ガイドラインも参照してください。

負荷テストに加えて、ストレステストは、システムが処理できる最大負荷を定義するのに役立ちます。 このテストは、トラフィックスパイクに対する準備に役立ちます。 パフォーマンステストについて詳しくは、 こちらを参照してください。

推奨されるAEM サービスパック、累積修正パックおよびホットフィックスをインストールします。Adobe Experience Manager リリースのアップデート。

Windows Server を使用している場合は、 この記事を確認してください。

大量のアセット（画像、ビデオなど）をAEMに読み込む場合は、Assetsのベストプラクティスを必ず適用してください。

十分な RAM のプロビジョニングと I/O 飽和状態の回避
実稼動環境を任意の規模で実行する場合は、Linux 環境に十分な RAM をプロビジョニングしてください。セグメント tar ファイルのサイズが、オフライン圧縮（またはオンライン圧縮のピーク）の間で大きくなるためです。 また、以下のような対策により、I/O の飽和状態を回避することができます。

• OS、データ、およびログ・ディスクを分離
• Noatime でデータディスクをマウントします。
• データディスクの先読みバッファを 32 に設定します。
• 理想的には、データディスクで ext4 の上に XFS を使用します。
• RedHat が仮想マシンで実行されている場合は、エントロピープールが常に 1,000 ビット > あることを確認します（必要に応じて rngtools を使用します）。

Linux で Transparent Huge Pages を無効にする
AEMは詳細な読み取り/書き込みを実行しますが、Linux Transparent Huge Pages は大規模な操作用に最適化されているので、Mongo または Tar ストレージを使用する場合は Transparent Huge Pages を無効にするすることをお勧めします。

一時的なワークフローの有効化
一時的ワークフローは、次のワークフローに使用できます。

• 頻繁に実行される。
• ワークフロー履歴は必要ありません。

このような状況では、パフォーマンスが向上します。
このユースケースは、通常、大量のアセットの取り込みがある場合に当てはまります。
Assetsのパフォーマンスチューニングに記載されている手順に従います。

Sling ジョブキューの調整
大きなアセットのバルクアップロードは、通常、非常にリソースを消費するプロセスです。 デフォルトでは、ジョブキューあたりの同時スレッド数は、CPU コア数と同じです。 そのため、この値の設定は、全体的なパフォーマンスへの影響や高い Java ヒープ消費を引き起こす可能性があります。
Adobeでは、CPU コアの 50% を超えないようにすることをお勧めします。 この値を調整するには、https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfigurationに移動します。
AEM インスタンスをホストするサーバーの CPU コアの 50% を表す値に queue.maxparallel を設定します。 例えば、8 つの CPU コアの場合は、値を 4 に設定します。

Oak リポジトリのチューニング
まず、AEM 6 インスタンスに最新バージョンのOakがインストールされていることを確認します。 前述の推奨されるホットフィックスページを確認します。

Oak クエリエンジン/インデックスの最適化

• 頻繁に使用するすべての検索クエリに対してカスタム oak インデックスを作成します。

  • 処理に時間のかかるクエリの分析方法については、この 記事を参照してください。
  • 次の 記事に従って、検索に使用するすべての検索プロパティについて、oak:index ノードの下にカスタムインデックスを作成します。
  • カスタム Lucene ベースのインデックスごとに、includedPaths （文字列）設定を使用して、インデックスが特定のコンテンツパスにのみ適用されるように制限します。 次に、インデックスに含まれるパスに適用可能な検索を制限します。

• JVM パラメーター
  大規模なクエリによってシステムに過度の負荷がかかるのを防ぐため、AEMの起動スクリプトにこれらの JVM パラメーターを追加します。 これらはAEM 6.3 以降のデフォルト値であることに注意してください。

  • Doak.queryLimitInMemory=500000 （Oakのドキュメントも参照）
  • Doak.queryLimitReads=100000 （Oakのドキュメントも参照）
  • Dupdate.limit=250000 （DocumentNodeStore の場合のみ。例： MongoMK、RDBMK

  次のオプションを使用するとパフォーマンスは向上しますが、結果サイズ呼び出しの意味は変更されます。 特に、サイズの計算時には、使用されているインデックスの一部であるクエリ制限のみが考慮されます。
  さらに、ACL は結果に適用されないので、現在のセッションには表示されないノードは、返されるカウントに引き続き含まれます。 そのため、返されるカウントは実際の結果の数よりも大きくなる場合があり、正確なカウントは結果を繰り返し処理することによってのみ判断できます。

  • Doak.fastQuerySize=true （Oakのドキュメントの結果のサイズも参照）

  注意：fastQuerySize を有効にすると、クエリの応答が速くなります。 ただし、AEMが一部のクエリに対して不正確な結果数を返します。 アプリケーション内の正確な結果カウントに依存する場合は、fastQuerySize を使用しないでください。

• Lucene インデックス設定
  /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService を開き、

  • CopyOnRead を有効にする（AEM 6.2 以降のデフォルトで有効）
  • CopyOnWrite を有効にする（AEM 6.2 以降のデフォルトで有効）
  • インデックスファイルをプリフェッチ を有効にします（AEM 6.2 以降のデフォルトで有効）。

  使用可能なパラメーターについて詳しくは、https://jackrabbit.apache.org/oak/docs/query/lucene.html を参照してください
  一部のパスにはインデックスを作成する必要がないものがあるので、次の操作を実行できます。
  CRXDE Liteで、/oak:index/lucene に移動し、/var、/etc/workflow/instances、/etc/replication の値を持つ excludedPaths という複数値文字列プロパティ（String）を設定します。

• データストア
  AEM Assetsを使用している場合、またはバイナリファイルを幅広く使用するAEM アプリケーションがある場合、Adobeでは外部データストアを使用することをお勧めします。 外部データストアの使用は、最大のパフォーマンスを確保するのに役立ちます。 詳しい手順については、 ドキュメントを参照してください。
  FileDataStore を使用する場合は、cacheSizeInMB を使用可能なヒープのパーセンテージに調整します。 保守的な値は、最大ヒープの 2% です。 例えば、8 GB のヒープの場合：

  • maxCachedBinarySize=1048576
  • cacheSizeInMB=164

  maxCachedBinarySize は 1 MB （1048576）に設定されています。 そのため、キャッシュされるのは最大 1 MB のファイルのみです。 この設定を小さい値に調整しても意味がある場合があります。
  多数のバイナリを処理する場合は、パフォーマンスを最大化する必要があります。 そのため、Adobeでは、デフォルトのノードストアではなく、外部のデータストアを使用することをお勧めします。 また、Adobeでは次のパラメーターを調整することをお勧めします。

  • maxCachedBinarySize=10485760
  • cacheSizeInMB=4096

  メモ：cacheSizeInMB 設定が高すぎると、Java プロセスがメモリ不足になる可能性があります。 例えば、最大ヒープサイズが 8 GB （– Xmx8g）に設定されていて、AEMとアプリケーションが結合ヒープの 4 GB を使用することを想定している場合、cacheSizeInMB を 164 ではなく 82 に設定するのは理にかなっています。 最大ヒープの 2～10% の範囲は安全な設定です。 ただし、Adobeでは、メモリ使用率を監視しながら、負荷テストを実施して設定の変更を検証することをお勧めします。

Mongo ストレージのチューニング

• MongoBlobStore キャッシュサイズ： blobstore は、ラージバイナリオブジェクトの保存と読み取りに使用されます。 内部的には、キャッシュを持つストアが実装されており、バイナリを比較的小さなブロック（データまたはハッシュコードまたは間接ハッシュ）に分割して、各ブロックがメモリに収まるようにします。 デフォルト設定では、MongoBlobStore は 16 MB の固定キャッシュサイズを使用します。 より多くの RAM が使用可能で、BLOB ストレージが頻繁にアクセスされるデプロイメント（例えば、Lucene インデックスが大きい場合）では、キャッシュサイズを増やします。 このキャッシュサイズは、MongoBlobStore （デフォルト）を使用する場合にのみ適用され、外部 blobstore を使用する場合には適用されません。

  • DocumentNodeStoreService の blobCacheSize 設定を使用して、キャッシュサイズ（MB 単位）を設定できます。
    例：blobCacheSize=1024
  • AEM-MongoDB checklist も確認してください。

• ドキュメントキャッシュサイズ： MongoDB からのノード読み取りのパフォーマンスを最適化するには、DocumentNodeStore のキャッシュサイズを調整する必要があります。 キャッシュのデフォルトサイズは 256 MB に設定されています。これは、DocumentNodeStore で使用される様々なキャッシュに分散されます。 http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cacheを参照してください

  • DocumentNodeStoreService のキャッシュ設定を使用して、キャッシュサイズ（MB）を設定できます。 例えば、cache=2048 となります。

  • crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.configand load test に次のすべてのキャッシュ設定を設定し、様々な値を指定してテストを行い、お使いの環境に最適な設定を確認してください。 残りのキャッシュの割合は、文書キャッシュに指定されます。

    • キャッシュ=2048
    • nodeCachePercentage=35
    • childrenCachePercentage=20
    • diffCachePercentage=30
    • docChildrenCachePercentage=10

  • 上記の設定では、割合の合計は 95% です。 キャッシュの残りの 5% が documentCache に割り当てられます。 documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

  • キャッシュの割合を分散させる際は、documentCache に残っているキャッシュがあまり大きくないことを確認します。 つまり、最大 500 MB 以下に保ちます。大きな documentCache を使用すると、キャッシュの無効化の実行に要する時間が長くなる可能性があります。

• Oak 1.4.x を使用するAEM 6.2 のキャッシュ設定：

  • AEM 6.2 では、これらのキャッシュ設定の仕組みが変更されました。 Oak 1.4 を使用したAEM 6.2 では、新しいキャッシュ prevDocCache が使用されます。 このキャッシュは、設定 prevDocCachePercentage を使用して構成できます。 初期設定は 4 です。
  • documentCache は、残りのキャッシュ MB を使用します（キャッシュ設定から他のすべてのキャッシュのサイズを引いた値）。 documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache

• MongoDB 実稼働チェックリストを実装します。
  https://docs.mongodb.org/manual/administration/production-checklist/ - Mongo DB のサポートによると、多くの項目がパフォーマンスに大きな影響を与えます。 ご質問がある場合は、MongoDB サポートまで直接お問い合わせください。

• 読み取りパフォーマンス： 各AEM ノードの Mongo DB URL に次のクエリ文字列パラメーターを追加します。 ?readPreference=secondaryPreferred
  このパラメータは、セカンダリからの読み取りをシステムに指示します。これにより、読み取りパフォーマンスが向上します。

• oak-observation: のスレッドプールを増やします /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory を開きます。 名前を oak-observation に設定し、最小および最大プールサイズを 20 に設定します。

• 監視キューの長さを増やす： パラメーター oak.observation.queue-length=50000 を含む com.adobe.granite.repository.impl.SlingRepositoryManager.cfg という名前のファイルを作成します。 /crx—quickstart/install フォルダーの下に配置します。

• 長時間実行されるクエリを避ける：クエリが 1 分以上実行されないようにするには、JVM パラメーター -Doak.mongo.maxQueryTimeMS=60000 でシステムプロパティを設定します。

Tar ストレージのチューニング
マイクロカーネルは、メモリマップファイルを直接呼び出しません。 ただし、JDK は内部でメモリマップファイルを使用しているので、効率的に読み取ることができます。 特定の Windows 64 ビットオペレーティングシステムでは、メモリマップファイルのクリーンアップに失敗し、ネイティブ OS メモリをすべて使用する場合があります。 Microsoft のパフォーマンス関連のパッチ/ホットフィックス（KB 2731284 を参照）とOracleをインストールしてください。

別のオプションとして、オペレーティングシステムの問題が解決されるまで、SegmentNodeStoreService.config に tarmk.mode=32 を追加してメモリマップモードを無効にすることもできます。 ディセーブルの欠点は、I/O に負荷がかかることです。 必ず I/O ページのロック制限を上げてください。

TarMK リビジョンクリーンアップ（コンパクション）
AEM 6.3 以降、オンラインコンパクション（オンラインでのリビジョンクリーンアップとも呼ばれます）は、デフォルトで有効になっています。 詳しくは、 このページを参照してください。

AdobeManaged Services（AMS）ユーザー向けCloud Manager
Cloud Manager （AMS ユーザーのみ）を使用すると、ガイド付きのパフォーマンステストと自動スケーリングにより、AEMのデプロイメントを確実に成功させることができます。