Como otimizar o cache do Dispatcher

Descrição

Ambiente

  • Experience Manager



 

Problemas/Sintomas
Este artigo se concentra nas otimizações mais recentes no AEM Dispatcher e como aproveitá-las melhor. O despachante do AEM é um armazenamento em cache proxy reverso para uso com o Adobe Experience Manager. Ele pode ser instalado e executado como um módulo no software de servidor da Web existente. No momento em que este artigo foi escrito, a o módulo dispatcher é compatível no Apache HTTP Server, Microsoft IIS e iPlanet.

Resolução

Funcionamento do armazenamento em cache do Dispatcher

No nível mais básico, o AEM dispatcher é um proxy reverso que funciona por meio do armazenamento em cache, liberação de cache e invalidação de cache.

Consulte os links relacionados para obter 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: observe 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 recursos mais recentes no dispatcher (após a v4.1.9).

Otimização do cache do Dispatcher

Estas são algumas maneiras de otimizar o cache do dispatcher:

  1. Armazenar quase tudo em cache: 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 - Se o site tiver conteúdo personalizado, considere usar Apache Sling Dynamic Includes no aplicativo AEM para aproveitar o Ajax (Chamadas assíncronas de JavaScript e XML no nível do navegador), SSI (Server Side Includes no nível do Servidor da Web) e ESI (Edge-Side Includes no nível CDN) para armazenar em cache diferentes partes da página por diferentes períodos.

  3. Nunca exclua o cache do dispatcher em um live dispatcher: se um dispatcher estiver disponibilizando conteúdo ao vivo e você excluir o cache, isso causará uma grande quantidade de solicitações para retornar ao AEM.  Por isso, o cache do dispatcher nunca deve 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 - Aproveite o DispatcherPassError 1 (Específica do Apache Web Server) para servir páginas de erro, como 404s, do cache do dispatcher.

  6. Compactar todos os tipos de arquivos com GZip, exceto os pré-compactados - No Apache Web Server, mod_deflate poderia ser usado, mas verifique se Vary: usuário-agente cabeçalho não está definido.  No Microsoft IIS, use Compactação dinâmica.

    Exemplo de configuração do Apache (especificando 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 /cache - exibe o arquivo de cache antigo quando instâncias AEM exibem erros.

  8. Adicionar /gracePeriod para a configuração /cache - defina o número de segundos em que um recurso obsoleto e invalidado automaticamente ainda pode ser enviado do 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. Adicionar regras a /ignoreUrlParams: ignore os parâmetros querystring que não são necessários ou usados pelo aplicativo.  Isso permite o armazenamento em cache de URLs, mesmo quando uma string de consulta está presente.

  10. Armazenar em cache os cabeçalhos de resposta de Cache-Control e Last-Modified - Use o /headers configuração para armazenar em cache os cabeçalhos de resposta HTTP Controle de cache e Última modificação (e/ou ETag se 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 o AEM apenas defina os cabeçalhos, não o próprio servidor da Web.  Observe que, quando você fizer isso, precisará começar a enviar os cabeçalhos do aplicativo AEM.

  11. Armazenar conteúdo em cache o máximo possível e reduzir solicitações que retornam ao AEM: otimizar solicitações de limpeza ativando a nova busca em todos os agentes de limpeza.  Ou use /enableTTL e defina Cache-Control: max-age=… para armazenar arquivos em cache o máximo possível.  Consulte abaixo para obter detalhes sobre este tópico.

Utilização de TTLs

A partir do Dispatcher versão 4.1.11, /enableTTL 1 pode ser definido na configuração do arquivo .any.  Essa configuração faz com que o dispatcher respeite as expirações do cache definidas no cabeçalho de resposta Cache-Control HTTP.  Em outras palavras, o dispatcher funcionará de forma semelhante a um CDN, em que 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ê pode desativar com segurança os agentes de limpeza do dispatcher nas instâncias de publicação.

Depois de desabilitar agentes de limpeza nas instâncias de publicação, talvez você ainda queira limpar o cache do dispatcher.  Nesse caso, você pode usar ACS Commons - Dispatcher Flush UI.  Essa ferramenta é instalada na instância do autor.  Ela fornece aos usuários uma interface onde é possível executar solicitações manuais de limpeza de cache.

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

  1. Modifique o código-fonte no aplicativo AEM para enviar Controle de cache cabeçalho e Última modificação para todas as solicitações em que ainda não foi definido.
  2. Instale o Dispatcher 4.1.11 ou posterior.
  3. Definir /enableTTL 1 na configuração .any farm do site.
  4. Defina o /headers configuração para armazenar em cache o Controle de cache e Última modificação cabeçalhos.
  5. Reinicie o servidor Web.

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

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

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

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

Agora que os agentes de limpeza estão desativados, você dependeria totalmente da Controle de cache cabeçalho para controlar quando o conteúdo é atualizado no dispatcher.  Você ainda pode permitir que os usuários emitam limpezas manuais do cache do dispatcher:

  1. Instalar o ACS Commons - Dispatcher Flush UI 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 Acionadores = Ignorar padrão como habilitado. Essa opção faz com que os agentes de limpeza sejam ignorados quando os usuários clicam em Publicar/Cancelar publicação ou Ativar/Desativar na interface do usuário do AEM.

Recuperação da limpeza do Dispatcher

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

Para habilitar a recuperação de limpeza do dispatcher, faça o seguinte:

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

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

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

Normalmente, uma liberação do dispatcher funciona excluindo arquivos:

  1. Toque em arquivo(s) .stat
  2. Exclua /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 que um usuário solicitar um arquivo como /content/foo.html ou /content/foo.json, enquanto o arquivo está sendo "buscado novamente", as solicitações subsequentes do mesmo arquivo também seriam enviadas para as instâncias de publicação até que o arquivo fosse armazenado em cache.  Para respostas lentas ou páginas de tráfego pesado, como páginas iniciais, isso pode causar inundação do nível de instância de publicação.

Para resolver esse problema, ative um recurso do dispatcher chamado rebusca.  Esse recurso permite enviar uma lista de URIs que o dispatcher deve “buscar novamente” de maneira proativa e substituir, em vez de excluir.

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

Nesta página