AEM パフォーマンスの最適化

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

有効にすると、Dispatcher はバックエンドからの応答ヘッダーを評価します。応答ヘッダーに Cache-Control の max-age または Expires の日付が含まれている場合は、キャッシュファイルの横に空の補助ファイルが作成され、変更時間は有効期限と同じになります。 変更時間を過ぎてキャッシュされたファイルがリクエストされると、バックエンドから自動的に再リクエストされます。 これにより、製品アップデート遅延（TTL）がビジネス関係者に認められ受け入れられると、手動の介入やメンテナンスを必要としない効果的なキャッシュメカニズムが提供されます。

ブラウザーのキャッシュ

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

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

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

Dispatcher statfilelevel anbd 猶予期間の最適化

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

どのサイト（特にコマースサイトの負荷が高い場合）でも、これによりAEM Publish層に不要な量の負荷が発生し、1 回のページ更新だけでサイト構造全体が無効化されます。

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

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

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

各フォルダーレベルには「統計レベル」があります（上の表で分類されています）。

この場合、statfilelevel プロパティをデフォルトの「0」のままにしておき、product-page.html テンプレートが更新され、無効化をトリガーしてアクティブ化されると、docroot からレベル 4 までのすべての.stat ファイルがタッチされ、ファイルが無効化されて、その 1 つの変更からサイト全体のすべてのページ（他の web サイト、国、言語を含む）のAEM パブリッシュインスタンスからさらにリクエストが発生します。

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

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

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

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

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

次の例では、ナビゲーションコンポーネントをキャッシュします。これは、サイト内のすべてのページで同じGraphQL クエリを送信するからです。 次のリクエストでは、ナビゲーション構造の過去 100 個のエントリを 10 分間キャッシュします。

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 クライアント」の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 リクエスト

ページ内の特定の動的データコンポーネントはキャッシュせず、常にGraphQLAdobe Commerceへの呼び出し（買い物かごやチェックアウトページ全体での呼び出しなど）が必要になります。 この情報はユーザーに固有で、買い物かごに製品を追加するなど、サイト上の顧客のアクティビティによって絶えず変化しています。

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

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

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

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

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

gclid と fbclid は、広告をクリックするたびに変更されます。これはトラッキング目的ですが、デフォルト設定では、AEMはすべてのリクエストを一意のページとして見てしまい、Dispatcher をバイパスして、パブリッシャーとAdobe Commerceに不要な追加負荷を生み出します。

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

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

Dispatcher の MPM ワーカーの制限

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

この設定では、Apache HTTP が「完全な準備設定」のままになります。これは、大量の RAM と複数の CPU コアを備えたサーバー向けの高性能な設定です。 この設定により、リクエストに対応できる永続的なオープン接続を維持することで、Apache HTTP からの最適な応答時間が得られ、フラッシュセールス時などの突然のトラフィックサージに応答して新しいプロセスを生成する遅延が取り除かれます。