As versões do Dispatcher são independentes do AEM. Você pode ter sido redirecionado para esta página se tiver seguido um link para a documentação do Dispatcher incorporada à documentação de uma versão anterior do AEM.
O Dispatcher é uma ferramenta de armazenamento em cache e/ou balanceamento de carga do Adobe Experience Manager, que pode ser usado em conjunto com um servidor Web de classe empresarial.
O processo de implantação do Dispatcher é independente do servidor Web e da plataforma de SO escolhida:
Para entender melhor como o Dispatcher funciona com o AEM:
Use as seguintes informações conforme necessário:
O uso mais comum do Dispatcher é armazenar em cache as respostas de uma instância de publicação do AEM, para aumentar a capacidade de resposta e a segurança de seu site publicado voltado para o exterior. A maior parte da discussão se concentra nesse caso.
Mas o Dispatcher também pode ser usado para aumentar a capacidade de resposta da instância do seu autor, principalmente se você tiver um grande número de usuários editando e atualizando seu site. Para obter detalhes específicos deste caso, consulte Uso de um Dispatcher com um servidor de autor, abaixo.
Há duas abordagens básicas para publicação na Web:
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:
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.
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.
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.
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 do servidor web.
Quando falta a configuração para o HTTP Header Caching, o Dispatcher armazena apenas o código HTML da página - não armazena os cabeçalhos HTTP. Isso pode ser um problema se você usar diferentes codificações dentro do seu website, pois elas podem se perder. Para permitir o HTTP Header Caching, veja Configuração do Cache do Dispatcher.
Localizar o documento-raiz do seu servidor Web no armazenamento anexo à rede (NAS) causa degradação de desempenho. Da mesma forma, quando um documento-raiz que está localizado no NAS é compartilhado entre vários servidores Web, bloqueios intermitentes podem ocorrer quando ações de replicação são realizadas.
O Dispatcher armazena o documento em cache em uma estrutura igual ao URL solicitado.
Pode haver limitações a nível de SO para o comprimento do nome do arquivo; por exemplo, se você tem um URL com muitos seletores.
O Dispatcher tem dois métodos primários para atualizar o conteúdo de cache quando mudanças forem feitas ao website.
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:
É de salientar os seguintes pontos:
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:
Mais uma vez, é de salientar alguns pontos:
Você pode definir quais documentos o Dispatcher armazena em cache no arquivo de configuração. 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:
Os métodos GET ou HEAD (para o cabeçalho HTTP) podem ser armazenados em cache pelo Dispatcher. Para obter informações adicionais sobre o armazenamento em cache do cabeçalho de resposta, consulte a seção Armazenamento em cache de cabeçalhos de resposta HTTP.
O Dispatcher armazena os arquivos em cache no servidor 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:
Para descobrir se um documento está atualizado, o Dispatcher executa duas etapas:
Os documentos sem invalidação automática permanecem no cache até serem fisicamente excluídos; por exemplo, por uma atualização de conteúdo no site.
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 é uma desaceleração 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.
Enquanto o balanceamento de carga espalha a carga com eficiência, o cache ajuda a reduzir a carga. Portanto, tente otimizar o cache e reduzir a carga geral antes de configurar o balanceamento de carga. Um bom cache pode aumentar o desempenho do balanceador de carga ou tornar desnecessário o balanceamento de carga.
Embora um único Dispatcher possa normalmente saturar a capacidade das instâncias de Publicação disponíveis, para alguns aplicativos raros, pode fazer sentido balancear adicionalmente a carga entre duas instâncias do Dispatcher. As configurações com vários Dispatchers precisam ser consideradas com cuidado, já que um Dispatcher adicional aumentará a carga nas instâncias de Publicação disponíveis e poderá facilmente diminuir o desempenho na maioria dos aplicativos.
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".
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.
Para a maioria das páginas que usam conexões adesivas, é necessário desligar o cache; caso contrário, a página será a mesma para todos os usuários, independentemente do conteúdo da sessão.
Para algumas aplicações, pode ser possível utilizar ligações aderentes e armazenamento em cache; por exemplo, se você exibir um formulário que grava dados na sessão.
Em configurações complexas, você pode usar vários Dispatchers. Por exemplo, você pode usar:
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.
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,
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:
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.
Há várias maneiras de controlar por quanto tempo um CDN armazenará em cache um recurso antes que ele seja obtido novamente no Dispatcher.
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.
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. Isso pode ser feito, por exemplo, usando o Módulo Apache mod_expires.
Invalidação manual
As CDNs permitem que os recursos sejam removidos do cache por meio de interfaces da Web.
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.
Consulte também Segurança do AEM (CQ) Dispatcher e Armazenamento em cache de CDN+Browser e uma apresentação gravada sobre Armazenamento em cache do Dispatcher.
se você estiver usando o AEM com Touch UI, não armazene em cache o conteúdo da instância do autor. Se o cache tiver sido ativado para a instância do autor, será necessário desativá-lo e excluir o conteúdo do diretório do cache. Para desativar o armazenamento em cache, edite o author_dispatcher.any
arquivo e modifique a propriedade /rule
da /cache
seção da seguinte maneira:
/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:
Instale um Dispatcher em um servidor Web (pode ser o Apache ou o IIS, consulte Instalação do Dispatcher).
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.
Agora, verifique se o Dispatcher consegue se conectar via TCP/IP à sua instância do autor.
Substitua o arquivo dispatcher.any de amostra pelo arquivo author_dispatcher.any fornecido com o download do Dispatcher.
Abra o author_dispatcher.any
em um editor de texto e faça as seguintes alterações:
/hostname
e /port
da /renders
seção para apontar para a instância do autor./docroot
da /cache
seção para apontar para um diretório de cache. Caso esteja usando o AEM com Touch UI, consulte o aviso acima.Exclua todos os arquivos existentes no diretório /cache
> /docroot
que você configurou acima.
Reinicie o servidor Web.
Observe que, com a author_dispatcher.any
configuração fornecida, ao instalar um pacote de recursos, uma correção ou um pacote de código de aplicativo do CQ5 que afeta qualquer conteúdo sob /libs
ou /apps
você deve excluir os arquivos em cache nesses diretórios no cache do dispatcher para garantir que, na próxima vez que forem solicitados, os arquivos recém-atualizados sejam buscados e não os arquivos em cache antigos.
Se você tiver usado o Dispatcher do autor previamente configurado e ativado um agente de limpeza do dispatcher, faça o seguinte: