ドキュメント

Dispatcher キャッシュを最適化するにはどうすればよいですか？

Last update: Thu May 30 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

この記事では、Dispatcher キャッシュを最適化する様々な方法について詳しく説明します。 さらに、TTL （「Time to Live」または有効期限）スタイルの無効化、Dispatcher フラッシュエージェントの無効化、Dispatcher フラッシュの再取得などの手順についても説明します。

説明 description

環境

Adobe Experience Manager

問題/症状

この記事では、AEM Dispatcher の最新の最適化と、それらを最大限に活用する方法について重点的に説明しています。 AEM Dispatcher はキャッシングです リバースプロキシ Adobe Experience Managerで使用するように設計されたサーバー。 既存の web サーバーソフトウェア内にモジュールとしてインストールして実行できます。 この記事の作成時点では、 dispatcher モジュールがサポートされています。 Apache HTTP Server、Microsoft IIS、iPlanet の場合。

解決策 resolution

Dispatcher のキャッシュの仕組み

最も基本的なレベルでは、AEM Dispatcher は、キャッシュの実行、キャッシュのフラッシュおよびキャッシュの無効化によって動作するリバースプロキシです。

Dispatcher について詳しくは、関連リンクを参照してください。

  1. Dispatcher の作動方法とインストールする方法。
  2. Dispatcher で使用できる設定オプション。
  3. Dispatcher の作動方法のウェビナー - プレゼンテーションの一部の情報は、古いバージョンの Dispatcher に関するものです。
  4. Dispatcher の機能についての Gems ウェビナー、CDN 上の使用およびセキュリティ。
  5. Dispatcher の新しい機能に関する Gems セッション（v4.1.9 以降）。

Dispatcher キャッシュの最適化

次に、Dispatcher キャッシュを最適化する方法を示します。

  1. ほぼすべてをキャッシュ  - ユーザーから 2 回以上リクエストされるようなコンテンツはすべてキャッシュします。

  2. パーソナライズされたコンテンツを様々な期間キャッシュする  - サイトにパーソナライズされたコンテンツがある場合は、の使用を検討します Apache Sling Dynamic Includes ajax （ブラウザーレベルでの非同期 JavaScript および XML 呼び出し）、SSI （web サーバーレベルでのサーバーサイドインクルード）、および ESI （CDN レベルでのエッジサイドインクルード）を活用するAEM アプリケーションで、ページの異なる部分を異なる期間キャッシュします。

  3. ライブ Dispatcher では決して Dispatcher キャッシュを削除しない  - Dispatcher がライブコンテンツを配信している場合にキャッシュを削除すると、大量のリクエストが AEM に戻されます。これにより、Dispatcher キャッシュはライブ Dispatcher では削除されません。

  4. キャッシュの準備  - Dispatcher キャッシュを削除する前に、Dispatcher をロードバランサーから引き出し、キャッシュを削除してから、ロードバランサーに配置する前に Dispatcher 上のファイルをキャッシュする web クローラーツールを実行します。

  5. エラーページをキャッシュ   – を活用 DispatcherPassError 1 （Apache web サーバー専用の）ディレクティブで、Dispatcher のキャッシュから 404 などのエラーページを提供します。

  6. 事前に圧縮されているものを除き、すべてのファイルタイプを GZip で圧縮する  - Apache Web サーバーで、 mod_deflate を使用できますが、以下を確認してください  Vary: User-Agent  ヘッダー が設定されていません。Microsoft IIS では、動的圧縮を使用します。

    Apache 設定例（圧縮済みのファイルタイプを回避するために、特定のコンテンツタイプのみを指定）:

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

  7. Enable （有効） /serveStaleOnError   /cache 設定内 - AEM インスタンスでエラーを処理している際に、古いキャッシュファイルを提供します。

  8. 追加 /gracePeriod   /cache 設定に追加します – 最後のコンテンツ公開イベント（「アクティブ化」）の後、自動で無効化された古いリソースがキャッシュから引き続き提供される秒数を定義します。これにより、「ツリーのアクティブ化」などの大規模なコンテンツ公開アクティビティの際にパブリッシュインスタンスに戻るリクエストの数が減ります。

  9. にルールを追加 /ignoreUrlParams  - アプリケーションが必要としない、または使用しないクエリ文字列パラメーターを無視します。これにより、クエリ文字列が存在する場合でも、URL のキャッシュが可能になります。

  10. Cache-Control および Last-Modified 応答ヘッダーをキャッシュする   – を使用します  /headers  http 応答ヘッダーをキャッシュする設定  キャッシュコントロール  および  最終変更日  （および/または  ETag  ヘッダー（AEMから送信する場合）。これは、CDN およびブラウザーレベルでキャッシュを簡素化し、最適化するのに役立ちます。これらのヘッダーをキャッシュすることで、web サーバー自体ではなく、AEM のみがヘッダーを設定するようになります。これを行う場合、AEM アプリケーションからヘッダーを送信し始める必要があることに注意してください。

  11. コンテンツをできるだけ長くキャッシュする  および  AEMに戻るリクエストを減らす   – すべてのフラッシュエージェントでフラッシュの再取得を有効にして、フラッシュリクエストを最適化します。 というタイトルの以下の節を参照してください。 Dispatcher フラッシュの再取得. または使用  /enableTTL  およびを設定  キャッシュコントロール : max-age=…  ファイルをできるだけ長くキャッシュするヘッダー。このトピックについて詳しくは、こちらを参照してください。

TTL の使用

Dispatcher バージョン 4.1.11 以降、 /enableTTL 1 .any ファイル設定で設定できます。  この設定により、Dispatcher は HTTP Cache-Control 応答ヘッダーで設定されたキャッシュの有効期限を尊重するようになります。つまり、Dispatcher は、ファイルの有効期限が切れると、プライマリ形式のキャッシュ無効化が発生する CDN と同様に機能します。  これを実装して送信を開始したら、  キャッシュコントロール : max-age=…  AEMからのすべての応答について、パブリッシュインスタンスで dispatcher フラッシュエージェントを安全に無効にできます。

パブリッシュインスタンスでフラッシュエージェントを無効にした後も、Dispatcher キャッシュをフラッシュできるようにすることができます。その場合、ACS Commons - Dispatcher フラッシュ UI を使用することができます。このツールは、オーサーインスタンスにインストールされています。これは、ユーザーが手動でキャッシュのフラッシュリクエストを実行できる UI を提供します。

I. TTL（「Time to Live」または有効期限）スタイルの無効化を有効にするための手順：

  1. 送信するAEM アプリケーションのソースコードを変更  キャッシュコントロール  ヘッダーと  最終変更日  まだ設定されていないすべてのリクエストの場合。
  2. Dispatcher 4.1.11 以降をインストールします。
  3. を設定  /enableTTL 1  サイトの.any ファーム設定。
  4. を  /headers  をキャッシュする設定  キャッシュコントロール  および  最終変更日  ヘッダー。
  5. Web サーバーを再起動します。

II. パブリッシュインスタンスで Dispatcher フラッシュエージェントを無効にする：

Dispatcher は、Cache-Control ヘッダーを使用して、キャッシュファイルの無効化を制御するようになりました。そのため、パブリッシュインスタンスからフラッシュされる Dispatcher が必要なくなりました。

  1. 各パブリッシュインスタンスで/etc/replication/agents.publish.html に移動します。
  2. 各フラッシュエージェントの設定に移動して、エージェントを無効にします。

III. オーサーインスタンスからの手動 Dispatcher フラッシュリクエストを許可する：

フラッシュエージェントが無効になっているので、完全に  キャッシュコントロール  コンテンツが更新されるタイミングを制御するヘッダーを dispatcher で使用します。それでも、次のように Dispatcher キャッシュを手動でフラッシュすることユーザーに許可できます。

  1. ACS Commons - Dispatcher フラッシュ UI をオーサーインスタンスにインストールします。
  2. オーサーインスタンスでフラッシュエージェントを設定します。
  3. 各エージェント設定で、を設定します  トリガー  =>   デフォルトを無視  有効にするオプション。 このオプションは、ユーザーが AEM UI で 公開（非公開） または アクティブ化（非アクティブ化） をクリックしたときに、フラッシュエージェントを無視するようにします。

Dispatcher フラッシュの再取得

Dispatcher フラッシュのリクエストを最適化するために、すべての Dispatcher フラッシュエージェントは、フラッシュの再取得という機能を有効にする必要があります。

Dispatcher フラッシュの再取得を有効にするには、次の手順を実行します。

  1. http://aemhost:port/crx/packmgr/index.jsp に移動して、管理者としてログインします。

  2. こちらからパッケージをダウンロードします。

  3. パッケージをパッケージマネージャーにアップロードしてインストールします。

  4. Dispatcher フラッシュエージェント設定に移動します。例：  /etc/replication/agents.author/flush.html

  5. 「編集」をクリックします。

  6. 次の内容を設定します。

    • Serialization Type  =  Re-fetch Dispatcher Flush
    • 拡張  =>   HTTP メソッド  =  POST

  7. 「Save」をクリックします

メモ – 上記でインストールしたパッケージは、あくまで基本的な例です。フラッシュの再取得をカスタマイズおよび最適化するために、送信する URI のリストを変更できます。このコードはオープンソースで、こちらで見つけることができます。このコードは、どのバスを再取得したらよいか Dispatcher に示すパラメーターとして、リクエスト本文に URI のリストを追加します。  サイトのキャッシュ機能を最適化するために、アプリケーションの要件に応じて、より多くのパスを追加できます。

フラッシュの再取得に関する詳細な説明

通常、Dispatcher フラッシュは、ファイルを削除することで動作します。

  1. .stat ファイルにタッチします
  2. /content/foo を削除します。*
  3. /content/foo/_jcr_content を削除します

手順 2 でファイルが削除されるので、次にユーザーが/content/foo.htmlや/content/foo.jsonなどのファイルをリクエストすると、ファイルが「再フェッチ」されている間、同じファイルに対する後続のリクエストも、そのファイルがキャッシュされるまで、パブリッシュインスタンスに送信されることになります。応答が遅いページやホームページなどのトラフィックが多いページでは、これが、パブリッシュインスタンス層がフラッディングする原因となる可能性があります。

この問題を解決するには、「re-fetching」という名前の Dispatcher の機能を有効にします。この機能を使用すると、Dispatcher が削除する代わりに、事前に「re-fetch」して置き換える URI のリストを送信できます。

仕組みと設定方法のデモについては、このプレゼンテーションの 22:41-27:05 を参照してください。

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f