Noções básicas sobre cache

Este documento explicará como o cache do dispatcher acontece e como ele pode ser configurado.

Diretórios de armazenamento em cache

Usamos os seguintes diretórios de cache padrão em nossas instalações de linha de base

  • Autor
    • /mnt/var/www/author
  • Editor
    • /mnt/var/www/html

Quando cada solicitação percorre o dispatcher, as solicitações seguem as regras configuradas para manter uma versão em cache local para a resposta dos itens qualificados.

Observação:

Mantemos intencionalmente a carga de trabalho publicada separada da carga de trabalho do autor, porque quando o Apache procura um arquivo no DocumentRoot, ele não sabe de qual instância do AEM ele veio.  Portanto, mesmo se o cache estiver desativado no farm do autor, se o DocumentRoot do autor for igual ao do editor, ele fornecerá arquivos do cache quando presentes.  Isso significa que você veiculará os arquivos do autor no cache publicado e proporcionará uma experiência de correspondência de mix muito ruim para os visitantes.

 

Manter diretórios DocumentRoot separados para diferentes conteúdos publicados também é uma péssima ideia.  Será necessário criar vários itens rearmazenados em cache que não são diferentes entre sites, como clientlibs, além de configurar um agente de liberação de replicação para cada DocumentRoot configurado.  Aumento do volume de liberação indireta a cada ativação da página.  Confie no namespace dos arquivos e nos caminhos em cache completos e evite vários DocumentRoot para sites publicados.

Arquivos de configuração

O Dispatcher controla o que é qualificado como armazenável em cache na seção de /cache { de qualquer arquivo farm.  Nos farms de configuração de linha de base do AMS, você encontrará nossas inclusões como mostrado abaixo:

/cache { 
    /rules { 
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any" 
    }

Ao criar as regras para o que deve ser armazenado em cache ou não, consulte a documentação aqui

Autor de armazenamento em cache

Vimos muitas implementações em que as pessoas não armazenam em cache o conteúdo do autor.  Elas estão perdendo uma grande atualização de desempenho e capacidade de resposta para os autores.

Vamos falar sobre a estratégia adotada para configurar o farm do autor para armazenar em cache corretamente.

Esta é uma seção básica de /cache { do autor do arquivo farm do autor:

/cache { 
    /docroot "/mnt/var/www/author" 
    /statfileslevel "2" 
    /allowAuthorized "1" 
    /rules { 
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any" 
    } 
    /invalidate { 
        /0000 { 
            /glob "*" 
            /type "allow" 
        } 
    } 
    /allowedClients { 
        /0000 { 
            /glob "*.*.*.*" 
            /type "deny" 
        } 
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_invalidate_allowed.any" 
    } 
}

É importante observar que o /docroot está definido para nós como o diretório de cache do autor.

Observação:

Verifique se o DocumentRoot no arquivo .vhost do autor corresponde ao parâmetro farms /docroot.

A instrução de inclusão das regras de cache inclui o arquivo /etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any que contém estas regras:

/0000 { 
 /glob "*" 
 /type "deny" 
} 
/0001 { 
 /glob "/libs/*" 
 /type "allow" 
} 
/0002 { 
 /glob "/libs/*.html" 
 /type "deny" 
} 
/0003 { 
 /glob "/libs/granite/csrf/token.json" 
 /type "deny" 
} 
/0004 { 
 /glob "/apps/*" 
 /type "allow" 
} 
/0005 { 
 /glob "/apps/*.html" 
 /type "deny" 
} 
/0006 { 
 /glob "/libs/cq/core/content/welcome.*" 
 /type "deny" 
}

Em um cenário do autor, o conteúdo muda constantemente e de propósito.  Você vai querer armazenar em cache apenas os itens que não serão alterados com frequência.  Temos regras para armazenar em cache /libs porque elas fazem parte da instalação do AEM de linha de base e seriam alteradas até a instalação de um Service Pack, Fix Pack cumulativo, Atualização ou Hotfix.  Portanto, armazenar em cache esses elementos faz muito sentido e realmente traz grandes benefícios à experiência do autor dos usuários finais que usam o site.

Observação:

Lembre-se de que essas regras também armazenam em cache /apps, é aqui que o código de aplicativo personalizado é ativado.  Se você estiver desenvolvendo seu código nessa instância, será muito confuso quando você salvar seu arquivo e não ver se reflete na interface do usuário devido ao envio de uma cópia em cache.  A intenção aqui é que, se você fizer uma implantação do seu código no AEM, isso também não seja frequente e parte de suas etapas de implantação refere-se a limpar o cache do autor.  Mais uma vez, o benefício é enorme, tornando seu código armazenável em cache mais rápido para os usuários finais.

ServeOnStale (AKA Serve on Stale / SOS )

Essa é uma daquelas jóias de um recurso do dispatcher.  Se o editor estiver sob carga ou deixar de responder, normalmente emitirá um código de resposta http 502 ou 503.  Se isso acontecer e esse recurso estiver ativado, o dispatcher será instruído a continuar a veicular o conteúdo que ainda estiver no cache da melhor maneira possível, mesmo que não seja uma cópia nova.  É melhor veicular algo que você entendeu do que apenas mostrar uma mensagem de erro que não oferece funcionalidade.

Observação:

Lembre-se de que, se o renderizador do editor atingir o tempo limite ou 500 mensagens de erro, esse recurso não será acionado.  Se o AEM estiver inacessível, esse recurso não fará nada

Essa configuração pode ser definida em qualquer farm, mas só faz sentido aplicá-la nos arquivos farm de publicação.  Este é um exemplo de sintaxe do recurso habilitado em um arquivo farm:

/cache { 
    /serveStaleOnError "1"

Armazenamento em cache com parâmetros / argumentos de consulta

Observação:

Um dos comportamentos normais do módulo Dispatcher é que, se uma solicitação tiver um parâmetro de consulta no URI (normalmente mostrado como /content/page.html?myquery=value), ignorará o armazenamento em cache do arquivo e irá diretamente para a instância do AEM.  Ele considera essa solicitação uma página dinâmica e não deve ser armazenada em cache.  Isso pode causar efeitos na eficiência do cache

Se você possui páginas no AEM que aceitam argumentos GET / parâmetros de consulta na linha de endereço que ajudam a página a operar, mas não renderiza html diferente, elas são boas candidatas para esse elemento de configuração.

Você pode determinar os argumentos que o dispatcher deve ignorar e ainda armazenar em cache a página.

Por exemplo, alguém criou um mecanismo de referência de link direto de mídia social que usa a referência de argumento no URI para saber de onde a pessoa veio.

Exemplo de uso:

https://www.weretail.com/home.html?reference=android

https://www.weretail.com/home.html?reference=facebook

A página é 100% armazenável em cache, mas não é armazenada em cache porque os argumentos estão presentes.  Para contornar isso, adicionamos a seguinte seção ao arquivo de configuração farm:

/cache { 
    /ignoreUrlParams { 
        /0001 { /glob "*" /type "deny" } 
        /0002 { /glob "reference" /type "allow" } 
    }

Agora, quando o dispatcher vê a solicitação, ele ignora o fato de que a solicitação possui o parâmetro de consulta de referência e ainda armazena em cache a página

Armazenamento em cache dos cabeçalhos de resposta

É bastante óbvio que o dispatcher armazena em cache as páginas .html e clientlibs, mas você sabia que ele também pode armazenar em cache os cabeçalhos de resposta específicos ao lado do conteúdo de um arquivo com o mesmo nome, mas com uma extensão de arquivo .h.  Isso permite que a próxima resposta não apenas para o conteúdo, mas também para os cabeçalhos de resposta que devem acompanhá-la no cache. 

O AEM pode lidar com mais do que apenas codificação UTF-8 (grande sorriso)

Às vezes, os itens têm cabeçalhos especiais que ajudam a controlar os detalhes de codificação do cache TTL e os carimbos de data e hora da última modificação.

Esses valores, quando armazenados em cache, são removidos por padrão e o servidor Web apache httpd fará seu próprio trabalho de processar o ativo com seus métodos normais de manipulação de arquivos, que normalmente são limitados à adivinhação do tipo MIME com base nas extensões de arquivo.

Se o dispatcher armazenar em cache o ativo e os cabeçalhos desejados, você poderá expor a experiência adequada e garantir que todos os detalhes cheguem ao navegador do cliente.

Este é um exemplo de um farm com os cabeçalhos para cache especificados:

/cache { 
 /headers { 
  "Cache-Control" 
  "Content-Disposition" 
  "Content-Type" 
  "Expires" 
  "Last-Modified" 
  "X-Content-Type-Options" 
 } 
}

No exemplo, eles configuraram o AEM para veicular os cabeçalhos procurados pela CDN para saber quando invalidar o cache.  Isso significa que agora o AEM pode determinar corretamente os arquivos que são invalidados com base nos cabeçalhos.

Observação:

Lembre-se de que você não pode usar expressões regulares ou correspondência de glob.  É uma lista literal dos cabeçalhos a serem armazenados em cache.  Coloque apenas uma lista dos cabeçalhos literais que você deseja que ele armazene em cache.

Invalidação automática do período de carência

Nos sistemas AEM que possuem muita atividade de autores que realizam várias ativações de página, é possível ter uma condição de corrida na qual ocorrem repetidas invalidações.  Solicitações de liberação com bastante repetição são desnecessárias e você pode criar certa tolerância para não repetir uma liberação até que o período de carência seja limpo.

Exemplo de como funciona:

Se você tiver 5 solicitações para invalidar /content/exampleco/pt/, tudo ocorrerá dentro de um período de 3 segundos.

Com esse recurso desativado, você invalidará o diretório de cache /content/exampleco/pt/ 5 vezes

Com esse recurso ativado e definido como 5 segundos, invalidaria o diretório de cache /content/exampleco/pt/ uma vez

Este é um exemplo de sintaxe desse recurso configurado por 5 segundos de carência:

/cache { 
    /gracePeriod "5"

Invalidação baseada em TTL

Um recurso mais recente do módulo Dispatcher é o Time To Live (TTL) com base nas opções de invalidação para itens armazenados em cache.  Quando um item é armazenado em cache, ele procura a presença de cabeçalhos de controle de cache e gera um arquivo no diretório de cache com o mesmo nome e a extensão .ttl

Este é um exemplo do recurso configurado no arquivo de configuração farm:

/cache { 
    /enableTTL "1"
Observação:

Lembre-se de que o AEM ainda precisa ser configurado para enviar cabeçalhos TTL para serem utilizados pelo dispatcher.  A alternância desse recurso permite que o dispatcher saiba quando remover os arquivos para os quais o AEM enviou cabeçalhos de controle de cache.  Se o AEM não começar a enviar cabeçalhos TTL, o dispatcher não fará nada de especial aqui.

Regras de filtro de cache

Este é um exemplo de uma configuração de linha de base para os elementos que serão armazenados em cache em um editor:

/cache{ 
    /0000 { 
        /glob "*" 
        /type "allow" 
    } 
    /0001 { 
        /glob "/libs/granite/csrf/token.json" 
        /type "deny" 
    }

Queremos que o site publicado se torne o mais ambicioso possível e armazene tudo em cache.

Se houver elementos que interrompem a experiência quando armazenados em cache, você pode adicionar regras para remover a opção de armazenar em cache esse item.  Como você vê no exemplo acima, os tokens csrf nunca devem ser armazenados em cache e foram excluídos.  Mais detalhes sobre como a gravação dessas regras podem ser encontrados aqui.

Logotipo da Adobe

Fazer logon em sua conta