Introdução

O tráfego passa pelo CDN para uma camada do servidor da Web apache, que suporta módulos incluindo o dispatcher. Para aumentar o desempenho, o dispatcher é usado principalmente como cache para limitar o processamento nos nós de publicação.
As regras podem ser aplicadas à configuração do despachante para modificar qualquer configuração de expiração de cache padrão, resultando em cache no CDN. Observe que o dispatcher também respeita os cabeçalhos de expiração do cache resultante se enableTTL estiverem ativados na configuração do dispatcher, o que significa que ele atualizará conteúdo específico mesmo fora do conteúdo que está sendo republicado.

Esta página também descreve como o cache do dispatcher é invalidado, bem como como o cache funciona no nível do navegador em relação às bibliotecas do lado do cliente.

Caching

HTML/Texto

  • por padrão, armazenado em cache pelo navegador por cinco minutos, com base no cabeçalho de controle de cache emitido pela camada de cache. O CDN também respeita esse valor.

  • pode ser substituída para todo o conteúdo HTML/Texto definindo a EXPIRATION_TIME variável em global.vars usando o AEM como ferramentas do Dispatcher do Cloud Service SDK.

  • pode ser substituído em um nível de granulado mais fino pelas seguintes diretivas apache mod_headers:

    <LocationMatch "\.(html)$">
         Header set Cache-Control "max-age=200"
         Header set Age 0
    </LocationMatch>
    

    Tenha cuidado ao definir cabeçalhos de controle de cache global ou aqueles que correspondem a um regex amplo, de modo que não sejam aplicados ao conteúdo que você deseja manter privado. Considere o uso de várias diretivas para garantir que as regras sejam aplicadas de forma refinada. Dito isso, AEM como um Cloud Service removerá o cabeçalho do cache se ele detectar que foi aplicado ao que detecta ser inatingível pelo dispatcher, conforme descrito na documentação do dispatcher. Para forçar o AEM a sempre aplicar o cache, é possível adicionar a opção "sempre" da seguinte maneira:

    <LocationMatch "\.(html)$">
         Header always set Cache-Control "max-age=200"
         Header set Age 0
    </LocationMatch>
    

    Você deve garantir que um arquivo em src/conf.dispatcher.d/cache tem a seguinte regra (que está na configuração padrão):

    /0000
    { /glob "*" /type "allow" }
    
  • Para impedir que o conteúdo específico seja armazenado em cache, defina o cabeçalho Cache-Control como particular. Por exemplo, o seguinte impediria que o conteúdo html em um diretório chamado myfolder fosse armazenado em cache:

       <LocationMatch "/myfolder/.*\.(html)$">.  // replace with the right regex
       Header set Cache-Control “private”
      </LocationMatch>
    
    Observação

    Os outros métodos, incluindo o projeto dispatcher-ttl AEM ACS Commons, não substituirão valores com êxito.

Bibliotecas do lado do cliente (js,css)

  • ao usar AEM estrutura de biblioteca do lado do cliente, o JavaScript e o código CSS são gerados de forma que os navegadores possam armazená-los em cache indefinidamente, já que qualquer alteração é manifestada como novos arquivos com um caminho exclusivo. Em outras palavras, o HTML que faz referência às bibliotecas do cliente será produzido conforme necessário para que os clientes possam experimentar novo conteúdo conforme ele é publicado. O controle de cache é definido como "imutável" ou 30 dias para navegadores mais antigos que não respeitam o valor "imutável".
  • consulte a seção Bibliotecas do lado do cliente e consistência da versão para obter mais detalhes.

Imagens e qualquer conteúdo grande o suficiente armazenado no armazenamento blob

  • por padrão, não armazenado em cache

  • pode ser definido em um nível de granulado mais fino pelas seguintes mod_headers diretivas de cache:

       <LocationMatch "^\.*.(jpeg|jpg)$">
         Header set Cache-Control "max-age=222"
         Header set Age 0
       </LocationMatch>
    

    Consulte a discussão na seção html/texto acima para ter cuidado para não armazenar em cache muito grande e também para forçar a AEM a sempre aplicar o cache com a opção "sempre".

    É necessário garantir que um arquivo em src/conf.dispatcher.d/cache tenha a seguinte regra (que está na configuração padrão):

    /0000
    { /glob "*" /type "allow" }
    

    Certifique-se de que os ativos destinados a serem mantidos privados em vez de armazenados em cache não façam parte dos filtros da diretiva LocationMatch.

    Observação

    Os outros métodos, incluindo o projeto dispatcher-ttl AEM ACS Commons, não substituirão valores com êxito.

Outros tipos de arquivos de conteúdo no armazenamento de nós

  • sem cache padrão
  • o padrão não pode ser definido com a EXPIRATION_TIME variável usada para tipos de arquivos html/text
  • a expiração do cache pode ser definida com a mesma estratégia LocationMatch descrita na seção html/texto especificando o regex apropriado

Invalidação do Cache do Dispatcher

Em geral, não será necessário invalidar o cache do dispatcher. Em vez disso, você deve confiar no dispatcher atualizando seu cache quando o conteúdo estiver sendo republicado e o CDN respeitar os cabeçalhos de expiração do cache.

Invalidação do Cache do Dispatcher durante Ativação/Desativação

Como nas versões anteriores do AEM, publicar ou desfazer a publicação de páginas limpará o conteúdo do cache do dispatcher. Se houver suspeita de um problema de armazenamento em cache, os clientes devem republicar as páginas em questão.

Quando a instância de publicação recebe uma nova versão de uma página ou ativo do autor, ela usa o agente de liberação para invalidar os caminhos apropriados em seu dispatcher. O caminho atualizado é removido do cache do dispatcher, juntamente com seus pais, até um nível mais alto (você pode configurar isso com o nívelde statfileslevel.

Invalidação explícita do cache do dispatcher

Em geral, não será necessário invalidar manualmente o conteúdo no dispatcher, mas é possível se necessário, conforme descrito abaixo.

Antes de AEM como um Cloud Service, havia duas maneiras de invalidar o cache do dispatcher.

  1. Chame o agente de replicação, especificando o agente de liberação do dispatcher de publicação
  2. Chamando diretamente a invalidate.cache API (por exemplo, POST /dispatcher/invalidate.cache)

A abordagem da invalidate.cache API do dispatcher não será mais suportada, pois ela aborda somente um nó de dispatcher específico. AEM como um Cloud Service opera no nível de serviço, não no nível de nó individual e, portanto, as instruções de invalidação na página Invalidando Páginas em Cache de AEM não são mais válidas para AEM como Cloud Service.
Em vez disso, o agente de liberação de replicação deve ser usado. Isso pode ser feito usando a API de replicação. A documentação da API de replicação está disponível aqui e, para obter um exemplo de como limpar o cache, consulte a página de exemplo da API especificamente o CustomStep exemplo que emite uma ação de replicação do tipo ATIVATE para todos os agentes disponíveis. O ponto de extremidade do agente de liberação não é configurável, mas pré-configurado para apontar para o dispatcher, correspondente ao serviço de publicação que executa o agente de liberação. O agente de descarga normalmente pode ser acionado por eventos ou workflows OSGi.

O diagrama apresentado abaixo ilustra isso.

Se houver uma preocupação de que o cache do dispatcher não esteja sendo apagado, entre em contato com o suporte ao cliente que pode liberar o cache do dispatcher, se necessário.

O CDN gerido pelo Adobe respeita os TTLs e, por conseguinte, não há necessidade de o eliminar. Se houver suspeita de um problema, entre em contato com o suporte ao cliente que pode liberar um cache de CDN gerenciado por Adobe, conforme necessário.

Bibliotecas do lado do cliente e consistência da versão

As páginas são compostas de HTML, Javascript, CSS e imagens. Os clientes são incentivados a aproveitar a estrutura de Bibliotecas do lado do cliente (clientlibs) para importar recursos do Javascript e CSS para páginas HTML, levando em conta as dependências entre as bibliotecas do JS.

A estrutura clientlibs fornece gerenciamento automático de versões, o que significa que os desenvolvedores podem fazer check-in das alterações nas bibliotecas JS no controle de origem e a versão mais recente será disponibilizada quando um cliente fizer o lançamento. Sem isso, os desenvolvedores precisariam alterar manualmente o HTML com referências à nova versão da biblioteca, que é especialmente onerosa se muitos modelos HTML compartilharem a mesma biblioteca.

Quando as novas versões das bibliotecas são lançadas para produção, as páginas HTML de referência são atualizadas com novos links para essas versões atualizadas da biblioteca. Depois que o cache do navegador expirar para uma determinada página HTML, não há preocupação de que as bibliotecas antigas sejam carregadas do cache do navegador, pois a página atualizada (do AEM) agora é garantida para fazer referência às novas versões das bibliotecas. Em outras palavras, uma página HTML atualizada incluirá todas as versões mais recentes da biblioteca.

O mecanismo para isso é um hash serializado, que é anexado ao link da biblioteca do cliente, garantindo um url exclusivo com versão para que o navegador armazene o CSS/JS em cache. O hash serializado só é atualizado quando o conteúdo da biblioteca do cliente é alterado. Isso significa que se ocorrerem atualizações não relacionadas (ou seja, sem alterações no css/js subjacente da biblioteca do cliente) mesmo com uma nova implantação, a referência permanecerá a mesma, garantindo menos interrupção no cache do navegador.

Ativação das versões do Longcache das bibliotecas do lado do cliente - AEM como um Início rápido do Cloud Service SDK

A clientlib padrão inclui em uma página HTML como o exemplo a seguir:

<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.css" type="text/css">

Quando o controle de versão restrito do clientlib está ativado, uma chave hash de longo prazo é adicionada como seletor à biblioteca do cliente. Como resultado, a referência clientlib se parece com:

<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.lc-7c8c5d228445ff48ab49a8e3c865c562-lc.css" type="text/css">

O controle de versão restrito do clientlib é ativado por padrão em todos os AEM como ambientes Cloud Service.

Para ativar o controle de versão restrito do clientlib no Início rápido do SDK local, execute as seguintes ações:

  1. Navegue até o Gerenciador de configuração do OSGi <host>/system/console/configMgr
  2. Localize o Gerenciador de biblioteca HTML Config do OSGi para o Adobe Granite:
    • Marque a caixa de seleção para ativar o Controle de versão restrito
    • No campo rotulado Chave de cache do lado do cliente de longo prazo, digite o valor de /.*;hash
  3. Salve as alterações. Observe que não é necessário salvar essa configuração no controle de origem, pois AEM como Cloud Service habilitará automaticamente essa configuração em ambientes dev, stage e production.
  4. Sempre que o conteúdo da biblioteca do cliente for alterado, uma nova chave hash será gerada e a referência HTML será atualizada.

Nesta página