注意:

Adobe Experience Manager 6.x バージョンのパフォーマンスの調整のヒントを参照しています。この記事は、バージョン 5.x の場合でも使用できます。

応答時間は編集および訪問者リクエストでは時間がかかる

応答時間は作成者がコンテンツを編集する場合に不十分であったり、Web サイトは訪問者リクエストに応答するのに時間がかかったりします。

原因

AEM のパフォーマンスの問題に影響する要因は次のとおりです。

  • 不適切なデザイン
  • アプリケーションコード
  • ディスク I / O 設定が正しくありません
  • メモリサイジング
  • ネットワーク帯域幅と待ち時間
  • AEM が、メモリ管理に問題がある一部の Windows 2008 あるいは 2012 バージョンにインストールされています
  • 後述するように工場出荷時の設定を変更すると、AEM のパフォーマンスが向上します。

パフォーマンスの問題の回避

これらが、ユーザーに影響を与える前に確実にパフォーマンスの問題を見つけ、修正する手順です。

  1. author と publish の両方のインスタンスで、実際的なシナリオをシミュレートする負荷テストを実装し、実行します。想定される負荷の調査と定義がこのプロセスの重要なステップです。このステップでは実稼働環境でライブになると、AEM アプリケーション、アーキテクチャ、および AEM インストールが正常に動作するかを実際に試すことができます。実際に試してみることで、設定ミス、アプリケーションの問題、サイジング、ハードウェアの問題、システムパフォーマンスに影響を与えるその他の問題の有無を特定できます。パフォーマンスに関するガイドライン監視に関するガイドラインも参照ください

    1. 負荷テストに加えて、ストレステストによりシステムが処理できる最大負荷を定義できます。このテストは、トラフィックスパイクの準備に役立ちます。パフォーマンステストの詳細は、ここで確認できます。
  2. 推奨される AEM サービスパック、累積修正パックおよびホットフィックスをインストールします。

    https://helpx.adobe.com/jp/experience-manager/aem-releases-updates.html

  3. Windows サーバーを使用している場合は、この記事を確認します。

  4. AEM への大量のアセット(画像、ビデオなど)の読み込みを計画している場合は、アセットのベストプラクティスを適用します。

  5. 十分な RAM をプロビジョニングし、IO 飽和を回避します

    任意のスケールでの実稼動の実行を意図している場合、Linux 環境では、tar ファイルがオフライン圧縮(またはオンライン圧縮ピーク)間で拡大するセグメントと同じ容量の RAM でプロビジョニングする必要があります。  さらに、次の操作で IO 飽和を回避します。

    • OS/Data/Logging ディスクの分割
    • noatime を使用したデータディスクのマウント
    • readahead buffers をデータディスク上でを < 32 に設定します。
    • 理想的には、データディスク上に xfs over ext4 を使用します。
    • VM で Red Hat を実行している場合には、エントロピープールが常に > 1K ビットであることを確認します(必要であれば rngtools を使用します)。
  6. Linux で Transparent Huge Pages を無効にする

    AEM モンゴまたは TAR ストレージを使用すると Linux の透明な領域のページには、大きな操作用に最適化されているので、透明に膨大なページを無効にすることをお勧めしますが、詳細な読み取り/書き込みを実行します。

注意:

この記事では、AEM 6.x、AEM/CQ 5.6.1 (またはそれ以前のバージョン)に対する AEM 6.x, のパフォーマンスのヒントについて適用しています。https://helpx.adobe.com/jp/experience-manager/kb/performancetuningtips.html を参照。

一時的なワークフローの有効化

高収集の読み込みを最適化するために、DAM 更新と XMP メタデータ書き戻しワークフローを一時的なワークフローに切り替えることをお勧めします。名前が示すとおり、一時的なワークフローの中間の作業手順に関連するランタイムデータは、実行時に JCR に保持されません(出力レンディションがコースに保持されている場合)。これにより、ワークフロー処理時間を 10%削減し、リポジトリの増加を大幅に低減します。パージする CRUD ワークフローは不要です。また、圧縮する TAR ファイルの数が減少します。監査のためにビジネスでワークフローランタイムデータを保持/アーカイブする必要がある場合は、この機能を有効にしないでください。

注意:

一時的なワークフローを有効にする場合は、次の点に注意してください。

  • 一時的なワークフローに、ワークフローイベントは生成されません。そのため、イベントに依存する機能や顧客は、一時的なワークフローを有効にする必要がありません。
  • 一時的なワークフローは、ワークフローのイベントに依存する、オフロードするワークフローをサポートしていません。
  • 一時的なワークフローでは、従来の CQ ワークフローのイベントをサポートしていません。CQEventDispatcher の互換レイヤーが機能しないためです。
  • 一時的なワークフローは、ワークフローの電子メール通知をサポートしていません。EmailNotificationService は、一時的なワークフローと一緒に動作しない CQEventDispatcher に基づいているためです。
  • 一時的なワークフローは、ワークフローの統計をサポートしていません。CQWorkflowStatisticsService は、一時的なワークフローと一緒に機能しない CQEventDispatcher に基づいているためです。

一時的なワークフローを使用できない場合は、ワークフローのパージを定期的に実行して、アーカイブされた DAM 更新アセットのワークフローを削除する必要があります。これにより、システムのパフォーマンスが維持されます。ワークフローのパージを設定するには、OSGi コンソールを経由して新しい Adobe Granite のワークフローのパージ設定を追加します。これを週別メンテナンスウィンドウの一部として設定し、予定に組み込みます。

注意:

DAM 更新ワークフローを一時的なワークフローに切り替えると、アセットブラウザーでアセットステータスの更新が無効になります。アッセトパフォーマンス調整ガイドも見直してください。

  1. 設定された AEM インスタンスの /miscadmin に移動します(例えば、http://<Server>:<Port>/miscadmin)。

  2. ナビゲーションツリーから、ツール > ワークフロー > モデル > DAM を展開します。

  3. DAM 更新アセットをダブルクリックします。

  4. フローティングツールパネルでは、ページタブに切り替え、ページプロバティをクリックしてください。

  5. チェックボックスの「一時的なワークフロー」を選択し、「OK」をクリックします。

Sling ジョブキューの調整。

大規模なアセットの一括アップロードは通常、非常にリソースをたくさん使うプロセスです。デフォルトでは、ジョブキューごとの同時スレッド数は CPU コア数と同じです。したがって、この値を設定すると、全体的なパフォーマンスが影響を受け、Java ヒープ消費量が高くなる可能性があります。

CPU コアが 50% を超えないことをお勧めします。この値を調整するには、次の操作を行います。

http://<host>:<port>/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration

AEM インスタンスをホストするサーバーの CPU コアの 50% を表す値に queue.maxparallel を設定します。例えば、8 CPU コアの場合は、値を 4 に設定します。

Oak リポジトリの調整

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

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

  1. 推奨インデックスをインストールします(AEM 6.0 のみ対象)

    Oak と QueryBuilder が最近改良されたことにより、確実にシステムが最適なパフォーマンスとなるように新しい Oak インデックスを定義する必要があります。Oak インデックス作成についての詳しい情報は、次を参照してください。Apache Jackrabbit Oak 関連ページ

    以下は、そのような新しいインデックス定義を含むサンプルパッケージです。AEM カスタマーケアへの要求に応じて利用できる統合済み AEM 6.0 インデックス定義パッケージ (NPR-6340) があります。

    * damLuceneProperty.zip
    DAM クラシックユーザーインターフェイスの検索パフォーマンスを向上させる推奨インデックス定義(2015 年 3 月 13 日に更新されています)

    * productsIndex.zip
    コンテンツファインダーによる製品検索を向上させる推奨インデックス定義

    注意:AEM 6.1 の場合、6.0 の統合されたインデックス定義は工場出荷時に使用できます(以下を除く)。rep:Token。この場合、次が必要です。

    • 値 rep:Token をノード /oak:index/ の declaringNodeTypes プロパティに追加します。ノードタイプと入力します。
    • 同じノードに対しては、インデックスプロパティの値を true に設定します。
    • Save をクリックして再インデックスします。
  2. すべての使用頻度が高い検索クエリに対して Create custom oak を作成する。

    • 低速なクエリーを分析する方法の情報は次を参照。article
    • カスタム索引の作成oak:index 検索するすべての検索プロパティのノードについては、この記事に従ってください。
    • カスタム Lucene ベースのインデックスごとに、特定のコンテンツパスにのみ適用するインデックスを制限するための includedPaths (String[]) 設定を設定します。次に、インデックスによって含まれるパスへの該当する検索を制限します。
  3. JVM パラメーター

    これらの JVM パラメーターを AEM 起動スクリプトに追加して、拡張クエリ―がシステムを過負荷にしないようにします。

    • -Doak.queryLimitInMemory=500000(Oak ドキュメントも参照してください)
    • -Doak.queryLimitReads=100000(Oak ドキュメントも参照してください)
    • -Dupdate.limit=250000 (DocumentNodeStore のみです。次に例を示します。MongoMK,RDBMK

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

  4. Lucene のインデックスの設定

    /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderServiceand を開きます

    • CopyOnRead(AEM 6.2 からデフォルトで有効)
      を有効にします
    • CopyOnWrite(AEM 6.2 からデフォルトで有効)
      を有効にします
    • Prefetch Index Files(AEM 6.2 からデフォルトで有効)を有効にします

    使用可能なパラメーターについてのさらに詳しい情報は、http://jackrabbit.apache.org/oak/docs/query/lucene.html を参照してください

    パスによってはインデックスを作成する必要がないため、次の操作を行うことができます。

    /oak:index/lucene へ移動し、複数値の文字列のプロパティである excludedPaths と名前のついた (String[]) を値 /var, /etc/workflow/instances, /etc/replication で設定します。

  5. データストア

    AEM アセットを使用する場合、またはバイナリファイルを多用する AEM アプリケーションがある場合は、外部での使用をお勧めしますデータストア。外部データストアを使用して最大限のパフォーマンスを確保できます。ドキュメント詳しい手順用

    FileDataStore を使用する場合は、cacheSizeInMB を使用可能なヒープの割合に調整します。保守的な値は、最大ヒープの 2% です。例えば、8GB ヒープの場合:

    maxCachedBinarySize=1048576
    cacheSizeInMB=164

    次の点に注意してください。maxCachedBinarySize は 1MB(1048576)になります。したがって、最大 1 MB のファイルだけをキャッシュします。この設定を小さい値に調整することもまた理にかなっているかもしれません。

    大量のバイナリを扱う場合は、パフォーマンスを最大化する必要があります。したがって、Adobe が推奨するのは外部のデータストアをデフォルトのノードストアの代わりに使用することです。また、以下のパラメーターを調整することをお勧めします。

    • maxCachedBinarySize=10485760
    • cacheSizeInMB=4096

注意:

cacheSizeInMB 設定を高く設定しすぎると Java プロセスではメモリ使用量が不足になることがあります。例えば、最大ヒープサイズを 8 GB(-Xmx8g)に設定し、AEM とアプリケーションが 4 GB の結合ヒープを利用すると、cacheSizeInMB は 164 の代わりに 82 に設定されることがわかります。最大ヒープは 2~10%の範囲にするのが安全な設定です。ただし、メモリ使用量を監視しながら読み込みのテストで設定の変更を検証することをお勧めします。

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

  1. MongoBlobStore のキャッシュサイズblobstoreは、大きなバイナリオブジェクトの保存と読み取りに使用します。内部的には、キャッシュ付きのストアが実装され、それはバイナリを分割します各ブロックがメモリに収まるように、比較的小さいブロック(データまたはハッシュコードまたは間接ハッシュ)の中の  デフォルトの設定では、MongoBlobStore により、16MB の固定のキャッシュのサイズが使用されます。  RAM がさらに使用可能で、Blob ストレージが頻繁にアクセスされるデプロイメントに対しては(例えば、Lucene インデックスが大きい場合)、キャッシュのサイズを増やします。このキャッシュのサイズは、MongoBlobStore(デフォルト)を使用する場合にのみ適用されます。外部のものを使用する場合は適用されませんblobstoreから無料でダウンロードできます。

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

    • キャッシュサイズ(MB)は、DocumentNodeStoreService でキャッシュ設定の方法によって設定できます。例えば、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 を使用すると、キャッシュの無効化の実行にかかる時間が増加することがあります。
  3. Oak 1.4.x を使用した AEM 6.2 のキャッシュ設定:

    • AEM 6.2 では、これらのキャッシュ設定の操作方法が変更されています。Oak 1.4 を使用した AEM 6.2 には、新しいキャッシュ:prevDocCache があります。  このキャッシュは、設定 prevDocCachePercentage を使用して設定できます。指定なしは 4 です。
    • cfinputdocumentCache 残りのキャッシュの MB(他のすべてのキャッシュのサイズを引いたキャッシュ設定):
        documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache - prevDocCache
  4. 複合インデックス(Oak 1.0.x を含む AEM 6.0 と Oak 1.2.x を含む AEM 6.1 のみ)

    • 背景に複合インデックスを作成します。可能であれば、休憩時間の間にこれを実行します。実行中は、AEM インスタンスを停止することをお勧めします。そうすると速く完了できます。次のコマンドを使用してください。
        nohup mongo localhost:27017/aem-author --eval "db.nodes.createIndex( {_modified:1, _id:1}, { background: true } )" &
    • JVM パラメーターに次の AEM の起動スクリプトを追加します。
        -Doak.mongo.disableIndexHint=true
  5. MongoDB サポートのその多くの項目に従って、MongoDB 製品チェックリスト
    http://docs.mongodb.org/manual/administration/production-checklist/ - を実装します。パフォーマンスに大きな影響を与えます。ご質問については、MongoDB サポートに直接お問い合わせください。

  6. パフォーマンスの読み取り:このクエリー文字列パラメーターを AEM ノードごとに Mongo DB URL に追加します:? readPreference=secondaryPreferred
    このパラメーターは、一部の追加された読み取りパフォーマンスを与えるセカンダリから読み取るようにシステムに指示します。

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

  8. 確認キューの長さの増加:パラメーター oak.observation.queue‐length=50000 を含む com.adobe.granite.repository.impl.SlingRepositoryManager.cfg という名前のファイルを作成します。これを /crx-­‐quickstart/install フォルダーの下に配置します。

  9. 長時間実行するクエリーの回避:JVM parameters : Doak.mongo.maxQueryTimeMS=60000 のシステムプロパティを設定し、1 分以上実行するクエリーを回避します。

Tar ストレージ

Micro kernels では、memory-mapped ファイルは直接呼び出されません。ただし、内部的には JDK は有効な読み上げのメモリにマップされたファイルが使用されます。Windows オペレーティングシステムの指定したメモリ 64 - bit でマップされたファイルが消去され、すべてのネイティブ OS のメモリを消費しないようにすることができます。必ず、次からパフォーマンスに関連するパッチ/ホットフィックスをインストールしてください。microsoft(参照 KB 2731284) および Oracle。

TarMK 圧縮

AEM 6.0, 6.1, 6.2 に対しては、以下の説明のとおりにオーク実行のツールを使用してオフラインで圧縮を使用します。http://docs.adobe.com/docs/en/aem/6-0/deploy/upgrade/microkernels-in-aem-6-0.html#Maintaining the Repository

AEM 6.3以降、圧縮オンライン(オンラインリビジョンクリーンアップとして既知)は、デフォルトで有効になっています。詳細は this page を参照。

次のステップ

AEM のパフォーマンスの問題に関する詳細について:

  1. - 潜在的なボトルネックを識別するために、AEM 環境を監視します

    - 一般的な重大な AEM の問題と関連の推奨を確認します

    - パフォーマンスのトラブルシューティングのベストプラクティスを活用します

  2. フォーラム AEM 6 のパフォーマンスの調整のヒントとコツで討論に参加します

  3. 正式なサポートを得ます

    1. 次のデータを収集します。
      1. プロファイラーの出力
      2. スレッドダンプ
      3. すべてのログファイル
    2. AEM カスタマーケアにお問い合わせください

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

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