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 estiver ativado 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.

Cache

HTML/Texto

  • por padrão, armazenado em cache pelo navegador por cinco minutos, com base no cabeçalho cache-control emitido pela camada de cache. O CDN também respeita esse valor.
  • a configuração padrão de armazenamento em cache de HTML/Texto pode ser desativada definindo a variável DISABLE_DEFAULT_CACHING em global.vars:
Define DISABLE_DEFAULT_CACHING

Isso pode ser útil, por exemplo, quando sua lógica comercial requer o ajuste fino do cabeçalho da idade (com um valor baseado no dia do calendário), já que, por padrão, o cabeçalho da idade está definido como 0. Dito isso, tenha cuidado ao desativar o cache padrão.

  • pode ser substituída para todo o conteúdo HTML/Texto definindo a variável EXPIRATION_TIME 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 "^/content/.*\.(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 "^/content/.*\.(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 tenha 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 private. Por exemplo, o seguinte impediria que o conteúdo html em um diretório chamado myfolder fosse armazenado em cache:

       <LocationMatch "/content/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 diretivas apache mod_headers:

       <LocationMatch "^/content/.*\.(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ó

  • sem cache padrão
  • o padrão não pode ser definido com a variável EXPIRATION_TIME 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 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 API invalidate.cache (por exemplo, POST /dispatcher/invalidate.cache)

A abordagem da API invalidate.cache do dispatcher não será mais suportada, pois trata apenas de 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 Invalidar 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 descarga do cache, consulte a página de exemplo da API especificamente o exemplo CustomStep 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 ](https://helpx.adobe.com/br/support.ec.html), 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 Javascript e CSS para páginas HTML, levando em conta as dependências entre bibliotecas 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 Cloud Service SDK Início rápido

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

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free