概要

この記事では、AEM ディスパッチャー内の最新のディスパッチャーとこれらの最適な活用法に焦点を当てます。  AEM ディスパッチャーは Adobe Experience Manager で使用するように設計されたキャッシュリバースプロキシサーバーです。  既存の Web サーバーソフトウェア内のモジュールとしてインストールおよび実行できます。  この記事の作成時点では、ディスパッチャーモジュールは、Apache HTTP サーバー、Microsoft IIS および iPlanet でサポートされています。

ディスパッチャーキャッシングの仕組み

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

ディスパッチャーの詳細については、関連リンクを参照してください。

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

ディスパッチャーキャッシュの最適化

ディスパッチャーキャッシュを最適化する方法は以下の通りです:

  1. ほぼすべてをキャッシュする - これはユーザーが何度もリクエストするすべてのコンテンツをキャッシュすることを意味します。
  2.  異なる期間のパーソナライズされたコンテンツをキャッシュ - もしサイトにパーソナライズされたコンテンツがある場合、Ajax(Asynchronous JavaScript and XML calls、ブラウザーレベル)、SSI(Server Side Includes、Web サーバーレベル)、および ESI(Edge-side Includes、CDN レベル)を利用してページの異なる期間の異なる部分をキャッシュするために、AEM アプリケーションの Apache Sling Dynamic Includes の使用を考慮してください。
  3. ライブディスパッチャーでは決してディスパッチャーキャッシュを削除しない - ディスパッチャーがライブコンテンツを配信している場合にキャッシュを削除すると、大量のリクエストが AEM に戻されます。  これにより、ディスパッチャーキャッシュはライブディスパッチャーでは削除されません。
  4. キャッシュの準備 - ディスパッチャーキャッシュを削除する前に、ディスパッチャーをロードバランサーから引き出し、キャッシュを削除してから、ロードバランサーに配置する前にディスパッチャー上のファイルをキャッシュする Web クローラーツールを実行します。
  5. キャッシュのエラーページ - DispatcherPassError 1(Apache ウェブサーバーの詳細)ディスパッチャーのキャッシュから 404s などのエラーページをサーブする指示を利用する。
  6. GZip は、事前に圧縮された以外のすべてのタイプのファイルを圧縮します- Apache Web サーバーにおいて、mod_deflate は使用できますが、Vary: User-Agent ヘッダーが設定されていないことを確認してください。  Microsoft IIS では、ダイナミック圧縮を使用します。
  7. /serveStaleOnError を有効にする - AEM インスタンスでエラーを処理しているときに、古いキャッシュファイルに提供します。
  8. /ignoreUrlParams へルールを追加 - アプリケーションで不要、または使用しない querystring パラメーターを無視します。  これにより、querystring が存在する場合でも、URL のキャッシュが可能になります。
  9. キャッシュコントロールおよび最終変更応答ヘッダーをキャッシュします - HTTP 応答ヘッダーをキャッシュするには ヘッダーの設定を使用します。キャッシュコントロール l および最終応答(AEM から送信する場合は、および/または ETag ヘッダー)  これは CDN およびブラウザーレベルでキャッシュを簡素化および最適化するために役立ちます。  これらのヘッダーをキャッシュすると、Web サーバー自体ではなく、AEM セットのみが設定されます。  この場合は、AEM アプリケーションからヘッダーの送信を開始する必要があります。
  10. できるだけ長い期間にわたってコンテンツをキャッシュするそして AEM に戻ってリクエストを削減する - すべてのフラッシュエージェントのフラッシュをリフェッチすることを有効することで、フラッシュのリクエストを最適化します。  /enableTTL を使用し、可能な限り長い時間キャッシュファイルへの Cache-Control: max-age=... ヘッダーをを設定します。  このトピックについて詳しくは、以下を参照してください。

TTLs の使用

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

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

I. TTL(「Time to Live」または有効期限)スタイルの無効化を有効化する手順:

  1. AEM アプリケーションのソースコードを変更し、設定されていない要求に対し、キャッシュの制御ヘッダーと最終更新を送信します。
  2. ディスパッチャー 4.2.3 以降をインストールします。
  3. サイトの .any ファーム設定において /enableTTL 1 を設定してください。
  4. /headers 設定しキャッシュコントロールヘッダー最終更新ヘッダーをキャッシュします。
  5. ウェブサーバーを再起動します。

II.公開インスタンスで Dispatcher フラッシュエージェントを無効にするには:

この Dispatcher では、キャッシュコントロールヘッダーを使用してキャッシュファイルの無効化を制御します。  この場合、ディスパッチャーは発行インスタンスからフラッシュされなくなります。

  1. 発行インスタンスごとに /etc/replication/agents.publish.html に移動します。
  2. 各フラッシュエージェントの構成に移動し、エージェントを無効にします。

III.作成者インスタンスからの手動ディスパッチャーフラッシュリクエストを許可します。

フラッシュエージェントが無効になっているため、コンテンツがディスパッチャーで更新されるとき、完全にキャッシュ制御ヘッダーに依存します。  それでも、次のようにディスパッチャーキャッシュを手動でフラッシュすることユーザーにを許可できます。

  1. ACS Commons - ディスパッチャーフラッシュ UI を作成者インスタンスにインストールします。
  2. 作成者インスタンスでフラッシュエージェントを設定します。
  3. 各エージェント設定で、トリガー => デフォルトを無視オプションを設定し有効にします。このオプションにより、ユーザーが AEM UI で(非)公開アクティベート(解除)をクリックするとき、フラッシュエージェントが無視します。

ディスパッチャーフラッシュの再取得

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

ディスパッチャーフラッシュの再取得を有効にするには、次の操作を行います。

  1. http://aemhost:port/crx/packmgr/index.jsp へ移動し、管理者としてログインします。
  2. ここからパッケージをダウンロードしてください。
  3. パッケージマネージャーにパッケージをアップロードし、インストールします。
  4. ディスパッチャーフラッシュエージェント設定に移動します。例えば、/etc/replication/agents.author/flush.html
  5. 編集」をクリックします。
  6. 以下を設定します。
    • Serialization Type = Re-fetch Dispatcher Flush
    • Extended => HTTP Method = POST
  7. 保存」をクリックします。

上記のインストールパッケージは基本的なであることに注意してください。  re-fetching flush をカスタマイズして最適化するには、送信する URI のリストを変更します。  コードはオープンソースで、次の URL からでも入手できます  このコードは、どのバスを再取得したらよいかディスパッチャーに示すパラメーターとして、要求本文に URI のリストを追加します。  アプリケーションの要件ごとにさらにパスを追加して、サイトのキャッシュ機能を最適化することができます。

フラッシュの再取得についてのより詳細な説明。

通常、ディスパッチャーフラッシュはファイルを削除することによって作動します。

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

手順 2 でファイルが削除された事実によって、次回ユーザーが /content/foo.html または /content/foo.json などのファイルをリクエストする場合、そのファイルが「再取得」されている間に同じファイルの次のリクエストもまたファイルがキャッシュされるまでパブリッシュインスタンスに送信されます。  低速な応答またはホームページなどの重いトラフィックページの場合、これがパブリッシュインスタンス層があふれる原因を引き起こすことがあります。

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

どのように動作し、どのように設定するかのデモンストレーション動画は、プレゼンテーションレコーディングの 22:41-27:05 を参照してください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー