Como entender diretórios de armazenamento em cache

Descrição

Ambiente
Adobe Experience Manager

Problema/Sintomas
Este documento explica como o cache do dispatcher acontece e como ele pode ser configurado.
Índice

Resolução

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 da resposta de itens elegíveis.

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 AEM veio. Portanto, mesmo que o cache esteja desativado no farm do autor, se o DocumentRoot do autor for o mesmo que o editor, ele fornecerá arquivos do cache quando presentes. Isso significa que você fornecerá arquivos de autor do cache publicado e proporcionará uma experiência de correspondência de mix muito ruim para seus 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 sejam diferentes entre sites, como clientlibs, bem como configurar um agente de liberação de replicação para cada DocumentRoot configurado, aumentando a sobrecarga de liberação com cada ativação de página. Confie no namespace dos arquivos e em seus caminhos em cache completos e evite várias DocumentRoots para sites publicados.

Arquivos de configuração

O Dispatcher controla o que é qualificado como armazenável em cache na seção /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 here

Autor do armazenamento em cache

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

Vamos discutir a estratégia adotada na configuração do farm do autor para armazenar em cache corretamente.

Esta é uma seção base de criação/cache 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"
    }
}

O importante a ser observado aqui é que a variável /docroot é definido como o diretório de cache do autor.

Observação:

Certifique-se de que 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 de criação, o conteúdo muda o tempo todo e de propósito. Você deseja armazenar em cache apenas itens que não serão alterados com frequência.
Temos regras para armazenar em cache /libs porque elas fazem parte da instalação da AEM de linha de base e seriam alteradas até que você tenha instalado um Service Pack, Cumulative Fix Pack, Upgrade ou Hotfix. Armazenar esses elementos em cache faz muito sentido e realmente beneficia a experiência de criação de 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 está ativo. Se você estiver desenvolvendo seu código nessa instância, será muito confuso salvar seu arquivo e não ver se ele reflete na interface do usuário devido ao fornecimento 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 será pouco frequente e parte de suas etapas de implantação deverá ser limpar o cache do autor. Novamente, o benefício é enorme, tornando seu código armazenável em cache mais rápido para os usuários finais.

ServeOnStale (AKA Serve no Stale / SOS)

Esta é uma daquelas joias de um recurso do dispatcher. Se o editor estiver sob carga ou não responder, ele normalmente lançará um código de resposta http 502 ou 503. Se isso acontecer e esse recurso estiver ativado, o dispatcher será instruído a ainda servir qualquer conteúdo que ainda esteja no cache como um melhor esforço, mesmo que não seja uma cópia nova. É melhor servir algo se tiver algo em mente do que apenas mostrar uma mensagem de erro que não oferece funcionalidade.

Observação:

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

Essa configuração pode ser definida em qualquer farm, mas aplicá-la aos arquivos farm publicados faz sentido. Este é um exemplo de sintaxe do recurso ativado em um arquivo farm:

/cache {
    /serveStaleOnError "1"

Armazenamento de páginas 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 de AEM. Ela está considerando essa solicitação como uma página dinâmica e não deve ser armazenada em cache. Isso pode causar um efeito incorreto na eficiência do cache.

Se você tiver páginas em AEM que aceitam argumentos GET/parâmetros de consulta na linha de endereço que ajudam a página a operar, mas não renderizam HTML diferentes, elas serão boas candidatas para esse elemento de configuração.

Você pode informar ao dispatcher quais argumentos ignorar e ainda armazenar em cache a página.

Como exemplo, alguém criou um mecanismo de referência de deep link 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.retail.com/home.html?reference=android

https://www.retail.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 ignorará o fato de que a solicitação tem o parâmetro de consulta de referência e ainda armazena em cache a página.

Armazenamento em cache de cabeçalhos de resposta

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

AEM pode lidar com mais do que apenas codificação UTF-8.

À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 processamento do ativo com seus métodos normais de manipulação de arquivos, que normalmente é limitado à adivinhação de tipo MIME com base em 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 a cheguem ao navegador dos clientes.

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

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

No exemplo, eles configuraram AEM para fornecer cabeçalhos que a CDN procura para saber quando invalidar seu cache. Isso significa que agora AEM pode ditar corretamente quais arquivos são invalidados com base em cabeçalhos.

Observação:

Lembre-se de que não é possível 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.

Período de carência de invalidação automática

Em sistemas de AEM com muita atividade de autores que fazem muitas ativações de página, você pode ter uma condição de corrida em que ocorrem invalidações repetidas. Solicitações de liberação com muitas repetições são desnecessárias e você pode criar alguma tolerância para não repetir uma liberação até que o período de carência tenha sido limpo.

Exemplo de como isso funciona:

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

Com esse recurso desativado, você invalidaria o diretório de cache /content/exampleco/en/ 5 vezes.

Com esse recurso ativado e definido como 5 segundos, ele invalidaria o diretório de cache /content/exampleco/en/once.

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

/cache {
    /gracePeriod "5"

Invalidação baseada em TTL

Um recurso mais recente do módulo Dispatcher foi Tempo de vida (TTL) opções de invalidação baseadas em itens 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 um .ttl extensão.

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

/cache {
    /enableTTL "1"

Observação:

Lembre-se de que AEM ainda precisa ser configurado para enviar cabeçalhos TTL para que o dispatcher os honre. Alternar esse recurso permite que o dispatcher saiba quando remover os arquivos para os quais o AEM enviou cabeçalhos de controle de cache. Se 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 tornar nosso site publicado o mais ganancioso possível e armazenar em cache tudo.

Se houver elementos que interrompem a experiência quando armazenados em cache, você poderá 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 escrever essas regras podem ser encontrados here.