目的

ここでは、一般的なアセット調整の設定とアセットのパフォーマンスの最適化に役立つソリューションについて説明します。

アセットパフォーマンスの最適化

  • 多くの組織が採用しているファイアウォールは HTTP トラフィックを傍受し、その結果アップロードに悪影響を及ぼしてファイルを破壊することがあるので、HTTPS の有効化をお勧めします。
  • 大きなサイズをアップロードする場合、無線ではなく有線接続を選択します。
  • tika index を使用したバイナリファイルのフルテキスト検索を無効にします。
  • 以下の例について、最適な JVM パラメーター を設定し、Java 8 を使用します。

XX:+UseConcMarkSweepGC  = Enable Concurrent Mark Sweep (CMS) Collector-Doak.queryLimitInMemory=500000 -Doak.queryLimitReads=100000 -Dupdate.limit=250000 -Doak.fastQuerySize=true

  • Sling Job クエリの調整:大きなアセットの一括アップロードは、リソースを大幅に消費する可能性があります。デフォルトでは、ジョブキューあたりの同時スレッド数は、CPU コアの数と同じです。これにより、全体的なパフォーマンスに影響を与え、Java ヒープを大幅に消費する可能性があります。コア数の 50%未満にすることをお勧めします。この値を変更するには、http://host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration に移動して、queue.maxparallel を AEM インスタンスをホストするサーバーの CPU コア数の 50%の値に設定します(例:8 CPU コアの場合、値を 4 に設定します)。
  • CQBufferedImageCache のキャッシュサイズの調整:システムの最大ヒープ(-Xmx param)を 5 GB にして、Oak BlobCache を 1 GB に設定し、ドキュメントキャッシュを 2 GB に設定することを検討します。この場合、バッファーされたキャッシュは、最大 1.25 GB になり、予期しないスパイク用に 0.75 GB のメモリのみが残ります。最終的に、OutOfMemoryErrors で JVM が失敗します。この問題を解決するには、バッファーされた画像キャッシュに設定した最大サイズを減らします。大量のアセットを Adobe Experience Manager にアップロードする際には、OSGi Web コンソールでバッファーされたキャッシュサイズを調整します。http://host:port/system/console/configMgr/com.day.cq.dam.core.impl.cache.CQBufferedImageCache2 に移動します。プロパティ cq.dam.image.cache.max.memory をバイト単位で設定します。例えば、1073741824 は 1 GB です(1024 x 1024 x 1024 = 1 GB)。注意:AEM 6.1 SP1 以降では、このプロパティの設定に sling:osgiConfig ノードを使用している場合、必ずデータタイプを Long に設定してください。詳しくは、この記事を参照してください。
  • 使用できるヒープの割合に FileDataStore を使用する場合、cacheSizeInMB を調整します(保守的な値は、最大ヒープの 2%)。例えば、8 ギガバイトのヒープの場合:maxCachedBinarySize=1048576cacheSizeInMB=164 にします。最大 1 MB のサイズのファイルのみをキャッシュするように、maxCachedBinarySize が 1 MB(1048576)に設定されていることに注意してください。これをより小さい値に調整することは、意味のあることです。多数のバイナリを扱う場合、アドビでは、パフォーマンスを最大にするために、デフォルトのノードストアではなく、外部データストアを使用することをお勧めします。また、以下のパラメーターを調整することをお勧めします。

• maxCachedBinarySize=10485760

• cacheSizeInMB=4096

注意:cacheSizeInMB 設定は、高くしすぎると、Java プロセスのメモリ不足の原因となる可能性があります。例えば、最大ヒープサイズを 8 GB(-Xmx8g)に設定して、AEM とアプリケーションが 4 GB のヒープを組み合わせて使用することを期待する場合、cacheSizeInMB を 164 ではなく 82 に設定すると意味をなします。最大ヒープは 2 ~ 10% の範囲にするのが安全な設定です。ただし、メモリ使用率を監視しながら負荷をテストすることで、これらの設定の変更を検証することを強くお勧めします。

  • DAM アセットの更新ワークフローには、Scene7 PTIFF 生成および InDesign Server 統合などのタスク用に設定された完全な手順が含まれています。ただし、ほとんどのユーザーには、これらの手順のいくつかは必要ありません。アドビでは、DAM アセットの更新ワークフローモデルのカスタムコピーを作成して、不要な手順を削除することをお勧めします。この場合、DAM アセットの更新のランチャーを更新して、新しいモデルを示すようにします。
  • 一時的なワークフロー:高いインジェスト負荷を最適化するには、DAM 更新および XMP メタデータの書き戻しワークフローを一時的なワークフローに切り替えることをお勧めします。「一時的」なので、一時的なワークフローにある中間的な作業手順に関連するランタイムデータは、実行時には JCR に保持されません(もちろん、出力レンダリングは保持されます)。 これにより、ワークフロー処理時間を 10%削減し、リポジトリの増加を大幅に低減します。 パージするのに CRUD ワークフローは必要ありません。さらに、圧縮する TAR ファイルの数が削減されます。監査のためにビジネスでワークフローランタイムデータを保持/アーカイブする必要がある場合は、この機能を有効にしないでください。
  • 選択的なレンダリングの生成:アセット処理ワークフローに条件を追加することで、必要なレンダリングのみを生成し、よりコストのかかるレンダリングを選択したアセットにのみ生成できます。ワークフロー/DAM アセットの更新/サムネールを処理を選択します。
  • インスタンス間の共有データストア:S3 または Shared File Datastore を実装すると、ディスクスペースの節約に役立ち、大規模実装でネットワークスループットが向上します。ただし、そうしたデプロイメントを維持する追加のタスクが発生する可能性があります。しかし、これは、より優れたパフォーマンスのためには、好ましいトレードオフといえます。
  • メンテナンス:通常、ワークフローのパージを週単位で実行する必要があります。 ただし、広範囲のアセットのインジェストなど、リソースを消費する状況では、より頻繁に実行できます。

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

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