Visão geral do Dispatcher

O Dispatcher é uma ferramenta de cache e/ou balanceamento de carga da Adobe Experience Manager que pode ser usada em conjunto com um servidor Web de classe empresarial.

O processo de implantação do dispatcher é independente do servidor da Web e da plataforma de SO escolhida:

1. Saiba mais sobre o Dispatcher (nesta página). Also, see frequently asked questions about dispatcher.
2. Install a supported web server according to the web server documentation.
3. Instale o módulo Dispatcher em seu servidor da web e configure o servidor da web apropriadamente.
4. Configurar o Dispatcher (qualquer arquivo no dispatcher).
5. Configure o AEM para que atualizações de conteúdo invalidem o cache.

Use as seguintes informações como necessário:

• Lista de verificação de segurança do Dispatcher
• A Base De Conhecimento Do Dispatcher
• Otimizando um site para o desempenho do cache
• Utilização do Dispatcher com vários domínios
• Utilização de SSL com Dispatcher
• Implementação de cache sensível a permissões
• Resolução de Problemas do Dispatcher
• Perguntas Frequentes do Dispatcher

Por que usar o Dispatcher para implementar o Cache?

Há duas abordagens básicas para publicação na Web:

• Servidores Web estáticos: como Apache ou IIS, são muito simples, mas rápidos.
• Servidores que fornecem conteúdo dinâmico, em tempo real e inteligente, mas exigem muito mais tempo de computação e outros recursos.

O Dispatcher ajuda a realizar um ambiente rápido e dinâmico. Funciona como parte de um servidor HTML estático, como o Apache, com o objetivo de:

• armazenar (ou "armazenar em cache") o máximo possível do conteúdo do site, na forma de um site estático
• acesso ao mecanismo de layout o mínimo possível.

O que significa que:

• o conteúdo estático é manipulado com a mesma velocidade e facilidade de um servidor Web estático;além disso, você pode usar as ferramentas de administração e segurança disponíveis para seus servidores Web estáticos.

• o conteúdo dinâmico é gerado conforme necessário, sem retardar o sistema além do absolutamente necessário.

O Dispatcher contém mecanismos para gerar e atualizar HTML estático com base no conteúdo do site dinâmico. Você pode especificar em detalhes quais documentos são armazenados como arquivos estáticos e quais são sempre gerados dinamicamente.

A presente seção ilustra os princípios subjacentes a este fato.

Servidor web estático

Um servidor Web estático, como o Apache ou o IIS, serve arquivos HTML estáticos para os visitantes do seu site. As páginas estáticas são criadas uma vez, portanto, o mesmo conteúdo será entregue para cada solicitação.

Este processo é muito simples e, portanto, extremamente eficiente. Se um visitante solicitar um arquivo (por exemplo, uma página HTML), o arquivo normalmente é retirado diretamente da memória, na pior das hipóteses, é lido da unidade local. Os servidores Web estáticos estão disponíveis há bastante tempo, portanto há uma grande variedade de ferramentas para administração e gerenciamento de segurança, e eles estão muito bem integrados às infraestruturas de rede.

Servidores de gerenciamento de conteúdo

Se você usar um Servidor de gerenciamento de conteúdo, como o AEM, um mecanismo de layout avançado processa a solicitação de um visitante. O mecanismo lê o conteúdo de um repositório que, combinado com estilos, formatos e direitos de acesso, transforma o conteúdo em um documento adaptado às necessidades e direitos do visitante.

Isso permite que você crie conteúdo dinâmico e mais rico, o que aumenta a flexibilidade e funcionalidade do seu site. No entanto, o mecanismo de layout requer mais potência do que um servidor estático, portanto, essa configuração pode ser sujeita a lentidão se muitos visitantes usarem o sistema.

Como o Dispatcher executa o Cache

O diretório de cache para armazenamento em cache, o módulo Dispatcher, usa a capacidade do servidor Web de fornecer conteúdo estático. O Dispatcher coloca os documentos em cache na raiz do documento no servidor da web.

Métodos de cache

O Dispatcher tem dois métodos primários para atualizar o conteúdo de cache quando mudanças forem feitas ao website.

• As Atualizações de conteúdo removem as páginas que foram alteradas, bem como os arquivos que estão diretamente associados a elas.
• A invalidação automática invalida automaticamente as partes do cache que podem estar desatualizadas após uma atualização. Por exemplo, eficientemente marcar páginas relevantes como sendo desatualizadas, sem excluir nada.

Atualizações de conteúdo

Em uma atualização de conteúdo, um ou mais documentos do AEM são alterados. O AEM envia uma solicitação de agregação para o Dispatcher, que atualiza o cache de acordo:

1. Ele exclui os arquivos modificados do cache.
2. Ele exclui do cache todos os arquivos que iniciam com o mesmo identificador. Por exemplo, se o arquivo /pt_br/index.html for atualizado, todos os arquivos que começam com /pt_br/index. são excluídos. Esse mecanismo permite que você crie sites eficientes em cache, especialmente em relação à navegação de imagens.
3. Ela toca o chamado Arquivo de estado, Isso atualiza o carimbo de data e hora do arquivo de status para indicar a data da última alteração.

É de salientar os seguintes pontos:

• As Atualizações de conteúdo geralmente são usadas em conjunto com um sistema de criação que "sabe" o que deve ser substituído.
• Os arquivos afetados por uma atualização de conteúdo são removidos, mas não são substituídos imediatamente. Na próxima vez que um arquivo for solicitado, o Dispatcher buscará o novo arquivo da instância do AEM e o colocará no cache, substituindo assim o conteúdo antigo.
• Normalmente, as imagens geradas automaticamente que incorporam texto de uma página são armazenadas em arquivos de imagem que começam com o mesmo identificador - garantindo assim que a associação exista para exclusão. Por exemplo, você pode armazenar o texto do título da página mypage.html como a imagem mypage.titlePicture.gif na mesma pasta. Desta forma, a imagem é automaticamente eliminada do cache sempre que a página é atualizada, para que possa ter a certeza de que a imagem reflete sempre a versão atual da página.
• Você pode ter vários arquivos de status, por exemplo, um por pasta de idioma. Se uma página for atualizada, o AEM procurará a próxima pasta pai que contém um arquivo de status e tocará esse arquivo.

Invalidação automática

A invalidação automática invalida automaticamente partes do cache - sem excluir fisicamente quaisquer arquivos. Em cada atualização de conteúdo, o chamado arquivo de status é tocado, portanto, seu carimbo de data e hora reflete a última atualização de conteúdo.

O Dispatcher tem uma lista de arquivos que estão sujeitos à invalidação automática. Quando um documento dessa lista é solicitado, o Dispatcher compara a data do documento em cache com o carimbo de data e hora do arquivo de status:

• se o documento em cache for mais recente, o Dispatcher o retornará.
• se for mais antigo, o Dispatcher recuperará a versão atual da instância do AEM.

Mais uma vez, é de salientar alguns pontos:

• Normalmente, a invalidação automática é usada quando as inter-relações são complexas, por exemplo, para páginas HTML. Essas páginas contêm links e entradas de navegação, portanto, elas geralmente precisam ser atualizadas após uma atualização de conteúdo. Se você tem arquivos de PDF ou figuras automaticamente gerados, pode escolher a invalidação automática também para eles.
• A invalidação automática não envolve nenhuma ação do despachante no momento da atualização, exceto para tocar no arquivo de status. Entretanto, tocar no arquivo de status torna automaticamente o conteúdo do cache obsoleto, sem removê-lo fisicamente do cache.

Como o Dispatcher retorna documentos

Determinar se um documento está sujeito ao cache

You can define which documents the Dispatcher caches in the configuration file. O Dispatcher verifica a solicitação em relação à lista de documentos que podem ser armazenados em cache. Se o documento não estiver nessa lista, o Dispatcher solicitará o documento da instância do AEM.

O Dispatcher sempre solicita o documento diretamente da instância do AEM nos seguintes casos:

• Se o URI da solicitação contiver um ponto de interrogação "?". Isso geralmente indica uma página dinâmica, como um resultado de pesquisa, que não precisa ser armazenada em cache.
• A extensão do arquivo está ausente. O servidor Web precisa da extensão para determinar o tipo de documento (o tipo MIME).
• O cabeçalho de autenticação está definido (isso pode ser configurado)

Determinar se um documento está em cache

O Dispatcher armazena os arquivos em cache no servidor da Web como se fossem parte de um site estático. Se um usuário solicitar um documento armazenável em cache, o Dispatcher verificará se esse documento existe no sistema de arquivos do servidor Web:

• se o documento estiver em cache, o Dispatcher retornará o arquivo.
• se não estiver em cache, o Dispatcher solicitará o documento da instância do AEM.

Como determinar se um documento está atualizado

Para descobrir se um documento está atualizado, o Dispatcher executa duas etapas:

1. Verifica se o documento está sujeito a invalidação automática. Caso contrário, o documento será considerado atualizado.
2. Se o documento estiver configurado para invalidação automática, o Dispatcher verificará se ele é mais antigo ou mais recente do que a última alteração disponível. Se for mais antigo, o Dispatcher solicitará a versão atual da instância do AEM e substituirá a versão no cache.

Os benefícios do balanceamento de carga

Balanceamento de carga é a prática de distribuir a carga computacional do site em várias instâncias do AEM.

Você ganha:

• maior poder de processamento Na prática, isso significa que o Dispatcher compartilha solicitações de documento entre várias instâncias do AEM. Como cada instância agora tem menos documentos para processar, você tem tempos de resposta mais rápidos. O Dispatcher mantém estatísticas internas para cada categoria de documento, de modo que ele possa estimar o carregamento e distribuir as consultas com eficiência.

• maior cobertura à prova de falhas Se o Dispatcher não receber respostas de uma instância, ele retornará automaticamente solicitações para uma das outras instâncias. Assim, se uma instância se tornar indisponível, o único efeito é um abrandamento do site, proporcional à potência computacional perdida. No entanto, todos os serviços continuarão.

• você também pode gerenciar sites diferentes no mesmo servidor Web estático.

Como o Dispatcher executa o Balanceamento de Carga

Estatísticas de desempenho

O Dispatcher mantém estatísticas internas sobre a velocidade com que cada instância do AEM processa documentos. Com base nesses dados, o Dispatcher estima qual instância fornecerá o tempo de resposta mais rápido ao responder uma solicitação e, portanto, reserva o tempo de cálculo necessário para essa instância.

Tipos diferentes de solicitações podem ter tempos médios diferentes de conclusão, de modo que o Dispatcher permite que você especifique categorias de documento. Eles são considerados ao calcular as estimativas de tempo. Por exemplo, você pode fazer uma distinção entre páginas HTML e imagens, já que os tempos de resposta típicos podem ser diferentes.

Se você usar uma função de pesquisa elaborada, poderá criar uma nova categoria para consultas de pesquisa. Isso ajuda o Dispatcher a enviar consultas de pesquisa para a instância que responde mais rapidamente. Isso impede que uma instância mais lenta seja paralisada quando recebe várias consultas de pesquisa "caras", enquanto as outras recebem as solicitações "mais baratas".

Conteúdo personalizado (conexões adesivas)

As conexões adesivas garantem que os documentos de um usuário sejam todos compostos na mesma instância do AEM. Isso é importante se você usar páginas personalizadas e dados de sessão. Os dados são armazenados na instância, portanto as solicitações subsequentes do mesmo usuário devem retornar a essa instância ou os dados são perdidos.

Como as conexões aderentes restringem a capacidade do Dispatcher de otimizar as solicitações, você deve usá-las somente quando necessário. Você pode especificar a pasta que contém os documentos "fixos", garantindo que todos os documentos dessa pasta sejam compostos na mesma instância para cada usuário.

Usando vários Dispatchers v

Em configurações complexas, você pode usar vários Dispatchers. Por exemplo, você pode usar:

• um Dispatcher para publicar um site na Intranet
• um segundo Dispatcher, em um endereço diferente e com configurações de segurança diferentes, para publicar o mesmo conteúdo na Internet.

Nesse caso, verifique se cada solicitação passa por apenas um Dispatcher. Um Dispatcher não lida com solicitações provenientes de outro Dispatcher. Portanto, verifique se ambos os Dispatchers acessam o site do AEM diretamente.

Uso do Dispatcher com um CDN

Uma rede de entrega de conteúdo (CDN), como Akamai Edge Delivery ou Amazon Cloud Front, fornece conteúdo de um local próximo ao usuário final. Assim,

• acelera os tempos de resposta para usuários finais
• e carrega seus servidores

Como um componente de infraestrutura HTTP, um CDN funciona como o Dispatcher: quando um nó CDN recebe uma solicitação, ele serve a solicitação de seu cache, se possível (o recurso está disponível no cache e é válido). Caso contrário, ele chegará ao próximo servidor mais próximo para recuperar o recurso e armazená-lo em cache para outras solicitações, se apropriado.

O "próximo servidor mais próximo" depende de sua configuração específica. Por exemplo, em uma configuração do Akamai, a solicitação pode seguir o seguinte caminho:

• O nó Akamai Edge
• A Camada Akamai Midgres
• Seu firewall
• Seu balanceador de carga
• Dispatcher
• AEM

Na maioria dos casos, o Dispatcher é o próximo servidor que pode servir o documento de um cache e influenciar os cabeçalhos de resposta retornados ao servidor CDN.

Controle de um cache CDN

Há várias maneiras de controlar por quanto tempo um CDN armazenará em cache um recurso antes que ele seja obtido novamente no Dispatcher.

1. Configuração explícita
   Configure por quanto tempo os recursos específicos são mantidos no cache do CDN, dependendo do tipo mime, extensão, tipo de solicitação etc.

2. Cabeçalhos de expiração e controle de cache
   A maioria dos CDNs respeitará Expires: e os Cache-Control:HTTP Headers serão enviados pelo servidor upstream. This can be achieved e.g. by using the mod_expires Apache Module.

3. Invalidação manual
   As CDNs permitem que os recursos sejam removidos do cache por meio de interfaces da Web.

4. Invalidação baseada em API
   A maioria das CDNs também oferece uma REST e/ou SOAP API que permite a remoção de recursos do cache.

Em uma configuração típica do AEM, a configuração por extensão e/ou caminho, que pode ser alcançada através dos pontos 1 e 2 acima, oferece possibilidades de definir períodos razoáveis de cache para recursos frequentemente usados que não são alterados com frequência, como imagens de design e bibliotecas de clientes. Quando novas versões são implantadas, geralmente é necessária uma invalidação manual.

Se essa abordagem for usada para armazenar em cache conteúdo gerenciado, isso implica que as alterações de conteúdo só estarão visíveis para os usuários finais depois que o período de cache configurado expirar e o documento for buscado do Dispatcher novamente.

Para obter um controle mais refinado, a invalidação com base em API permite invalidar o cache de um CDN quando o cache do Dispatcher for invalidado. Com base na API de CDNs, você pode implementar seu próprio ContentBuilder e TransportHandler (se a API não for baseada em REST) e configurar um Agente de Replicação que os usará para invalidar o cache do CDN.

Uso de um Dispatcher com um Servidor de Autores

/rules
{
/0000
{ /type "deny" /glob "*"}
}

Um Dispatcher pode ser usado na frente de uma instância do autor para melhorar o desempenho da criação. Para configurar um Dispatcher de criação, faça o seguinte:

1. Instale um Dispatcher em um servidor da Web (pode ser o Apache ou o IIS, consulte Instalação do Dispatcher).

2. Você pode testar o Dispatcher recém-instalado em relação a uma instância de publicação do AEM em funcionamento, para garantir que uma instalação correta da linha de base tenha sido atingida.

3. Agora, verifique se o Dispatcher consegue se conectar via TCP/IP à sua instância do autor.

4. Substitua o arquivo dispatcher.any de amostra pelo arquivo author_dispatcher.any fornecido com o download do Dispatcher.

5. Abra o author_dispatcher.any em um editor de texto e faça as seguintes alterações:

   1. Altere o /hostname e /port da /renders seção para apontar para a instância do autor.
   2. Altere o /docroot da /cache seção para apontar para um diretório de cache. In case you are using AEM with Touch UI, see the warning above.
   3. Salve as alterações.

6. Exclua todos os arquivos existentes no diretório /cache > /docroot que você configurou acima.

7. Reinicie o servidor Web.

1. Exclua ou desative o agente de descarga do autor dispatcher na instância do autor do AEM.
2. Refaça a configuração do dispatcher do autor seguindo as novas instruções acima.