ドキュメント

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

Last update: Tue Jul 16 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. パーソナライズされたコンテンツを様々な期間にキャッシュする - サイトにパーソナライズされたコンテンツがある場合は、AEM アプリケーションで Apache Sling Dynamic Includes を使用して、Ajax （ブラウザーレベルでの非同期JavaScriptおよび XML 呼び出し）、SSI （web サーバーレベルでのサーバーサイドインクルード）、ESI （Edgeサイドインクルード）を活用し、ページの様々な部分を様々な期間にキャッシュします。

  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 /serveStaleOnErrorin the /cache configuration - AEM インスタンスでエラーを処理している際に、古いキャッシュファイルを提供します。

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

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

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

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

TTL の使用

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

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

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

  1. AEM アプリケーションのソースコードを変更して、まだ設定されていないすべてのリクエストに対して Cache-Control header および Last-Modified を送信するようにします。
  2. Dispatcher 4.1.11 以降をインストールします。
  3. サイトの任意のファーム設定で /enableTTL 1 を設定します。
  4. Cache-Control🔗 および Last-Modified ヘッダーをキャッシュするように /headers 設定を設定します。 . Web サーバーを再起動します。

****II. パブリッシュインスタンスでDispatcher フラッシュエージェントを無効にする：**Dispatcherは、Cache-Control ヘッダーを使用して、キャッシュファイルの無効化を制御するようになりました。  そのため、パブリッシュインスタンスからフラッシュされるDispatcherが必要なくなりました。1) 各パブリッシュインスタンスで/etc/replication/agents.publish.html に移動します。 2) 各フラッシュエージェントの設定に移動して、エージェントを無効にします。**III. オーサーインスタンスからの手動Dispatcher フラッシュリクエストを許可する：フラッシュエージェントが無効になっているので、コンテンツが Dispatcher で更新される際に、完全に Cache-Control ヘッダーに依存します。  引き続き、Dispatcher キャッシュを手動でフラッシュすること（ユーザーによる）を許可できます。1) ACS Commons - Dispatcher フラッシュ UI をオーサーインスタンスにインストールします。 2) オーサーインスタンスでフラッシュエージェントを設定します。 3) 各エージェント設定で、トリガー => を設定します   Ignore Default オプションを有効にします。 このオプションは、ユーザーが AEM UI で 公開（非公開） または アクティブ化（非アクティブ化） をクリックしたときに、フラッシュエージェントを無視するようにします。Dispatcher フラッシュの再取得**Dispatcher フラッシュリクエストを最適化するために、すべてのDispatcher フラッシュエージェントは、フラッシュの再取得という機能を有効にする必要があります。Dispatcher フラッシュの再取得を有効にするには、次の手順を実行します。1) http://aemhost:port/crx/packmgr/index.jsp に移動して、管理者としてログインします。

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

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

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

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

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

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

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

  7. /content/foo を削除します。*

  8. /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