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

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

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

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

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

十分なRAMを確保し、IO飽和状態を回避
本番環境を任意の規模で実行する場合は、セグメント tar ファイルがオフラインのコンパクション（またはオンラインのコンパクション ピーク）の間に拡張されるのと同じ量のRAMをLinux環境にプロビジョニングする必要があります。 さらに、以下はIO飽和度を回避します。

• OS、データ、ロギングディスクの分離
• Noatimeを使用してデータディスクをマウントします。
• データディスク上の先読みバッファを32に設定します。
• 理想的には、データディスクでXFS over ext4を使用します。
• RedHatがVMで実行されている場合、エントロピープールが常に> 1 K ビットであることを確認します（必要に応じて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に移動します。
queue.maxparallelを、AEM インスタンスをホストするサーバーのCPU コアの50%を表す値に設定します。 例えば、8 CPU コアの場合、値を4に設定します。

Oak リポジトリの調整
まず、AEM 6 インスタンスに最新のOak バージョンがインストールされていることを確認します。 上記の推奨ホットフィックスページを確認してください。

Oak Query Engine/インデックスの最適化

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

  • 低速クエリの分析方法については、この記事を参照してください。
  • この記事に従って、検索対象のすべての検索プロパティのoak:index ノードの下にカスタムインデックスを作成します。
  • Lucene ベースのカスタムインデックスごとに、includedPaths （String）設定を設定して、特定のコンテンツパスのみにインデックスを適用するように制限します。 次に、インデックスに含まれるパスに対して、該当する検索を制限します。

• JVM パラメーター
  これらのJVM パラメーターをAEM開始スクリプトに追加して、大規模なクエリがシステムに過負荷になるのを防ぎます。 これらは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 インデックスが大きい場合など）の場合は、キャッシュサイズを増やします。 このキャッシュサイズは、外部のBlobStoreを使用する場合ではなく、MongoBlobStore （デフォルト）を使用する場合にのみ適用されます。

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

• ドキュメントのキャッシュ サイズ： 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で次のすべてのキャッシュ設定を設定し、様々な値を使用してテストを読み込んで、環境に最適な設定を確認します。 残りのキャッシュ率はドキュメントキャッシュに与えられることに注意してください。

    • cache=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では、これらのキャッシュ設定の動作が変更されました。 AEM 6.2とOak 1.4では、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​を設定します。

タール貯蔵の調整
マイクロカーネルは、メモリマップされたファイルを直接呼び出すことはありません。 ただし、JDKは、効率的な読み取りのためにメモリマッピングファイルを内部的に使用します。 特定のWindows 64 ビットのオペレーティングシステムでは、メモリマップされたファイルのクリーンアップに失敗し、すべてのネイティブ OS メモリを消費する可能性があります。 パフォーマンス関連のパッチ/ホットフィックスをmicrosoft （KB 2731284を参照）およびOracleからインストールしてください。

また、オペレーティングシステムの問題が解決されるまで、SegmentNodeStoreService.configに​ tarmk.mode=32 ​を追加して、メモリマップモードを無効にすることもできます。 無効化の欠点により、I/Oが集中的になります。 I/O ページロックの制限を上げてください。

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

Adobe Managed Services（AMS）ユーザー向けCloud Manager
Cloud Manager （AMS ユーザーのみ）では、ガイド付きパフォーマンステストと自動拡張を使用して、AEM デプロイメントを成功させることができます。