Ambiente
Experience Manager
Problema/Sintomas
Este documento dará orientação sobre como a liberação ocorre e explica o mecanismo que executa a liberação e a invalidação do cache.
Como funciona
Ordem de operação
O fluxo de trabalho típico é melhor descrito quando os autores de conteúdo ativam uma página, quando o editor recebe o novo conteúdo, ele aciona uma solicitação de liberação para o dispatcher, conforme mostrado no diagrama a seguir:
Essa cadeia de eventos destaca que apenas liberamos itens novos ou que foram alterados. Isso garante que o conteúdo tenha sido recebido pelo editor antes de limpar o cache, para evitar condições de corrida, onde a liberação pode ocorrer antes que as alterações possam ser recebidas do editor.
Agentes de replicação
No autor, há um agente de replicação configurado para apontar para o publicador que, quando algo é ativado, ele dispara para enviar o arquivo e todas as suas dependências para o publicador.
Quando o editor recebe o arquivo, ele tem um agente de replicação configurado para apontar para o dispatcher que dispara no evento ao receber. Em seguida, ele serializará uma solicitação de liberação e a postará no dispatcher.
AGENTE DE REPLICAÇÃO DO AUTOR
Aqui estão algumas capturas de tela de exemplo de um agente de replicação padrão configurado
Normalmente, há 1 ou 2 agentes de replicação configurados no autor para cada editor para o qual eles replicam conteúdo.
O primeiro é o agente de replicação padrão que envia ativações de conteúdo.
O segundo é o agente reverso. Isso é opcional e está configurado para verificar a caixa de saída de cada editor para ver se há novo conteúdo a ser extraído para o autor como uma atividade de replicação inversa
AGENTE DE REPLICAÇÃO DO EDITOR
Veja um exemplo de capturas de tela de um agente de replicação de liberação padrão configurado
REPLICAÇÃO DE LIBERAÇÃO DO DISPATCHER RECEBENDO HOST VIRTUAL
O módulo Dispatcher procura cabeçalhos específicos para saber quando uma solicitação POST é algo a ser transmitido para renderizações de AEM ou se é serializado como uma solicitação de liberação e precisa ser manipulado pelo próprio manipulador do Dispatcher. Esta é uma captura de tela da página de configuração que mostra estes valores:
A página de configuração padrão mostra o Tipo de serialização as Liberação do Dispatcher e define o nível de erro
Na guia transporte, você pode ver o URI sendo definido para apontar o endereço IP do dispatcher que receberá as solicitações de liberação. O caminho /dispatcher/invalidate.cache não é como o módulo determina se é uma liberação, é apenas um endpoint óbvio que você pode ver no log de acesso para saber se foi uma solicitação de liberação. Na guia Estendido , vamos analisar os itens que estão lá para qualificar que esta é uma solicitação de liberação para o módulo do dispatcher.
O método HTTP para solicitações de liberação é apenas uma solicitação GET com alguns cabeçalhos de solicitação especiais:
CQ-Action
CQ-Handle
CQ-Path
Host
Agora, se olharmos para a aparência típica de uma solicitação de liberação na forma de um comando curl
$ curl \ -H "CQ-Action: Activate" \ -H "CQ-Handle: /content/dam/logo.jpg" \ -H "CQ-Path: /content/dam/" \ -H "Content-Length: 0" \ -H "Content-Type: application/octect-stream" \ -H "Host: flush" \ http: //10 .43.0.32:80 /dispatcher/invalidate .cache |
---|
Este exemplo de liberação liberaria o caminho /content/dam atualizando o arquivo .stat nesse diretório.
O arquivo .stat
O mecanismo de descarga é de natureza simples e queremos explicar a importância da .stat arquivos gerados na raiz do documento em que os arquivos de cache são criados.
Dentro dos arquivos .vhost e _farm.any, configuramos uma diretiva raiz de documento para especificar onde o cache está localizado e de onde armazenar / veicular arquivos quando uma solicitação de um usuário final chega.
Se você executasse o seguinte comando no servidor do dispatcher, começaria a encontrar arquivos .stat
1 | $ find /mnt/var/www/html/ - type f -name ".stat" |
---|
Este é um diagrama da aparência dessa estrutura de arquivo quando você tem itens no cache e tem uma solicitação de liberação enviada e processada pelo módulo Dispatcher
NÍVEL DE ARQUIVO STAT
Observe que em cada diretório havia um arquivo .stat presente. Este é um indicador de que ocorreu uma liberação. No exemplo acima de statfilelevel foi definida como 3 dentro do arquivo de configuração farm correspondente.
A configuração statfilelevel indica quantas pastas o módulo percorrerá e atualizará um arquivo .stat. O arquivo .stat está vazio, não é nada mais do que um nome de arquivo com um carimbo de data e hora poderia ser criado manualmente, mas executando o comando touch na linha de comando do servidor dispatcher.
Se a configuração de nível de arquivo stat estiver definida como muito alta, cada solicitação de liberação percorrerá a árvore de diretório tocando arquivos stat. Isso pode se tornar um grande impacto no desempenho em árvores de cache grandes e pode afetar o desempenho geral do seu dispatcher.
Definir esse nível de arquivo como muito baixo pode fazer com que uma solicitação de liberação apague mais do que o esperado. O que, por sua vez, faria com que o cache fosse retornado com mais frequência, com menos solicitações sendo atendidas do cache, e poderia causar problemas de desempenho.
Observação:
Defina o statfilelevel em um nível razoável. Examine sua estrutura de pastas e verifique se está configurada para permitir liberações concisas sem ter que percorrer muitos diretórios. Teste-o e certifique-se de que ele se ajuste às suas necessidades durante um teste de desempenho do sistema.
Um bom exemplo é um site que suporta idiomas. A árvore de conteúdo típica teria os seguintes diretórios
/content/brand1/en/us/
Neste exemplo, use uma configuração de nível de arquivo stat de 4. Isso garantirá quando você liberar o conteúdo contido no us que também não fará com que as pastas de idioma sejam liberadas.
COMPARTILHAMENTO DE CARIMBO DE DATA E HORA DO ARQUIVO STAT
Quando uma solicitação de conteúdo ocorre na mesma rotina
MANIPULAÇÃO DE CACHE - EXEMPLO 1
No exemplo acima, uma solicitação para o conteúdo /content/index.html
A hora do arquivo index.html é 2019-11-01 às 18:21
A hora do arquivo .stat mais próximo é 2019-11-01 às 12:22 PM
Entendendo o que lemos acima, você pode ver que o arquivo de índice é mais recente que o arquivo .stat e o arquivo seria distribuído do cache para o usuário final que o solicitou
HANDSHAKE DE CACHE - EXEMPLO 2
No exemplo acima, uma solicitação para o conteúdo /content/dam/logo.jpg
A hora do arquivo logo.jpg é 31/10/2019 às 13:13
A hora do arquivo .stat mais próximo é 2019-11-01 às 12:22 PM
Como você pode ver neste exemplo, o arquivo é mais antigo que o arquivo .stat e será removido, e um novo é extraído do AEM para substituí-lo no cache antes de ser enviado ao usuário final que o solicitou.
Configurações do arquivo farm
A documentação está aqui para o conjunto completo de opções de configuração: https://docs.adobe.com/content/help/pt-BR/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html#configuring-dispatcher_configuring-the-dispatcher-cache-cache
Destacaremos alguns deles relacionados à liberação de cache
Raiz do documento
Essa entrada de configuração está na seguinte seção do arquivo farm:
/myfarm { /cache { /docroot |
---|
Você especifica o diretório no qual deseja que o dispatcher preencha e gerencie como um diretório de cache.
Observação:
Esse diretório deve corresponder à configuração da raiz do documento apache do domínio que seu servidor da Web está configurado para usar.
Ter pastas docroot aninhadas por cada farm que vivem subpastas da raiz do documento apache é uma péssima ideia por vários motivos.
Nível dos arquivos stat
Essa entrada de configuração está na seguinte seção do arquivo farm:
/myfarm { /cache { /statfileslevel |
---|
/statfileslevel definido no seguinte número com a raiz do documento de /var/www/html/ teria os seguintes resultados ao liberar /content/dam/brand1/en/us/logo.jpg
0 - os arquivos stat a seguir seriam criados
1 - os arquivos stat a seguir seriam criados
2 - os arquivos stat a seguir seriam criados
3 - os arquivos stat a seguir seriam criados
4 - os arquivos stat a seguir seriam criados
5 - os arquivos stat a seguir seriam criados
Observação:
Lembre-se de que, quando ocorre o handshake do carimbo de data e hora, ele procura o arquivo .stat mais próximo.
ter um nível de arquivo .stat 0 e um arquivo stat somente em /var/www/html/.stat significa que o conteúdo contido em /var/www/html/content/dam/brand1/en/us/ procuraria o arquivo .stat mais próximo e percorreria 5 pastas para encontrar o único arquivo .stat existente no nível 0 e comparar datas com esse arquivo. Isso significa que uma liberação no nível mais alto invalidaria todos os itens em cache.
Invalidação permitida
Essa entrada de configuração está na seguinte seção do arquivo farm:
/myfarm { /cache { /allowedClients { |
---|
Dentro dessa configuração, você coloca uma lista de endereços IP que podem enviar solicitações de liberação. Se uma solicitação de liberação entrar no dispatcher, ela deverá vir de um IP confiável. Caso tenha configurado incorretamente ou enviado uma solicitação de liberação de um endereço IP não confiável, você verá o seguinte erro no arquivo de log:
Mon Nov 11 22:43:05 2019 W pid 3079 (tid 139859875088128) Flushing rejected from 10.43.0.57 |
---|
Regras de invalidação
Essa entrada de configuração está na seguinte seção do arquivo farm:
/myfarm { /cache { /invalidate { |
---|
Normalmente, essas regras indicam quais arquivos podem ser invalidados com uma solicitação de liberação.
Para evitar que arquivos importantes sejam invalidados com uma ativação de página, você pode colocar regras que especificam quais arquivos são ok para invalidar e quais arquivos devem ser invalidados manualmente. Este é um conjunto de amostras de configuração que permite que somente arquivos html sejam invalidados:
/invalidate { /0000 { /glob "*" /type "deny" } /0001 { /glob "*.html" /type "allow" } } |
---|
Teste/solução de problemas
Ao ativar uma página e obter a luz verde informando que a ativação da página foi bem-sucedida, você deve esperar que o conteúdo ativado também seja liberado do cache.
Atualize sua página e veja os itens antigos e há luz verde.
Vamos seguir alguns passos manualmente no processo de liberação para nos trazer uma ideia do que poderia estar errado. No shell do editor, execute a seguinte solicitação de liberação usando curl:
$ curl -H "CQ-Action: Activate" \ -H "CQ-Handle: /content/PATH TO ITEM TO FLUSH" \ -H "CQ-Path: /content/PATH TO ITEM TO FLUSH" \ -H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ -H "Host: flush" \ http: // DISPATCHER IP ADDRESS /dispatcher/invalidate .cache |
---|
Exemplo de solicitação de liberação de teste
$ curl -H "CQ-Action: Activate" \ -H "CQ-Handle: /content/customer/en-us" \ -H "CQ-Path: /content/customer/en-us" \ -H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ -H "Host: flush" \ http: //169 .254.196.222 /dispatcher/invalidate .cache |
---|
Depois de disparar o comando de solicitação para o dispatcher, você desejará ver o que é feito nos logs e o que é feito com os arquivos .stat. Siga o arquivo de log e você deve ver as seguintes entradas para confirmar a ocorrência da solicitação de liberação do módulo do dispatcher
Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 Activation detected: action=Activate /content/dam/logo.jpg Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 Touched /mnt/var/www/html/.stat Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 Touched /mnt/var/www/html/content/.stat Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 Touched /mnt/var/www/html/content/dam/.stat Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 "GET /dispatcher/invalidate.cache" 200 purge publishfarm/- 0ms |
---|
Agora que vemos o módulo selecionado e reconhecemos a solicitação de liberação, precisamos ver como ele afetou os arquivos .stat. Execute o seguinte comando e observe a atualização dos carimbos de data e hora à medida que emite outra liberação:
| $
watch
-n 3
"find /mnt/var/www/html/ -type f -name "
.stat
" | xargs ls -la $1"
|
| — |
Como você pode ver na saída do comando, os carimbos de data e hora dos arquivos .stat atuais
-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/dam/ .stat -rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/ .stat -rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/ .stat |
---|
Agora, se executarmos a liberação novamente, você verá os carimbos de data e hora serem atualizados
-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/dam/ .stat -rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/ .stat -rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/ .stat |
---|
Vamos comparar nossos carimbos de data e hora de conteúdo com nossos carimbos de data e hora de arquivos .stat
$ stat /mnt/var/www/html/content/customer/en-us/ .stat File: .stat’ Tamanho: 0 Blocos: 0 Bloco de E/S: 4096 normal vaziofile Dispositivo: ca90h/51856d` `Inode: 17154125 Links: 1 Acesso: (0644)/-rw-r--r-- ) Uid: (48/apache) Gid: (48/apache)Access: 2019-11-13 16:22:31.000000000 -0400 Modificar: 2019-11-13 16:22:31.00000000 -0400Change: 2019-11-13 16:22:31.000000000 -0400`<br> <br>`$ stat /mnt/var/www/html/content/customer/en-us/logo.jpg Arquivo: logo.jpg' Size: 15856 Blocks: 32 IO Block: 4096 regular file Device: ca90h /51856d Inode: 9175290 Links: 1 Access: (0644 /-rw-r--r-- ) Uid: ( 48/ apache) Gid: ( 48/ apache) Access: 2019-11-11 22:41:59.642450601 +0000 Modify: 2019-11-11 22:41:59.642450601 +0000 Change: 2019-11-11 22:41:59.642450601 +0000 |
---|
Se você observar qualquer um dos carimbos de data e hora, observará que o conteúdo tem um horário mais recente que o arquivo .stat, o que instrui o módulo a veicular o arquivo do cache, pois ele é mais recente que o arquivo .stat.
Em resumo, algo atualizou os carimbos de data e hora desse arquivo, o que não o qualifica como "liberado" ou substituído.