サーバー側の Web 階層キャッシング
Commerce Cloud アプリケーション層コンポーネントの 1 つは、SCAPI リクエストの Web 階層キャッシングを実行します。これは、さまざまな API ファミリーへの GET リクエストに影響を与えます。
このサーバー側のキャッシングメカニズムは、リクエストが Commerce Cloud のサーバー側アプリケーション層に到達した後でのみ使用されます。別のキャッシングメカニズムが設置されている場合は (たとえば、クライアント側)、そのメカニズムは引き続き独立して使用されます。ストアフロント実装のフロントエンドまたはクライアント側で複数のキャッシング層を扱う場合は、これを考慮する必要があります。
次の API の GET リクエストに対するレスポンスはキャッシュされます。
- /product/shopper-products/v1/organizations/{org-id}/categories/{id}
- /product/shopper-products/v1/organizations/{org-id}/categories
- /product/shopper-products/v1/organizations/{org-id}/products/{id}
- /product/shopper-products/v1/organizations/{org-id}/products
- /search/shopper-search/v1/organizations/{org-id}/product-search
- /search/shopper-search/v1/organizations/{org-id}/search-suggestions
- /pricing/shopper-promotions/v1/organizations/{org-id}/promotions/campaigns
- /pricing/shopper-promotions/v1/organizations/{org-id}/promotions/campaigns
- /site/shopper-seo/v1/organizations/{org-id}/url-mapping
- /configuration/preferences/v1/organizations/{org-id}/site-custom-preferences?{siteId}
- /configuration/preferences/v1/organizations/{org-id}/global-custom-preferences
2024 年 3 月 12 日より前に SCAPI に登録した (それぞれのショートコードで SCAPI ゾーンをプロビジョニングした) お客様は、この機能を Business Manager の機能スイッチで有効にできます。これを行うには、Business Manager で管理 > 機能スイッチ に移動し、SCAPI サーバー側の Web 階層キャッシング の機能スイッチを有効にします。
2024 **年 3 月 12 日以降に SCAPI **に登録したお客様の場合、この機能スイッチは効果がなく、キャッシュはデフォルトでオンになっています。
これとは別に、特定のサイトに対して動的コンテンツのページキャッシングを有効にする必要があります。
これを行うには、Business Manager で、管理 > サイト > サイトの管理 > サイト名 - キャッシュの順に移動し、その後「ページキャッシングを有効にする」を選択します。
キャッシュエントリの有効期間、ならびにレスポンスがパーソナライズされるかどうかは、API、または API および選択された展開に利用可能な展開があるかどうかによって決まります。たとえば、availability (入手可能性) の展開が選択された状態で Product API に対してリクエストが行われた場合、キャッシュエントリはデフォルトで 60 秒のみ保存されます。
API に展開がある場合、すべての展開の中で最短の TTL により、キャッシュエントリの有効期間が決まります。リクエストされた展開の少なくとも 1 つが「パーソナライズ済み」としてマークされていない場合、レスポンス全体はパーソナライズされていないとみなされます。
| API 参照名 | Expansion Cache | time-to-live, seconds (デフォルト) パーソナライズされている (デフォルト) | |
|---|---|---|---|
| Categories | N/A | 86400 | No |
| 商品 | 入手可能性 | 60 | いいえ |
| bundled_products | 86400 | いいえ | |
| images | 86400 | いいえ | |
| links | 86400 | いいえ | |
| options | 86400 | いいえ | |
| prices | 900 | はい | |
| promotions | 900 | はい | |
| recommendations | 86400 | いいえ | |
| set_products | 86400 | いいえ | |
| variations | 86400 | いいえ | |
| なし | 86400 | いいえ | |
| 商品検索 | の入手可能性 | 60 | いいえ |
| images | 900 | いいえ | |
| prices | 900 | はい | |
| represented_products | 900 | いいえ | |
| variations | 900 | いいえ | |
| なし | 900 | いいえ | |
| 検索の提案 | 該当なし | 900 | いいえ |
| プロモーション | N/A | 3600 | いいえ |
| Campaigns | N/A | 3600 | No |
| SEO URL マッピング | N/A | 43200 | いいえ |
| Preferences (Site) | 300 | No | |
| Preferences (Global) | 300 | No |
特定の展開ではキャッシュエントリの有効期間は非常に短いため、必要な展開のみがリクエストに含まれていることを確認するようお勧めします。たとえば、Products API へのリクエストに「availability」の展開を不必要に含めると、キャッシュのヒット率は大幅に低下し、リクエストの全体的なパフォーマンスに悪影響を及ぼします。
リソースに対してパーソナル化が有効になっている場合、URL 文字列に加えて、次の情報がキャッシュ キーの一部になります。
- アクティブなプロモーションの完全なセット。
- アクティブな商品の並べ替えルールの完全なセット。
- 適用可能な価格表の完全なセット。
- アクティブな ABTest グループの完全なセット。
キャッシュはさまざまな応答のバリエーションをキャッシュに保存し、この追加情報に基づいて正しいバージョンを API ユーザーに配信します。
2 人の買い物客が同じ商品 API (つまり、同じ URL) にアクセスする場合の意味を考えてみましょう。この場合、買い物客 A はプロモーション X の対象となり、買い物客 B はプロモーション Y の対象となります。同じ商品 (URL は変更なし) が 2 回キャッシュされます。その後、プロモーション X の買い物客全員に、プロモーション Y の買い物客と同じキャッシュエントリが提供されます。このシナリオでは、価格表とプロモーションの数によっては、商品の価格にかかわらず、キャッシュエントリの数が大幅に増加する可能性があります。
パーソナルキャッシングは、必要な場合にのみ使用することを検討してください。しかも、十分な数の買い物客のグループのみが対象です。
新しい要求の場合、Web 層はまず、指定された要求のキャッシュ エントリが存在するかどうかをチェックします。キャッシュキーは、フックのカスタマイズが呼び出される前に計算され、フック内で後で発生する可能性のある変更は含まれません。したがって、該当する価格表やプロモーションなどのパーソナル化関連リソースの変更は、常に Shopper Context API を使用して適用し、必要な価格表とプロモーションが Web 層キャッシュで考慮されるようにする必要があります。
フックロジック内で該当する価格表とプロモーションを変更すると、最終的なキャッシュエントリが元のキーと一致しなくなり、キャッシュヒット率が低くなるためパフォーマンスが低下します。代わりに Shopper Context (買い物客のコンテキスト) を使用してください。
同様に、応答本文の更新の可能性 (カスタム属性の追加など) は、キャッシュ キー内では考慮されません。条件付きフックロジックのみにより、2 つの同一の要求 (URL とクエリ文字列) が異なる応答を生成することが想定されている場合、Web 層はそのような要求を同一と見なし、キャッシュされた応答を返します。Web 層キャッシュが正しく動作するようにするには、カスタム クエリ パラメーターを URL に追加することをお勧めします。
たとえば、
条件コードによる応答のカスタマイズは、条件が URL の一部として、つまりカスタムクエリパラメーターとして指定された場合にのみ正しくキャッシュされます。これは、パフォーマンスに影響を与える可能性があるため、必要な場合にのみ行ってください。
Script API には、キャッシュ設定をプログラムで制御するためのオプションが用意されています。
Script API の dw.system.Response#setExpires(milliseconds) メソッドを使用すると、任意のキャッシュ有効期限のタイムスタンプを設定できます。このメソッドはミリ秒単位のタイムスタンプを受け入れるため、現在のタイムスタンプと必要な「TTL (有効期間)」の合計をパラメーターとして渡す必要があります。
たとえば、カテゴリ API のレスポンスを 1 日ではなく 1 時間のみキャッシュする場合は、次のカスタムコードを使用できます。
キャッシュの TTL は 1 秒以上である必要があり、86,400 秒を超えることはできません。
Script API の dw.system.Response#setVaryBy(String varyBy) メソッドは、指定されたバリアント識別子を使用してレスポンスをパーソナライズ済みとしてマークします。price_promotion のみがサポートされており、他の値は無効です。
デフォルトでは、prices (価格) の展開と promotions (プロモーション) の展開を使用した商品呼び出し、および prices (価格) の展開を使用した商品検索呼び出しはパーソナライズれています。
現時点では、キャッシュを手動で無効にする方法は 1 つだけで、サイトのページキャッシュ全体を無効にすることです。
Business Manager で、管理 > サイト > サイトの管理 > サイト名 - キャッシュ の順に移動し、キャッシュタブを選択します。「キャッシュの無効化」セクションに、サイトのページキャッシュを無効にするボタンがあります。無効化がトリガーされると、SCAPI レスポンスに関連するキャッシュを含む、サイトのページキャッシュ全体が 15 分以内にクリアされます。
これにより、既存のパイプラインのキャッシュもすべて無効になり、パフォーマンスが一時的に低下する可能性があります。
新しいサーバー側のキャッシュを導入すると、キャッシュされたエンドポイントのレスポンスは常に Cache-Control ヘッダー値の no-cache, no-store, must-revalidate を返します。特にパーソナライズする場合は、SCAPI と Script Controller API の均一な動作を保証するために必要です。