Como otimizar o cache do Dispatcher?
Este artigo oferece instruções detalhadas sobre as diferentes maneiras de otimizar o cache do Dispatcher. Ele descreve ainda as etapas para ativar invalidações de estilo TTL ("Time to Live" ou expiração), desativação de agentes de limpeza do Dispatcher, nova busca de limpeza do Dispatcher, entre outras.
Descrição description
Ambiente
Adobe Experience Manager
Problemas/Sintomas
Este artigo se concentra nas otimizações mais recentes no AEM Dispatcher e como aproveitá-las melhor. O AEM Dispatcher é um servidor de cache proxy reverso criado para ser usado com o Adobe Experience Manager. Ele pode ser instalado e executado como um módulo em um software de servidor Web existente. No momento em que este artigo foi escrito, o módulo Dispatcher era suportado no Apache HTTP Server, Microsoft IIS e iPlanet.
Resolução resolution
Como funciona o 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 a Dispatcher:
- Como o Dispatcher funciona e como instalá-lo.
- Opções de configuração disponíveis no Dispatcher.
- Webinar sobre como o Dispatcher funciona - observe que algumas informações na apresentação são baseadas em versões antigas do dispatcher.
- Sessão de webinar do Gems sobre recursos do Dispatcher, uso e segurança de CDN.
- Sessão do Gems sobre recursos mais recentes no Dispatcher (após a v4.1.9).
Otimizando o cache do Dispatcher
Estas são algumas maneiras de otimizar o cache do Dispatcher:
-
Armazenar quase tudo em cache - Isso significa armazenar em cache todo o conteúdo que seria solicitado mais de uma vez pelos usuários.
-
Armazenar conteúdo personalizado em cache por diferentes períodos - Se o seu site tiver conteúdo personalizado, considere usar Apache Sling Dynamic Includes no aplicativo AEM para usar 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.
-
Nunca exclua o cache do Dispatcher em uma Dispatcher ativa - Se uma Dispatcher AEM estiver oferecendo conteúdo ativo e você excluir o cache, isso causará uma grande quantidade de solicitações para retornar ao. Por isso, o cache do Dispatcher nunca deve ser excluído em um Dispatcher ativo.
-
Priorizar o cache - Antes de excluir o cache do Dispatcher, puxe o Dispatcher do balanceador de carga, exclua o cache e execute uma ferramenta de crawler da Web para armazenar em cache arquivos no Dispatcher antes de colocá-lo no balanceador de carga.
-
Páginas de erro de cache - Use a diretiva DispatcherPassError 1 (específica do Apache Web Server) para ver páginas de erro do servidor, como 404s, do cache do Dispatcher.
-
Compactar todos os tipos de arquivos com GZip, exceto os pré-compactados - No Apache Web Server, mod_deflate pode ser usado, mas verifique se Vary: User-Agent header 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
-
Habilitar /serveStaleOnError na /configuração de cache - Fornece o arquivo de cache antigo quando instâncias AEM exibem erros.
-
Adicionar /gracePeriod à configuração /cache - defina o número de segundos 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”.
-
Adicionar regras a /ignoreUrlParams - Ignorar 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.
-
Armazenar em cache os cabeçalhos de resposta de Cache-Control e Last-Modified - Use a configuração /header para armazenar em cache os cabeçalhos de resposta HTTP Cache-Control e o cabeçalho Last-Modified (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.
-
Armazenar conteúdo em cache o máximo possível e reduzir solicitações que retornam ao AEM - Otimizar solicitações de liberação habilitando a nova busca em todos os agentes de limpeza. Consulte a seção abaixo intitulada Nova busca da limpeza do Dispatcher. 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 obter detalhes sobre este tópico.
Usando TTLs
A partir do Dispatcher versão 4.1.11, /enableTTL 1 poderá ser definido em qualquer configuração de arquivo. 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 desabilitar com segurança seus agentes de liberação do Dispatcher nas instâncias de publicação.
Depois de desativar 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):
- Modifique o código-fonte no aplicativo AEM para enviar o cabeçalho Cache-Control e Last-Modified para todas as solicitações em que ainda não foi definido.
- Instale o Dispatcher 4.1.11 ou posterior.
- Defina /enableTTL 1 em qualquer configuração de farm do site.
- Defina a configuração /cabeçalhos para armazenar em cache os cabeçalhos Cache-Control e Last-Modified.
- Reinicie o servidor Web.
II. Desabilitar agentes de liberação 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.
- Acesse /etc/replication/agents.publish.html em cada instância de publicação.
- 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 limpeza estão desativados, você dependeria totalmente do cabeçalho Cache-Control para controlar quando o conteúdo é atualizado no dispatcher. Você ainda pode permitir que os usuários emitam limpezas manuais do cache do Dispatcher:
- Instalar o ACS Commons - Dispatcher Flush UI na instância do autor.
- Configure os agentes de limpeza na instância do autor.
- Em cada uma das configurações do agente, defina Acionadores =
>
Ignorar a opção Padrão para habilitada. 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.
Recuperando a Liberação 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 ativar a recuperação de limpeza do dispatcher, faça o seguinte:
-
Acesse http://aemhost:port/crx/packmgr/index.jsp e faça logon como administrador.
-
Baixe o pacote aqui.
-
Faça upload e instale o pacote no gerenciador de pacotes.
-
Vá para a configuração do agente de limpeza do Dispatcher. Por exemplo /etc/replication/agents.author/flush.html
-
Clique em Editar
-
Defina o seguinte
- Tipo de serialização = Recuperar limpeza do Dispatcher
- Estendido =
>
Método HTTP = POST
-
Clique em Salvar
Observação - 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.
Explicação detalhada da nova busca de liberação
Normalmente, uma liberação do Dispatcher funciona excluindo arquivos:
- Toque em arquivo(s) .stat
- Exclua /content/foo.*
- 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 da Dispatcher chamado rebusca. Esse recurso permite enviar uma lista de URIs que o Dispatcher deve "buscar novamente" de forma 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.