Otimização do cache do Dispatcher

Visão geral

Este artigo se concentra nas otimizações mais recentes no AEM dispatcher e a melhor forma de aproveitá-las.  O AEM dispatcher é um servidor proxy reverso de armazenamento em cache projetado para uso com o Adobe Experience Manager.  Ele poderá ser instalado e executado como um módulo no software de servidor da Web existente.  No momento da escrita deste artigo, o módulo dispatcher é compatível com o Apache HTTP Server, Microsoft IIS e iPlanet.

Como funciona o armazenamento em cache do Dispatcher

No nível mais básico, o AEM dispatcher é um proxy reverso que funciona realizando o armazenamento em cache, o esvaziamento do cache e a invalidação do cache.  

Veja os links relacionados para mais detalhes sobre o dispatcher:

  1. Como o dispatcher funciona e como instalá-lo.
  2. Opções de configuração disponíveis no dispatcher.
  3. Webinar sobre como o dispatcher funciona - note que algumas informações na apresentação são baseadas em versões antigas do dispatcher.
  4. Sessão de webinar do Gems sobre recursos do dispatcher, uso e segurança de CDN.
  5. Sessão do Gems sobre novos recursos no dispatcher (após a v4.1.9).

Otimização do Cache do Dispatcher

Aqui estão algumas maneiras de otimizar o cache do dispatcher:

  1. Faça cache de quase tudo - isso significa armazenar em cache todo o conteúdo que seria solicitado mais de uma vez pelos usuários.
  2. Armazenar conteúdo personalizado em cache por diferentes períodos de tempo - Se o seu site tiver conteúdo personalizado, considere usar o Apache Sling Dynamic Inclui em seu aplicativo AEM para aproveitar o Ajax (chamadas assíncronas de JavaScript e XML no nível do navegador), SSI (Server Side Inclui no nível do Servidor Web) e ESI (Edge-side Includes no nível CDN) para armazenar em cache partes diferentes da página por diferentes períodos de tempo.
  3. Nunca exclua o cache do distribuidor em um distribuidor em tempo real - Se um distribuidor estiver oferecendo conteúdo em tempo real e você excluir o cache, isso causará uma grande quantidade de solicitações para retornar ao AEM.  Devido a isso, o cache do dispatcher nunca deverá ser excluído em um live dispatcher.
  4. Priorize o cache - Antes de excluir o cache do dispatcher, retire o dispatcher do balanceador de carga, exclua o cache e execute uma ferramenta de crawler da web para armazenar em cache os arquivos no dispatcher antes de colocá-lo no balanceador de carga. 
  5. Páginas de erro de cache - Impulsione o DispatcherPassError 1 (Diretiva específica do Apache Web Server) para exibir páginas de erro, como 404s, do cache do dispatcher.
  6. A compactação de todos os tipos de arquivos em GZip, exceto aqueles pré-compactados - No Apache Web Server, mod_deflate poderá ser usado, mas certifique-se de que Vary: User-Agent cabeçalho não está definido.  No Microsoft IIS, use Compressão Dinâmica.
    Exemplo de configuração do Apache (que especifica apenas determinados tipos de conteúdo para evitar tipos de arquivos pré-compactados):
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
  7. Ativar /serveStaleOnError na configuração do /cache - exibe o arquivo de cache antigo quando as instâncias do AEM estão exibindo erros.
  8. Adicionar /gracePeriod à configuração do /cache - defina o número de segundos que um recurso obsoleto e invalidado automaticamente ainda poderá ser exibido no cache, após o último evento de publicação de conteúdo (“ativação”).  Isso reduz o número de solicitações que retornam às instâncias de publicação durante uma grande atividade de publicação de conteúdo, como uma “Ativação em árvore”.
  9. Adicione regras para /ignoreUrlParams - ignore os parâmetros de querystring que não são necessários ou não são usados pelo aplicativo.  Isso permite o armazenamento em cache de URLs, mesmo quando uma string de consulta está presente.
  10. Armazene em cache os cabeçalhos de resposta de Cache-Control e Last-Modified - Use a configuração dos /headers para armazenar em cache os cabeçalhos de resposta HTTP Controle de Cache e Last-modified (e/ou cabeçalho ETag, se você estiver enviando do AEM).  Isso ajuda a simplificar e otimizar o armazenamento em cache nos níveis de CDN e navegador.  Armazenar esses cabeçalhos em cache faz com que tão somente o AEM defina os cabeçalhos, não o servidor da web em si.  Observe que, quando você fizer isso, precisará começar a enviar os cabeçalhos a partir de seu aplicativo AEM.
  11. Armazenar conteúdo em cache pelo maior tempo possível e reduzir solicitações que retornam ao AEM - Otimize as solicitações de liberação ativando a liberação de busca em todos os agentes de liberação.  Ou use /enableTTL e defina o cabeçalho Cache-Control: max-age=... para armazenar em cache arquivos durante o maior tempo possível.  Consulte abaixo para detalhes sobre este tópico.

Uso de TTLs

A partir do Dispatcher versão 4.1.11, /enableTTL 1 poderá ser definido na configuração do arquivo .any.  Essa configuração faz com que o dispatcher respeite as expirações de cache definidas no cabeçalho de resposta HTTP do controle de cache.  Em outras palavras, o dispatcher funcionará de forma semelhante a um CDN no qual a forma principal de invalidação de cache ocorre quando os arquivos expiram.  Depois de implementar isso e começar a enviar Cache-Control: max-age=... para todas as respostas do AEM, você poderá desativar com segurança os agentes de liberação do dispatcher nas instâncias de publicação.

Após desabilitar agentes de limpeza nas instâncias de publicação, talvez você ainda queira liberar o cache do dispatcher.  Nesse caso, você poderá usar ACS Commons - Interface de liberação do Dispatcher.  Esta ferramenta está instalada na instância do autor.  Ela fornece aos usuários uma interface onde podem executar solicitações manuais de limpeza de cache.

I. Passos para ativar invalidações de estilo TTL ("Time to Live" ou expiração):

  1. Modificar o código-fonte no aplicativo AEM para enviar o cabeçalho Cache-Control e Last-Modified para todas as solicitações em que ele ainda não está definido.
  2. Instale o Dispatcher 4.1.11 ou posterior.
  3. Defina /enableTTL 1 na configuração do farm .any do site.
  4. Defina a configuração dos /headers para armazenar em cache os cabeçalhos Cacho-Control e Last-Modified.
  5. Reinicie o servidor da web.

II. Desative os agentes de liberação do dispatcher nas instâncias de publicação:

O dispatcher agora usará o cabeçalho Controle de Cache para controlar a invalidação dos arquivos de cache.  Como esse é o caso, a liberação do dispatcher a partir das instâncias de publicação não é mais necessária.

  1. Vá para /etc/replication/agents.publish.html em cada instância de publicação.
  2. Vá para a configuração de cada agente de limpeza e desabilite o agente.

III. Permitir solicitações de liberação manual do dispatcher da instância do autor:

Agora que os agentes de liberação estão desativados, você deverá confiar inteiramente no cabeçalho Controle de Cache para controlar quando o conteúdo será atualizado no dispatcher.  Você ainda poderá permitir que os usuários emitam liberações manuais do cache do dispatcher:

  1. Instale ACS Commons - Interface de Liberação do Dispatcher na instância do autor.
  2. Configure os agentes de limpeza na instância do autor.
  3. Em cada uma das configurações do agente, defina a opção Gatilhos => Ignorar Padrão para habilitado. Essa opção faz com que os agentes de limpeza ignorem quando os usuários clicam em Cancelar publicação ou (Des)Ativar na interface do AEM.

Recuperando a Liberação do Dispatcher

Para otimizar as solicitações de liberação do dispatcher, todos os agentes de liberação do dispatcher devem ter um recurso chamado liberação de recuperação ativado.

Para habilitar a nova busca de liberação do dispatcher, faça o seguinte:

  1. Vá para http://aemhost:port/crx/packmgr/index.jsp e faça o logon como administrador.
  2. Baixe o pacote aqui.
  3. Carregue e instale o pacote no gerenciador de pacotes.
  4. Vá para a configuração do agente de liberação do dispatcher. Por exemplo /etc/replication/agents.author/flush.html
  5. Clique em Editar
  6. Defina o seguinte
    • Tipo de serialização = Recuperar a liberação do Dispatcher
    • Estendido => Método HTTP = PUBLICAÇÃO
  7. Clique em Salvar

Observe que o pacote instalado acima é apenas um exemplo básico.  Para personalizar e otimizar o a liberação de recuperação, você poderá modificar a lista de URIs enviadas por ela.  O código é aberto e poderá ser encontrado aqui.  O código adiciona uma lista de URIs ao corpo da solicitação como parâmetros que dizem ao dispatcher quais caminhos deverão ser recuperados.  Você poderá adicionar mais caminhos, de acordo com os requisitos do seu aplicativo, para otimizar os recursos de armazenamento em cache do seu site.

Uma explicação mais detalhada da liberação de recuperação

Normalmente, um agente de liberação trabalha excluindo arquivos:

  1. Toque no(s) arquivo(s) .stat
  2. Excluir /content/foo.*
  3. Excluir /content/foo/_jcr_content

Devido ao fato de que os arquivos são excluídos na etapa 2, na próxima vez em que um usuário solicitar um arquivo como /content/foo.html ou /content/foo.json, enquanto o arquivo estiver sendo "recuperado", as solicitações subsequentes para o mesmo arquivo também serão enviadas para as instâncias de publicação até que o arquivo esteja armazenado em cache.  Para respostas lentas ou páginas de tráfego pesado, como páginas iniciais, isso poderá causar saturação da camada de instância de publicação.

Para resolver esse problema, ative um recurso do dispatcher chamado re-fetching.  Esse recurso permite que você envie uma lista de URIs que o dispatcher deverá "recuperar" de maneira proativa e substituir, em vez de excluí-los.

Consulte 22:41-27:05 nesta gravação de apresentação para uma demonstração de como isso funciona e como configurá-lo.

Logotipo da Adobe

Fazer logon em sua conta