AEM からのキャッシュされたページの無効化 invalidating-cached-pages-from-aem

Dispatcher を AEM と共に使用する際は、キャッシュが効果的に管理されるようにインタラクションを設定する必要があります。環境によっては、この設定でパフォーマンスを向上させることができます。

AEM ユーザーアカウントの設定 setting-up-aem-user-accounts

デフォルトの admin ユーザーアカウントを使用して、デフォルトでインストールされているレプリケーションエージェントを認証します。レプリケーションエージェントで使用する専用のユーザーアカウントを作成します。

詳しくは、AEM セキュリティチェックリストのレプリケーションユーザーとトランスポートユーザーの設定の節を参照してください。

オーサリング環境からの Dispatcher キャッシュの無効化 invalidating-dispatcher-cache-from-the-authoring-environment

ページが公開されると、AEM オーサーインスタンス上のレプリケーションエージェントがキャッシュの無効化要求を Dispatcher に送信します。Dispatcher では、新しいコンテンツが公開されると、最終的にキャッシュ内のファイルを更新します。

次の手順に従って、AEM オーサーインスタンスにレプリケーションエージェントを設定します。この設定により、ページのアクティベーション時に Dispatcher のキャッシュが無効になります。

または、AEM Touch UI から Dispatcher フラッシュエージェントにアクセスし、設定することもできます。

バニティー URL へのアクセスを有効にする方法について詳しくは、バニティー URL へのアクセスの有効化を参照してださい。

この方法には、次の 2 つの問題が発生する可能性があります。

パブリッシュインスタンスからの Dispatcher キャッシュの無効化 invalidating-dispatcher-cache-from-a-publishing-instance

キャッシュ管理をオーサー環境からパブリッシュインスタンスに移行すると、パフォーマンスが向上する場合があります。この場合、公開されたページを受信したときにキャッシュの無効化リクエストを Dispatcher に送信するのは、AEM オーサー環境でなくパブリッシュ環境となります。

次のような場合が考えられます。

パブリッシュインスタンス上で動作するレプリケーションエージェントが Dispatcher フラッシュを制御します。ただし、オーサリング環境で設定され、その後、エージェントをアクティベートして、転送されます。

設定後、オーサーからパブリッシュにページをアクティベートすると、このエージェントが標準のレプリケーションを開始します。ログには、次の例のようなパブリッシュサーバーからのリクエストを示すメッセージが含まれます。

手動での Dispatcher キャッシュの無効化 manually-invalidating-the-dispatcher-cache

ページをアクティベートせずに Dispatcher キャッシュを無効化（またはフラッシュ）するには、Dispatcher に HTTP リクエストを発行できます。例えば、管理者や他のアプリケーションによるキャッシュのフラッシュを可能にする AEM アプリケーションを作成できます。

HTTP リクエストによって、Dispatcher が特定のファイルをキャッシュから削除します。その後、オプションで、Dispatcher が新しいコピーを使用してキャッシュを更新します。

キャッシュされたファイルの削除 delete-cached-files

HTTP リクエストを発行します。これにより、Dispatcher がキャッシュからファイルを削除します。Dispatcher は、そのページに対するクライアント要求を受信した場合にのみ、ファイルを再びキャッシュします。このようなやり方でキャッシュファイルを削除する方法は、同じページに対する要求を同時に受信する可能性が低い Web サイトに適しています。

HTTP 要求の形式は以下のとおりです。

POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
CQ-Handle: path-pattern
Content-Length: 0

Dispatcher は、CQ-Handler ヘッダーの値に一致する名前を持つ、キャッシュされたファイルおよびフォルダーをフラッシュ（削除）します。例えば、/content/geomtrixx-outdoors/en という CQ-Handle は、以下のアイテムに一致します。

Dispatcher キャッシュ内のその他すべてのファイル（または、/statfileslevel 設定によっては特定のレベルまで）は、.stat ファイルにタッチすることによって無効化されます。このファイルの最終変更日が、キャッシュされたドキュメントの最終更新日と比較され、.stat ファイルのほうが新しい場合はドキュメントが再取得されます。詳しくは、フォルダーレベルでのファイルの無効化を参照してください。

追加の CQ-Action-Scope: ResourceOnly ヘッダーを送信することによって、無効化（つまり .stat ファイルへのアクセス）を防ぐことができます。この機能を使用すると、特定のリソースをフラッシュできます。これらはすべて、JSON データなど、キャッシュの他の部分を無効にすることなく実行できます。そのデータは動的に作成され、キャッシュに関係なく、定期的にフラッシュする必要があります。例えば、ニュースや株価ティッカーなどを表示するためにサードパーティシステムから取得したデータを表します。

ファイルの削除と再キャッシュ delete-and-recache-files

HTTP リクエストを発行します。これにより、Dispatcher がキャッシュされているファイルを削除し、そのファイルを即座に取得して再キャッシュします。Web サイトが同じページに対するクライアント要求を同時に受信する可能性が高い場合は、ファイルを削除して即座に再キャッシュします。即時再キャッシュにより、Dispatcher は同時のクライアントリクエストそれぞれに対して 1 回ずつではなく、1 回だけページを取得してキャッシュします。

メモ： ​ファイルの削除と再キャッシュは、パブリッシュインスタンス上でのみ実行してください。オーサーインスタンスから実行すると、リソースを公開する前に再キャッシュが試みられた場合に、競合状態が発生します。

HTTP 要求の形式は以下のとおりです。

POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
`Content-Type: text/plain
CQ-Handle: path-pattern
Content-Length: numchars in bodypage_path0

page_path1
...
page_pathn

即時再キャッシュするページのパスは、メッセージ本文に別々の行として一覧表示されます。CQ-Handle の値は、再キャッシュするページを無効化するページのパスです。（キャッシュ設定項目の /statfileslevel パラメーターを参照してください）。以下の HTTP 要求メッセージの例では、/content/geometrixx-outdoors/en.html page ページを削除して再キャッシュします。

POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
Content-Type: text/plain
CQ-Handle: /content/geometrixx-outdoors/en/men.html
Content-Length: 36

/content/geometrixx-outdoors/en.html

サンプルのフラッシュサーブレット example-flush-servlet

以下のコードは、無効化リクエストを Dispatcher に送信するサーブレットを実装するものです。このサーブレットは、handle パラメーターと page パラメーターを含む要求メッセージを受信します。これらのパラメーターはそれぞれ、CQ-Handle ヘッダーの値と再キャッシュするページのパスを提供します。サーブレットは、その値を使用して、Dispatcher 向けの HTTP リクエストを組み立てます。

サーブレットをパブリッシュインスタンスにデプロイすると、次の URL によって、Dispatcher が /content/geometrixx-outdoors/en.html ページを削除し、新しいコピーをキャッシュします。

10.36.79.223:4503/bin/flushcache/html?page=/content/geometrixx-outdoors/en.html&handle=/content/geometrixx-outdoors/en/men.html

package com.adobe.example;

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Service;
import org.apache.felix.scr.annotations.Property;

import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.servlets.SlingSafeMethodsServlet;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.httpclient.methods.StringRequestEntity;

@Component(metatype=true)
@Service
public class Flushcache extends SlingSafeMethodsServlet {

 @Property(value="/bin/flushcache")
 static final String SERVLET_PATH="sling.servlet.paths";

 private Logger logger = LoggerFactory.getLogger(this.getClass());

 public void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) {
  try{
      //retrieve the request parameters
      String handle = request.getParameter("handle");
      String page = request.getParameter("page");

      //hard-coding connection properties is a bad practice, but is done here to simplify the example
      String server = "localhost";
      String uri = "/dispatcher/invalidate.cache";

      HttpClient client = new HttpClient();

      PostMethod post = new PostMethod("https://"+host+uri);
      post.setRequestHeader("CQ-Action", "Activate");
      post.setRequestHeader("CQ-Handle",handle);

      StringRequestEntity body = new StringRequestEntity(page,null,null);
      post.setRequestEntity(body);
      post.setRequestHeader("Content-length", String.valueOf(body.getContentLength()));
      client.executeMethod(post);
      post.releaseConnection();
      //log the results
      logger.info("result: " + post.getResponseBodyAsString());
      }
  }catch(Exception e){
      logger.error("Flushcache servlet exception: " + e.getMessage());
  }
 }
}