AEM performance optimization

AEM Dispatcher は、高速で動的な環境の配信に役立つリバースプロキシです。 Apache HTTP Server などの静的HTMLサーバーの一部として機能し、可能な限り多くのサイトコンテンツを静的リソースの形式で保存（または「キャッシュ」）することを目的としています。 この方法は、AEMのページレンダリング機能とAdobe Commerce GraphQLサービスにできるだけアクセスする必要性を最小限に抑えることを目的としています。 ページの多くを静的HTML、CSS、および JS として提供することで、ユーザーにパフォーマンスのメリットを提供し、環境のインフラストラクチャ要件を軽減します。 ユーザー間で同じように繰り返される可能性が高いページまたはクエリは、キャッシュの対象と考える必要があります。

次の節では、CIF/Adobe Commerce環境でAEMに対して効果的なキャッシュを有効にするために、技術的な検討が必要な推奨事項を大まかに示します。

AEM Dispatcher に基づく TTL

すべてのAEMプロジェクトで、Dispatcher 上で可能な限り多くのサイトをキャッシュすることがベストプラクティスです。 時間ベースのキャッシュ無効化を使用すると、設定された時間、サーバー側でレンダリングされた CIF ページがキャッシュされます。 設定された時間が経過した後、次のリクエストはAEMパブリッシャーとAdobe Commerce GraphQLからページを再構築し、次の無効化まで Dispatcher キャッシュに再び保存します。

TTL キャッシュ機能は、ACS AEM Commons パッケージ内の「Dispatcher TTL」コンポーネントを使用して、dispatcher.any 設定ファイルで/enableTTL "1"に設定することで、AEMで設定できます。

有効にした場合、Dispatcher はバックエンドからの応答ヘッダーを評価し、Cache-Control max-age または Expires 日付が含まれる場合は、有効期限と同じ変更時刻を持つ予備の空のファイルがキャッシュファイルの隣に作成されます。 変更時刻以降にキャッシュされたファイルがリクエストされると、自動的にバックエンドから再リクエストされます。 これにより、ビジネス関係者が製品更新遅延 (TTL) を承認し、承認した後で、手動の介入やメンテナンスを必要としない、効果的なキャッシュメカニズムが実現します。

ブラウザーのキャッシュ

上記の Dispatcher TTL アプローチは、要求を大幅に減らし、パブリッシャーに読み込みますが、変更される可能性が非常に低いアセットもあります。したがって、関連するファイルをユーザーのブラウザーでローカルにキャッシュすることで、Dispatcher への要求を減らすことができます。 例えば、サイトのロゴ（サイトテンプレート内のサイトの各ページに表示される）は、Dispatcher が要求するたびに要求する必要はありません。 代わりに、ユーザーのブラウザーキャッシュに保存できます。 各ページの読み込みに伴う帯域幅の要件の削減は、サイトの応答性とページの読み込み時間に大きな影響を与えます。

ブラウザーレベルでのキャッシュは、通常、「Cache-Control: max-age=」応答ヘッダーを介して実行されます。 maxage 設定は、「再検証」を試みる前に、またはサイトから再度要求する前に、ファイルをキャッシュする時間をブラウザに指示します。 この max-age キャッシュの概念は、一般に「キャッシュの有効期限」または TTL（「有効期間」）と呼ばれます。 大規模なコマースエクスペリエンスの提供 — Adobe Experience Manager、Commerce Integration Framework、Adobe Commerce 7

クライアントのブラウザーにキャッシュするように設定できるAEM/CIF/Adobe Commerceサイトの一部の領域は次のとおりです。

Dispatcher の statfilelevel 猶予期間の最適化

デフォルトの Dispatcher 設定では、 /statfilelevel "0"設定が使用されます。つまり、1 つの「.stat」ファイルが htdocs ディレクトリ（ドキュメントルートディレクトリ）のルートに配置されます。 AEM内のページまたはファイルに変更が加えられた場合、この単一の stat ファイルの変更時刻は、変更時刻に更新されます。 この時間がリソースの変更時間よりも新しい場合、Dispatcher はすべてのリソースが無効化されていると見なし、無効化されたリソースに対する後続の要求では、パブリッシュインスタンスへの呼び出しがトリガーされます。 つまり、この設定を使用すると、すべてのアクティベーションによってキャッシュ全体が無効化されます。

すべてのサイト（特に負荷の大きいコマースサイト）では、1 回のページ更新でのみサイト構造全体が無効化されるために、AEMパブリッシュ層に不要な負荷がかかります。

代わりに、ドキュメントルートディレクトリの htdocs ディレクトリ内のサブディレクトリの深さに対応する statfilelevel 設定を高い値に変更して、特定のレベルのファイルが無効化された場合、その.stat ディレクトリレベル以下のファイルのみが更新されるようにします。

例えば、次の場所に製品ページテンプレートがあるとします。

content/ecommerce/us/en/products/product-page.html

各フォルダーレベルには、上の表に示すように、「stat level」が設定されます。

この場合、statfilelevel プロパティをデフォルトの「0」に設定したままにし、product-page.html テンプレートが更新され、無効化のトリガーが有効化されると、docroot からレベル 4 までのすべての.stat ファイルが touch され、無効化され、サイト全体（他の Web サイト、国、言語を含む）からさらに要求されます。

ただし、statfilelevel プロパティがレベル 4 に設定され、product-page.html に変更が加えられた場合は、その特定の web サイト/国/言語の products ディレクトリ内の.stat ファイルのみが touch されます。

.stat ファイルのレベルを高いレベルに設定しすぎないでください。20 を超えると、パフォーマンスに影響を与える可能性があります。 パフォーマンステストの実行中に一括ファイルアクティベーションを実行すると、統計レベルを調整する必要がある正しいレベルが得られます。

statfilelevel の設定時に最適化をおこなうもう 1 つの Dispatcher 設定は、 gracePeriod の設定です。 これは、自動的に無効化された古いリソースを、最後のアクティベーションが発生した後にキャッシュから引き続き使用できる秒数を定義します。 自動無効化されたリソースは、任意のアクティベーションによって無効化されます（パスが dispatcher /invalidate セクションに一致する場合、および statfilelevel プロパティで指定されたレベルに一致する場合）。 gracePeriod 設定を 2 秒に設定すると、パブリッシャーがまだ新しいページの作成処理中である場合でも、複数のリクエストが継続的にパブリッシャーに送信されるシナリオを防ぐことができます。

CIF — コンポーネントを介したGraphQLキャッシュ

AEM内の個々のコンポーネントをキャッシュするように設定できます。つまり、Adobe CommerceへのGraphQLリクエストが 1 回呼び出され、設定された時間制限まで後続のリクエストがAEMキャッシュから取得され、Adobe Commerceにそれ以上読み込まれなくなります。 例えば、ファセット検索機能内の各ページおよびオプションに表示されるカテゴリツリーに基づくサイトナビゲーションです。これらは、Adobe Commerceに対するリソース集約型のクエリを必要とする 2 つの領域ですが、定期的に変更されないので、キャッシュに適した選択肢です。 この方法 ( パブリッシャーが PDP または PLP を再構築している場合でも、ナビゲーションビルドのリソースを集中的に消費するGraphQL要求がAdobe Commerceにヒットせず、AEM CIF のGraphQLキャッシュから取得できる可能性がある )。

次の例は、ナビゲーションコンポーネントがサイトのすべてのページで同じGraphQLクエリを送信するので、キャッシュするためのものです。 以下のリクエストは、ナビゲーション構造に対する 10 分間の過去 100 個のエントリをキャッシュします。

venia/components/structure/navigation:true:100:600

以下の例では、過去 100 個のファセット検索オプションを 1 時間の検索ページにキャッシュします。

com.adobe.cq.commerce.core.search.services.SearchFilterService:true:100:3600

キャッシュが「ヒット」され、Adobe Commerceへの繰り返し呼び出しがおこなわれないようにするには、すべてのカスタム http ヘッダーと変数を含むリクエストが、完全に一致する必要があります。 設定後は、手動でこのキャッシュを無効にする簡単な方法がないことに注意してください。 したがって、Adobe Commerceで新しいカテゴリが追加された場合、上記のキャッシュに設定された有効期限が切れ、GraphQLリクエストが更新されるまで、ナビゲーションに表示されなくなります。 検索ファセットも同じです。 ただし、このキャッシュで実現するパフォーマンスのメリットを考えると、通常は妥協点として許容できます。

上記のキャッシュオプションは、「GraphQL Client Configuration Factory」のAEM OSGi 設定コンソールを使用して設定できます。 各キャッシュ設定エントリは、次の形式で指定できます。

* NAME:ENABLE:MAXSIZE:TIMEOUT like for example mycache:true:1000:60 where each attribute is defined as:
    › NAME (String): name of the cache
    › ENABLE (true|false): enables or disables that cache entry
    › MAXSIZE (Integer): maximum size of the cache (in number of entries)
    › TIMEOUT (Integer): timeout for each cache entry (in seconds)

ハイブリッドキャッシュ — キャッシュされた Dispatcher ページ内のクライアント側GraphQL要求

ページのキャッシュに対するハイブリッドアプローチも可能です。CIF ページに、常にAdobe Commerceから顧客のブラウザーから直接最新情報をリクエストするコンポーネントを含めることができます。 これは、テンプレート内のページの特定の領域で、リアルタイム情報（PDP 内の製品価格など）を最新の状態に保つことが重要な場合に役立ちます。 動的な価格の一致によって価格が頻繁に変化する場合、その情報を Dispatcher にキャッシュしないように設定でき、価格は、AEM CIF Web コンポーネントを使用して、GraphQL API を介してAdobe Commerceから顧客のブラウザーでクライアント側を直接取得できます。

これは、AEMコンポーネント設定を使用して設定できます。製品リストページの価格情報の場合は、製品リストテンプレートで、ページ設定で製品リストコンポーネントを選択し、「価格を読み込み」オプションをオンにして設定できます。 同じ方法が在庫レベルにも有効です。

上記の方法は、常に最新の情報を必要とするリアルタイムの場合にのみ使用してください。 上記の価格設定の例では、低トラフィック時に毎日の価格のみを更新し、その後キャッシュフラッシュ操作を実行することについて、ビジネス関係者と合意することができます。 これにより、価格情報を表示する各ページを作成する際に、リアルタイムの価格情報リクエストと、それに続くAdobe Commerceへの余分な負荷が不要になります。

キャッシュできないGraphQLリクエスト

ページ内の特定の動的データコンポーネントはキャッシュしないでください。また、Adobe Commerceに対するGraphQLの呼び出し（買い物かごの場合や、チェックアウトページ全体に対する呼び出しなど）が必ず必要になります。 この情報はユーザーに固有で、例えば製品を買い物かごに追加するなど、サイトでの顧客の行動によって常に変化しています。

サイトのデザインでユーザーの役割に基づいて異なる応答が提供される場合、GraphQLクエリの結果をログインした顧客に対してキャッシュしないでください。 例えば、複数の顧客グループを作成して、異なる製品価格や、各グループに対する異なる製品カテゴリの表示を設定できます。 このようなキャッシュの結果は、顧客に別の顧客グループの価格が表示されたり、間違ったカテゴリが表示されたりする可能性があります。

AEM Dispatcher キャッシュでのトラッキングパラメーターの無視

e コマースサイトは、PPC 検索広告やソーシャルメディアキャンペーンを使用して、サイトへのトラフィックを促進できます。

これらのメディアを使用すると、そのプラットフォームからのアウトバウンドリンクにトラッキング ID が追加されます。 例えば、FacebookはFacebook Click ID(fbclid) を URL に追加し、Google Adverts はGoogle Click ID(gclid) を追加します。これにより、AEMフロントエンドへの着信リンクが次のように表示されます。

https://www.adobe.com/?gclid=oirhgj34y43yowiahg9u3t

gclid と fbclid は、広告をクリックするすべてのユーザーによって変更されます。これは追跡を目的としていますが、AEMのデフォルト設定では、すべてのリクエストが一意のページとして表示され、Dispatcher がスキップされ、パブリッシャーとAdobe Commerceに不要な余分な負荷が発生します。

サージイベント中に、AEMのパブリッシャーが過負荷になり、応答しなくなる可能性もあります。 あるページのパラメーターを無視するように設定すると、そのページが初めて要求されたときにそのページがキャッシュされます。 ページに対する後続のリクエストは、リクエスト内のパラメーターの値に関係なく、キャッシュされたページに提供されます。

したがって、「ignoreUrlParams」のデフォルトでは、すべてのパラメーターを無視するように設定する必要があります。ただし、GETパラメーターを使用するとページのHTML構造が変更されます。 例えば、検索語句がGETパラメーターとして URL に含まれている検索ページです。この場合、ignoreUrlParams を手動で設定して、広告チャネルが使用する gclid、fbclid、その他のトラッキングパラメーターなどのパラメーターを無視し、通常のサイト操作に必要なGETパラメーターは影響を受けません。

MPM ワーカーの Dispatcher に対する制限

MPM ワーカーの設定は、Apache HTTP サーバーの高度な設定で、Dispatcher の使用可能な CPU および RAM に基づいて最適化を徹底的にテストする必要があります。 ただし、このホワイトペーパーの範囲では、 ServerLimit と MaxRequestWorkers を、サーバの使用可能な CPU と RAM がサポートするレベルに増やし、 MinSpareThreads と MaxSpareThreads を MaxRequestWorkers に一致するレベルに増やすことをお勧めします。

この設定により、Apache HTTP は「フル準備設定」のままになります。これは、大量の RAM と複数の CPU コアを持つサーバーに対して、高パフォーマンスの設定です。 この設定は、リクエストを処理するための常時オープン接続を維持することで Apache HTTP から最適な応答時間を生成し、Flash の販売中などの急激なトラフィックの急増に応じて新しいプロセスの生成に遅延を生じさせます。