Show Menu
TOPICS×

Visão geral do Dispatcher

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 é a ferramenta de balanceamento de carga e/ou cache do Adobe Experience Manager. Usar o Dispatcher do AEM também ajuda a proteger seu servidor AEM contra ataques. Portanto, você pode aumentar a segurança da sua instância do AEM usando o Dispatcher em conjunto com um servidor da Web de classe empresarial.
O processo de implantação de um Dispatcher é independente do servidor da Web e da plataforma do SO escolhida:
  1. Saiba mais sobre o Dispatcher (nesta página). Além disso, consulte as perguntas frequentes sobre o Dispatcher .
  2. Instale um site da Web compatível de acordo com a documentação do servidor da Web.
  3. Instale o módulo Dispatcher em seu servidor da web e configure o servidor da web apropriadamente.
  4. Configure o AEM para que atualizações de conteúdo invalidem o cache.
Para obter melhor compreensão de como o Dispatcher funciona com AEM, veja Pergunte aos especialistas da Comunidade AEM para julho de 2017 .
Use as seguintes informações como 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.

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.
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 da 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 da 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 à URL solicitada.
Pode haver limitações a nível de OS para o comprimento do nome do arquivo; por exemplo, se você tem uma URL com muitos seletores.

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

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:
  • 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)
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 cache do cabeçalho de resposta, consulte a seção Cache de HTTP Response Headers .

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 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.

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.
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.

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.
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.

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. Isso pode ser feito, por exemplo, usando o mod_expires no Módulo Apache.
  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 o API não for baseado em REST) e configurar um Agente de replicação que usará isso para invalidar o cache do CDN.
Consulte também AEM (CQ) Dispatcher Security e CDN+Browser Caching e apresentação gravada no Dispatcher Caching .

Uso de um Dispatcher com um Servidor de Autores

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:
  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. Caso esteja usando o AEM com Touch UI , consulte o aviso acima.
    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.
Observe que, com a 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
author_dispatcher.any
ou
/libs
/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 despachante do autor previamente configurado e ativado um agente
de despachante do
despachante, faça o seguinte:
  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.