Experience Manager Assetsセットアップには、多数のハードウェア、ソフトウェア、およびネットワークコンポーネントが含まれています。 導入のシナリオによっては、パフォーマンス上のボトルネックを排除するために、ハードウェア、ソフトウェアおよびネットワークコンポーネントに対して特殊な設定変更が必要になる場合があります。
さらに、特定のハードウェアおよびソフトウェアの最適化ガイドラインを特定し、遵守することで、Experience Manager Assets導入環境がパフォーマンス、拡張性、信頼性に関する期待に応える確実な基盤を構築できます。
Experience Manager Assetsのパフォーマンスが低いと、インタラクティブパフォーマンス、アセット処理、ダウンロード速度、その他の領域でのユーザーエクスペリエンスに影響を与える可能性があります。
パフォーマンスの最適化は、すべてのプロジェクトでターゲット指標を確立する前に実行する、基本的なタスクです。
ユーザーに影響を及ぼす前にパフォーマンス上の問題を検出して修正する必要がある主な領域は次のとおりです。
Experience Managerは数多くのプラットフォームでサポートされていますが、AdobeはLinuxとWindowsでネイティブツールの最大のサポートを見つけ、最適なパフォーマンスと実装の容易さに貢献しています。 Experience Manager Assets導入の高メモリ要件を満たす64ビットオペレーティングシステムを導入するのが理想的です。 Experience Manager導入の場合と同様に、可能な限りTarMKを実装する必要があります。 TarMK は単一のオーサーインスタンスを超えて拡張できませんが、パフォーマンスは MongoMK よりも優れています。TarMKオフロードインスタンスを追加して、Experience Manager Assets導入のワークフロー処理能力を高めることができます。
アセットのアップロード時間を改善するには、Javaの一時ディレクトリに高いパフォーマンスのストレージを使用します。 Linux および Windows の場合は、RAM ドライブまたは SSD を使用できます。クラウドベースの環境では、同等の高速ストレージタイプを使用できます。例えば、AmazonEC2では、Ephemeral Driveドライブを一時フォルダーに使用できます。
サーバーに十分なメモリがあるという前提で、RAM ドライブを設定します。Linux の場合、8GB RAM ドライブを作成するには、次のコマンドを実行します。
mkfs -q /dev/ram1 800000
mkdir -p /mnt/aem-tmp
mount /dev/ram1 /mnt/aem-tmp
df -H | grep aem-tmp
Windows OSでは、サードパーティ製のドライバを使用してRAMドライブを作成するか、SSDなどの高パフォーマンスストレージを使用します。
高パフォーマンスの一時ボリュームの準備が整ったら、JVMパラメーター-Djava.io.tmpdir
を設定します。 例えば、Experience Managerのbin/start
スクリプト内のCQ_JVM_OPTS
変数に次のJVMパラメーターを追加できます。
-Djava.io.tmpdir=/mnt/aem-tmp
Adobeでは、最適なパフォーマンスを得るために、Java 8にExperience Manager Assetsを導入することをお勧めします。
次のJVMパラメーターを設定します。
-XX:+UseConcMarkSweepGC
-Doak.queryLimitInMemory
=500000-Doak.queryLimitReads
=100000-Dupdate.limit
=250000-Doak.fastQuerySize
=trueすべてのExperience Manager Assetsユーザーには、データストアとセグメントストアを分けることをお勧めします。 また、maxCachedBinarySize
パラメーターと cacheSizeInMB
パラメーターを設定することでパフォーマンスを最大化するのに役立ちます。キャッシュに含めることができるように、maxCachedBinarySize
を最小のファイルサイズに設定します。cacheSizeInMB
内のデータストアで使用するインメモリキャッシュのサイズを指定します。この値は合計ヒープサイズの 2~10%に設定することをお勧めします。ただし、負荷テストやパフォーマンステストが理想的な設定を決定するのに役立ちます。
大量のアセットをAdobe Experience Managerにアップロードする場合、メモリ消費量が予期せぬ急増を生じさせ、OutOfMemoryErrorsでJVMが失敗するのを防ぐために、バッファされたイメージキャッシュの最大サイズを小さくします。 例えば、最大ヒープ(-Xmx
パラメーター)が 5 GB のシステムで、Oak BlobCache が 1 GB、文書キャッシュが 2 GB に設定されているとします。このときに、バッファーされるキャッシュが最大 1.25 GB のメモリを使用した場合、予期しないスパイクに使用できるメモリは 0.75 GB のみとなります。
バッファーされるキャッシュサイズは OSGi Web コンソールで設定します。https://host:port/system/console/configMgr/com.day.cq.dam.core.impl.cache.CQBufferedImageCache
で、プロパティ cq.dam.image.cache.max.memory
をバイト単位で指定します。例えば、1073741824 は 1 GB です(1024 x 1024 x 1024 = 1 GB)。
Experience Manager6.1 SP1から、sling:osgiConfig
ノードを使用してこのプロパティを設定する場合は、データタイプをLongに設定する必要があります。 詳しくは、CQBufferedImageCache がアセットのアップロード中にヒープを消費するを参照してください。
S3 または共有ファイルデータストアの実装は、ディスク領域の節約と大規模な実装におけるネットワークスループットの向上に役立ちます。共有データストアの使用の長所と短所について詳しくは、アセットサイズ変更ガイドを参照してください。
次の S3 データストアの設定(org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.cfg
)は、アドビが 12.8 TB のバイナリラージオブジェクト(BLOB)を既存のファイルデータストアから顧客サイトの S3 データストアに抽出するのに役立ちました。
accessKey=<snip>
secretKey=<snip>
s3Bucket=<snip>
s3Region=us-standard
s3EndPoint=<a href="https://s3.amazonaws.com/">s3.amazonaws.com</a>
connectionTimeout=120000
socketTimeout=120000
maxConnections=80
writeThreads=60
concurrentUploadsThreads=30
asyncUploadLimit=30
maxErrorRetry=1000
path=/opt/author/crx-quickstart/repository/datastore
s3RenameKeys=false
s3Encryption=SSE_S3
proactiveCaching=true
uploadRetries=1000
migrateFailuresCount=400
多くの企業には HTTP トラフィックをスニッフィングするファイアウォールがあり、ファイルのアップロードに干渉しファイルを破損するので、HTTPS を有効にすることをお勧めします。サイズの大きなファイルのアップロードについては、Wi-Fi ネットワークでは簡単に飽和するおそれがあるので、必ず有線でネットワークに接続してください。ネットワークのボトルネックの特定に関するガイドラインについては、アセットサイズ設定ガイドを参照してください。 ネットワークトポロジを分析してネットワークのパフォーマンスを評価する方法については、アセットネットワークに関する考慮事項を参照してください。
主に、ネットワーク最適化戦略は、使用可能な帯域幅の量とExperience Managerインスタンスの負荷に依存します。 ファイアウォールやプロキシなどの一般的な設定オプションは、ネットワークのパフォーマンスの改善に役立ちます。留意点は次のとおりです。
可能な場合は、DAM Update Assetワークフローを「一時的」に設定します。 この設定にすると、ワークフローが通常のトラッキングやアーカイブ処理をパススルーする必要がなくなるので、ワークフローの処理に必要なオーバーヘッドが大幅に削減されます。
https://[aem_server]:[port]/miscadmin
のExperience Managerデプロイメントの/miscadmin
に移動します。
ツール/ワークフロー/モデル/damを展開します。
DAM Update Assetを開きます。 フローティングツールパネルで、「ページ」タブに切り替えて「ページプロパティ」をクリックします。
「一時的なワークフロー」を選択し、「OK」をクリックします。
一部の機能は一時的なワークフローをサポートしません。Assetsデプロイメントでこれらの機能が必要な場合は、一過性のワークフローを設定しないでください。
一過性のワークフローを使用できない場合は、定期的にワークフローの削除を実行して、アーカイブされたDAM Update Assetワークフローを削除し、システムのパフォーマンスが低下しないようにします。
通常、パージワークフローは週単位で実行します。 ただし、大規模なアセット取り込みの際など、リソースを大量に消費するシナリオでは、より頻繁にアセットを実行できます。
ワークフローのパージを設定するには、OSGi コンソールで新しい Adobe Granite のワークフローのパージ設定を追加します。次に、ワークフローを週次メンテナンスウィンドウの一部としてスケジュールを設定します。
パージの実行時間が長すぎる場合、タイムアウトします。このため、ワークフローの数が多すぎることが原因でパージワークフローが終わらない状況を避けるために、パージジョブが確実に終わるようにする必要があります。
例えば、多数の非一過性ワークフロー(ワークフローインスタンスノードを作成)を実行した後、ACS AEM Commons Workflow Removerをアドホックに実行できます。 これにより、冗長および完了したワークフローのインスタンスが即座に削除されるので、Adobe Granite のワークフローのパージスケジューラーが実行されるのを待つ必要がありません。
デフォルトでは、Experience Managerは、サーバー上のプロセッサ数と同じ数の並列ジョブを実行します。 この設定の問題は、負荷が大きい時間帯に、すべてのプロセッサーがDAM Update Assetワークフローに占有され、UIの応答性が低下し、Experience Managerがサーバーのパフォーマンスと安定性を保護する他のプロセスを実行できないことです。 次の手順を実行して、この値をサーバーで使用できるプロセッサーの半分の値にすることをお勧めします。
Experience Manager作成者でhttps://[aem_server]:[port]/system/console/slingevent
にアクセスします。
Granite Transient Workflow Queueのように、実装に関連する各ワークフローキューで「編集」をクリックします。
Maximum Parallel Jobsの値を更新し、Saveをクリックします。
まずは、キューを使用できるプロセッサーの半分に設定してください。ただし、場合によっては最大のスループットを得るためにこの値をお使いの環境に合わせて増減させる必要があります。一時的および一時的でないワークフローには別個のキューが用意されているほか、外部ワークフローなどその他の処理も存在します。プロセッサーの 50%に設定された複数のキューが同時にアクティブになると、システムはすぐにオーバーロードします。頻繁に使用されるキューは、ユーザーの実装により大きく異なります。このため、サーバーの安定性を損なうことなく効率を最大化するには、これらを慎重に設定する必要が生じる場合があります。
DAM Update Assetワークフローには、Dynamic MediaPTIFFの生成やAdobe InDesign Server統合など、タスク用に構成されたすべての手順が含まれています。 ただし、大多数のユーザーにとってこれらの手順のうちのいくつかは不要です。Adobeでは、DAM Update Assetワークフローモデルのカスタムコピーを作成し、不要な手順を削除することをお勧めします。 この場合、DAM Update Assetのランチャーを更新して、新しいモデルを指定します。
DAM Update Assetワークフローを大幅に実行すると、ファイルデータストアのサイズを大幅に拡大できます。 アドビが実施した実験の結果によると、8 時間以内に約 5,500 のワークフローを実行した場合、データストアのサイズが約 400 GB 増加する可能性があります。
これは一時的な増加であり、データストアのガベージコレクションタスクを実行すると、データストアは元のサイズに戻ります。
通常、データストアのガベージコレクションタスクは、スケジュールされた他のメンテナンスタスクと共に毎週実行されます。
ディスク領域が限られていて、DAM Update Assetワークフローを集中的に実行する場合は、ガベージコレクションタスクのスケジュールをより頻繁に設定することを検討してください。
お客様は Web サイトやビジネスパートナーへの配布に様々なサイズや形式の画像を使用します。各レンディションによりリポジトリ内のアセットの足跡が増加するので、この機能は適切なタイミングで使用することをお勧めします。画像の処理と保存に必要なリソースを減らすために、これらの画像を取り込み中にではなく実行時にレンディションとして生成できます。
多くの Sites のお客様はリクエストされた時点で画像のサイズを変更および切り抜く画像サーブレットを実装しています。これにより、パブリッシュインスタンスにさらに負荷がかけられます。ただし、これらの画像をキャッシュできる限り、問題を減らすことができます。
別のアプローチは、Dynamic Mediaの技術を使って完全な画像操作を手渡すことです。 さらに、Experience Managerインフラストラクチャのレンディション生成の責任を引き継ぐだけでなく、公開層全体を引き継ぐBrand Portalを展開できます。
DAM Update AssetワークフローをカスタマイズしてImageMagickを使用したレンディションを生成する場合、Adobeでは/etc/ImageMagick/
のpolicy.xml
ファイルを変更することを推奨します。 デフォルトでは、ImageMagick は OS ボリュームで使用できるディスク領域と空きメモリをすべて使用します。policy.xml
のpolicymap
セクション内で次の設定変更を行い、これらのリソースを制限します。
<policymap>
<!-- <policy domain="system" name="precision" value="6"/> -->
<policy domain="resource" name="temporary-path" value="/ephemeral0/imagemagick_tmp"/>
<policy domain="resource" name="memory" value="1000MiB"/>
<policy domain="resource" name="map" value="1000MiB"/>
<!-- <policy domain="resource" name="area" value="1gb"/> -->
<policy domain="resource" name="disk" value="10000MiB"/>
<!-- <policy domain="resource" name="file" value="768"/> -->
<policy domain="resource" name="thread" value="1"/>
<policy domain="resource" name="throttle" value="50"/>
<!-- <policy domain="resource" name="time" value="3600"/> -->
</policymap>
さらに、configure.xml
ファイル内のImageMagickの一時フォルダーのパスを、十分な容量とIOPSを持つ環境パーティションに設定します(または、ディスク変数MAGIC_TEMPORARY_PATH
を設定します)。
使用可能なすべてのディスク領域を ImageMagick で使用する場合、設定を誤るとサーバーの動作が不安定になるおそれがあります。ImageMagickを使用して大きなファイルを処理するために必要なポリシーの変更は、Experience Managerのパフォーマンスに影響する場合があります。 詳しくは、ImageMagick のインストールと設定を参照してください。
ImageMagick policy.xml
ファイルとconfigure.xml
ファイルは、/etc/ImageMagick/
ではなく/usr/lib64/ImageMagick-*/config/
で入手できます。設定ファイルの場所については、ImageMagickドキュメントを参照してください。
Adobe Managed Services(AMS)でExperience Managerを使用している場合は、大量のPSDファイルまたはPSBファイルを処理する予定の場合は、Adobeカスタマーケアにお問い合わせください。 AMS導入のためのこれらのベストプラクティスを実装し、Adobe独自の形式に対して可能な限り最適なツールとモデルを選択するには、Adobeカスタマーケアの担当者にご相談ください。 Experience Manager は、30000 x 23000ピクセルを超える高解像度PSBファイルを処理できない場合があります。
XMPの書き戻しでは、メタデータがExperience Managerで変更されると元のアセットが更新され、次の結果になります。
上記の結果により、大量のリソースが消費されます。このため、この機能が必要でない場合は、XMP の書き戻しを無効化することをお勧めします。
ワークフロー実行フラグがチェックされている場合、大量のメタデータを読み込むと、リソースを集中的に使用する XMP 書き戻しアクティビティが発生するおそれがあります。このような読み込みは、他のユーザーのパフォーマンスに影響しないように、サーバー使用率が低いときに計画します。
Sites の実装などで、アセットを多数のパブリッシュインスタンスにレプリケートするときは、チェーンレプリケーションを使用することをお勧めします。この場合、オーサーインスタンスが単一のパブリッシュインスタンスにレプリケートし、そのパブリッシュインスタンスが代わりに他のパブリッシュインスタンスにレプリケートすることで、オーサーインスタンスを解放します。
アセットの自動アクティベートはお勧めしません。ただし、必要な場合は、ワークフローの最後の手順(通常は「DAM アセットの更新」)で実行することをお勧めします。
システムインデックスの更新が含まれている場合が多いので、最新のサービスパックやパフォーマンス関連のホットフィックスを実装してください。インデックスの最適化については、パフォーマンス調整のヒントを参照してください。
頻繁に実行するクエリにカスタムインデックスを作成します。詳しくは、スロークエリの分析手法(英語)とカスタムインデックスの作成を参照してください。クエリとインデックスのベストプラクティスに関するその他の洞察については、クエリとインデックスのベストプラクティスを参照してください。
Experience Manager Assetsのパフォーマンスを向上させるため、Oakインデックスの構成で最適化を行うことができます。 インデックス構成を更新して再インデックス作成時間を改善します。
/crx/de/index.jsp
を開き、管理ユーザーとしてログインします。/oak:index/lucene
を参照します。/var
、/etc/workflow/instances
、および/etc/replication
を持つString[]
プロパティexcludedPaths
。/oak:index/damAssetLucene
を参照します。 値追加/content/dam
のString[]
プロパティincludedPaths
。 変更を保存します。例えば、PDFドキュメント内のテキストを検索する場合など、アセットをフルテキスト検索する必要がない場合は、これを無効にします。 フルテキストインデックスを無効にすると、インデックスのパフォーマンスが向上します。 Apache Luceneテキスト抽出を無効にするには、次の手順に従います。
大きな結果セットを生成するクエリを作成するときは、クエリ実行時のメモリ消費を抑えるために guessTotal
パラメーターを使用してください。
Experience Managerには大きなファイルに関する2つの主な既知の問題があります。 ファイルのサイズが 2 GB 以上に到達すると、コールドスタンバイの同期でメモリ不足のエラーが発生することがあります。場合によっては、スタンバイの同期が実行されなくなります。また、プライマリインスタンスのクラッシュを引き起こすこともあります。このシナリオは、Experience Manager内の2 GBを超えるファイル(コンテンツパッケージを含む)に適用されます。
同様に、共有S3データストアを使用している間にファイルのサイズが2 GBに達した場合は、ファイルがキャッシュからファイルシステムに完全に保持されるまでに時間がかかる場合があります。 結果として、バイナリなしのレプリケーションを使用しているとき、レプリケーションが完了する前にバイナリデータが保持されていなかった可能性があります。この状況は、特にデータの可用性が重要な場合に問題を引き起こす可能性があります。
Experience Manager導入のたびに、ボトルネックを迅速に特定し解決できるパフォーマンステスト体制を確立します。 留意点は次のとおりです。
お客様からのネットワークのパフォーマンスに関するすべての懸念については、次のタスクを実行してください。
CPUの効率的な使用率と負荷分散により、待ち時間を最小限に抑え、高いスループットを実現するには、Experience Manager導入環境のパフォーマンスを定期的に監視します。 具体的には、次のことを実行します。