AEM 5.x のパフォーマンス調整のヒント

問題

CQ5 インスタンスのパフォーマンスが低下します。

原因

CQ5 のパフォーマンスの問題は、ペアで行う操作の多くが原因である可能性があります。最も一般的な原因は、アプリケーションコードが原因です。ただし、パフォーマンスを向上させる CQ5 設定内で対策を講じることができます。

解決策

CQ インスタンスの全体的なパフォーマンスを向上させるには、以下（作成者および公開インスタス）で行うことをお勧めします。

1. 推奨ホットフィックスをインストールします

これは、AEM 5.6.1 に適用されます。https://helpx.adobe.com/jp/experience-manager/kb/cq561-available-hotfixes.html を注意深くお読みください。モジュールの推奨ホットフィックス、特にパフォーマンスに関するものがインストールされます。

2. bundleCacheSize CRX での増加

次を実行することで CRX TarPersistenceManager の bundleCacheSize パラメーターが増大します。

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager" /> エレメント内の次のパラメーターを追加して repository.xml の各 PersistenceManager エレメントと、すべての workspace.xml ファイルを編集します。
例えば：

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="bundleCacheSize" value="256" /> </PersistenceManager>

デフォルトではこのキャッシュは 8 MB に設定されています。JVM のメモリの割り当て量によって、最低 256 MB、または 512MB に増やします。10GB Xmx パラメーターの JVM を使用している場合は、bundleCacheSize を 1024 MB bundleCacheSize に設定します。Windows 32 ビット JVM を使用している場合、Xmx パラメーターは、1500 MB 未満です。したがって、bundleCacheSize の妥当な値は 128 MB です。Adobe では、JVM ヒープにより多くのメモリを割り当てるには、64 ビット JVM にアップグレードすることをお勧めします。

3. FineGrainedISMLocking（CRX 1.4.x のみ）を使用

これを設定するには、workspace.xml と repository.xml、SearchIndex ブロックの後ろに、直接次にある ISMLocking クラスを追加します。

<Workspace ...> ... </SearchIndex> <ISMLocking class="org.apache.jackrabbit.core.state.FineGrainedISMLocking"/> ... </Workspace>

4. CQ5 AssetSynchronizationService（CQ 5.3 のみ）を無効化

AssetSynchronizationService は、マウントされたリポジトリ（LiveLink、Documentum など）からアセットを同期します。有効にすると、このサービスは、ガベージコレクションを受ける多くのオブジェクトを定期的に割り当てられることを確認しました。したがって、JVM のパフォーマンスに影響を与えます。インストールされたリポジトリを使用しない場合は、このサービスを無効にすることができます。

設定によって、同期期間がさらに大きくなる秒数（デフォルトは 300）設定に制限はあり、このように事実上実行を防ぐことができます。

添付されたパッケージは同期期間を 1 年に設定するので、サービスを無効にします。

5. CRX 検索インデックスの resultFetchSize パラメーターを設定

jcr クエリーの結果セットが大きい場合は、完全なセットと ACL の確認が高価になります。これを解決するには、workspace.xml の SearchIndex エレメントを介したように、取得サイズを 50 に制限します。

<param name="resultFetchSize" value="50"/> 例えば：

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="resultFetchSize" value="50"/> </SearchIndex>

6. CRX 検索 cacheSize パラメーターの設定

検索 cacheSize は、workspace.xml の SearchIndex エレメントも設定されます。このパラメーターを 100000 に設定します。

<param name="cacheSize" value="100000" />

例：

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="resultFetchSize" value="50"/> <param name="cacheSize" value="100000" /> </SearchIndex>

このパラメーターは、ここで確認できます。

7. CRX クラスタリング（CRX 1.4、2.0、2.1）

書き込み負荷が高いシステム（大規模な DAM アセットの読み込みなど）を実行すると、比較的小さい書き込みパフォーマンスが得られる場合があり、これにより、必要なパフォーマンスベンチマークを実現できます。このような場合は、デプロイメントでのクラスター化するジャーナルをオフにしてください。

デフォルトでは、CRX はクラスターモードで実行するように設定されています。しかし、クラスターにインスタンスが 1 つしかない場合は、I/O オーバーヘッドが追加されます。パフォーマンスを書き込むには、クラスター化を無効にします。

repository.xml の <Cluster ...>...</Cluster> をコメントアウトします。
次にサンプルスクリプトを使用して、クラスターモードから単一モードにリポジトリファイルを移動します。

この手順を行う前に、daycare またはアカウントマネージャーに連絡して、このオプションを説明してください。ほとんどの顧客のデプロイメントは、デフォルトの journaled 設定で実行されます。稼働システムレンダリングのテストインスタンスでこのスクリプトをテストすることをお勧めします。

8. コンテンツファインダーの更新と自動読み込みを無効にする（作成者インスタンスのみ）

この記事を参照する。[2]

9. DAM サブアセットの生成を無効にする

この記事を参照してください。[3]

10.CRX での最大ジャーナルサイズの制限

共有／ジャーナルの下にある CRX ジャーナルファイルが大きすぎる場合は、アプリケーションが遅くなることがあります。ファイルのジャーナルサイズと最大数を制限する方法については、この記事 [4] を参照してください。

11.公開 DAM ワークフローの無効化（CQ 5.3 は公開インスタンスのみ）

この記事 [5] を参照してください

12.リンクチェッカーの無効化

パフォーマンスのゲインは、リンクチェックを無効にすることによって保持できます（特に AEM 5.6.1 です）。これは、環境で必要とされていない場合にのみ実行してください。

リンクチェックでは、ページアドレスのリソース URL がアクセス可能かどうかが検証されます。これは、HTTP HEAD リクエストを実行することによって行います。

作成者に無効なリンクがマークされている場合、リンクチェックはその周囲に壊れたアイコンを表示します。リンクが公開で無効とマークされている場合、周辺の <a href="..."> タグは削除されます。

一部のクライアントは、発行インスタンスで無効にしてパフォーマンスを向上させます。これによりパフォーマンスが向上しますが、リンクはサイトの SEO に影響します。無効にする前に、エフェクトを注意深く有効にすることを検討してください。

この機能を無効にする手順については、この記事[6] を参照してください。

13. Tar PM インデックスをキャッシュする

CRX 2.1 まで

cron ジョブを使用して、時間から時間にインデックス *.tar ファイルを読み込むことで、tar インデックスが、ハードウェア I/O キャッシュにキャッシュされるので、パフォーマンスを向上できます。UNIX では、「cat index*.tar > /dev/null」コマンドを使用して、インデックス *.tar を読み込めます。TarFile.readFully() メソッドの実行中に、一時間おきに Tar パーシスタンスマネージャーのパフォーマンスを向上させる必要があるとします。

CRX 2.2 から + hotfixpack 2.2.0.26 移行

crx.default ワークスペースで index_*.tar ファイルのグローバルサイズを確認し、最大ヒープサイズをそのサイズで増やし、workspace.xml の TarPersistenceManager セクションに indexInMemory パラメーターを true に設定します。

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
<param name="indexInMemory" value="true" />
</PersistenceManager>

1 つの JCR ノードに必要なヒープ空間は 128 バイトです。ワークスペースの最大インデックス *.tar ファイルが 1GB の場合、各ノードは 64 バイトのディスク容量が必要なため、このワークスペースには約 16,000,000 ノードです。内部メモリを使用したインデックスオプションは約 2GB のヒープ空間（インデックスの結合中にインデックスファイルごとに 2 つのバージョンがあるので、ファイルサイズを2倍にしたヒープ空間を計算する）が必要です。

14.LDAP のキャッシュの有効期限

パフォーマンスを向上させ、認証プロセスの間に遅延を軽減するために、LDAP のキャッシュの有効期限を適切に増加し、LDAP の設定の cache.expiration を 86400（1 日）に設定できます。

15.ディスク容量と効率を取得する Lucene インデックスの最適化

参考資料

[1] http://wiki.apache.org/jackrabbit/Search
[2] ContentFinder 間隔の変更方法を更新
[3] DAM ワークフローから subasset 生成を削除する方法
[4] 大量のディスク容量を消費するジャーナル
[5] 公開 DAM ワークフローを無効にする方法
[6] リンクチェックを無効化
[7] Lucene のインデックスを最適化しディスク容量と効率化を取得

適用対象

CQ 5.x、CRX 2.x