Diretrizes de desempenho

Esta página fornece diretrizes gerais sobre como otimizar o desempenho da implantação do AEM. Se você não AEM, passe o mouse sobre as seguintes páginas antes de começar a ler as diretrizes de desempenho:

• AEM conceitos básicos
• Visão geral do armazenamento em AEM
• Implantações recomendadas
• Requisitos técnicos

Ilustradas abaixo estão as opções de implantação disponíveis para AEM (rolar para exibir todas as opções):

Quando utilizar as diretrizes de desempenho

Você deve usar as diretrizes de desempenho nas seguintes situações:

• Implantação pela primeira vez: Ao planejar a implantação do AEM Sites ou do Assets pela primeira vez, é importante entender as opções disponíveis ao configurar o Micro Kernel, a Loja de nós e a Loja de dados (em comparação com as configurações padrão). Por exemplo, alterar as configurações padrão do Data Store para TarMK para File Data Store.
• Atualização para uma nova versão: Ao atualizar para uma nova versão, é importante entender as diferenças de desempenho em comparação ao ambiente em execução. Por exemplo, atualização do AEM 6.1 para 6.2 ou do AEM 6.0 CRX2 para 6.2 OAK.
• O tempo de resposta é lento: Quando a arquitetura do Nodestore selecionada não estiver atendendo aos seus requisitos, é importante compreender as diferenças de desempenho em comparação com outras opções de topologia. Por exemplo, implantar o TarMK em vez do MongoMK ou usar um File Data Store em vez de um Amazon S3 ou Microsoft Azure Data Store.
• Adicionar mais autores: Quando a topologia TarMK recomendada não atende aos requisitos de desempenho e o redimensionamento do nó Autor atingiu a capacidade máxima disponível, é importante entender as diferenças de desempenho em comparação ao uso do MongoMK com três ou mais nós Autor. Por exemplo, implantar MongoMK em vez de TarMK.
• Adicionar mais conteúdo: Quando a arquitetura recomendada do Data Store não atender aos seus requisitos, é importante compreender as diferenças de desempenho em comparação com outras opções do Data Store. Exemplo: usando o Amazon S3 ou o Microsoft Azure Data Store em vez de um File Data Store.

Introdução

Este capítulo fornece uma visão geral da arquitetura de AEM e seus componentes mais importantes. Ele também fornece diretrizes de desenvolvimento e descreve os cenários de teste usados nos testes de benchmark TarMK e MongoMK.

A Plataforma AEM

A plataforma de AEM consiste nos seguintes componentes:

Para obter mais informações sobre a plataforma de AEM, consulte O que é AEM.

A arquitetura de AEM

Há três blocos fundamentais importantes para uma implantação de AEM. A Instância do autor que é usada por autores, editores e aprovadores de conteúdo para criar e revisar o conteúdo. Quando o conteúdo é aprovado, ele é publicado em um segundo tipo de instância chamado Publicar instância de onde é acessado pelos usuários finais. O terceiro bloco de construção é o Dispatcher que é um módulo que lida com o armazenamento em cache e a filtragem de URL e é instalado no servidor da Web. Para obter informações adicionais sobre a arquitetura de AEM, consulte Cenários de implantação típicos.

Micro Kernels

Micro Kernels atuam como gerentes de persistência em AEM. Existem três tipos de Micro Kernels usados com AEM: TarMK, MongoDB e Banco de Dados Relacional (sob suporte restrito). Escolher um que atenda às suas necessidades depende da finalidade de sua ocorrência e do tipo de implantação que você esteja considerando. Para obter informações adicionais sobre Micro Kernels, consulte a página Implantações Recomendadas.

Nodestore

No AEM, os dados binários podem ser armazenados independentemente dos nós de conteúdo. O local onde os dados binários são armazenados é chamado de Data Store, enquanto o local dos nós e propriedades de conteúdo é chamado de Node Store.

Armazenamento de dados

Ao lidar com um grande número de binários, é recomendável usar um armazenamento de dados externo em vez dos armazenamentos de nó padrão para maximizar o desempenho. Por exemplo, se o projeto exigir um grande número de ativos de mídia, armazená-los no Arquivo ou no Data Store do Azure/S3 fará com que o acesso seja mais rápido do que armazená-los diretamente em um MongoDB.

Para obter mais detalhes sobre as opções de configuração disponíveis, consulte Configuração de nós e armazenamentos de dados.

Pesquisar

Listados nesta seção são os provedores de índice personalizados usados com o AEM. Para saber mais sobre indexação, consulte Consultas e Indexação do Oak.

Diretrizes de desenvolvimento

Você deve desenvolver para AEM com o objetivo de desempenho e escalabilidade. Apresentamos abaixo uma série de práticas recomendadas que podem ser seguidas:

DO

• Aplicar separação de apresentação, lógica e conteúdo
• Use APIs AEM existentes (por exemplo: Sling) e ferramentas (ex: Replicação)
• Desenvolver no contexto do conteúdo real
• Desenvolver para otimizar a capacidade de armazenamento em cache
• Minimize o número de salvamentos (por exemplo: ao usar workflows transitórios)
• Certifique-se de que todos os pontos finais HTTP sejam RESTful
• Restringir o escopo da observação do JCR
• Considere o encadeamento assíncrono

NÃO

• Não use APIs JCR diretamente, se você puder

• Não altere /libs, mas use sobreposições

• Não use consultas sempre que possível

• Não use o Sling Bindings para obter serviços OSGi no código Java, mas use:

  • @Reference em um componente DS
  • @Inject em um Modelo Sling
  • sling.getService() em uma Classe de Uso Sightly
  • sling.getService() em um JSP
  • um ServiceTracker
  • acesso direto ao registro do serviço OSGi

Para obter mais detalhes sobre o desenvolvimento no AEM, leia Desenvolvimento - Noções básicas. Para obter práticas recomendadas adicionais, consulte Práticas recomendadas de desenvolvimento.

Cenários de referência

Os cenários de teste detalhados abaixo são usados para as seções de benchmark dos capítulos TarMK, MongoMk e TarMK vs MongoMk. Para ver qual cenário foi usado para um teste de benchmark específico, leia o campo Cenário da tabela Especificações técnicas.

Cenário de produto único

AEM Assets:

• Interações do usuário: Pesquise ativos / Pesquise ativos / Baixe ativos / Leia metadados do ativo / Atualize metadados do ativo / Carregar ativo / Executar fluxo de trabalho de upload de ativo
• Modo de execução: usuários simultâneos, única interação por usuário

Cenário de combinação de produtos

AEM Sites + Ativos:

• Interações do usuário do Sites: Ler Página Do Artigo / Ler Página / Criar Parágrafo / Editar Parágrafo / Criar Página De Conteúdo / Ativar Página De Conteúdo / Pesquisar Do Autor
• Interações do usuário do Assets: Pesquise ativos / Pesquise ativos / Baixe ativos / Leia metadados do ativo / Atualize metadados do ativo / Carregar ativo / Executar fluxo de trabalho de upload de ativo
• Modo de execução: usuários simultâneos, interações mistas por usuário

Cenário de caso de uso vertical

Mídia:

• Ler Página Do Artigo (27.4%), Página De Leitura (10.9%), Criar Sessão (2.6%), Ativar Página De Conteúdo (1.7%), Criar Página De Conteúdo (0.4%), Criar Parágrafo (4.3%), Editar Parágrafo (0.9%), Componente De Imagem (0.9%), Pesquisar Ativos (20%), Ler Metadados De Ativos (8.5 %), Baixar Ativo (4.2%), Pesquisar Ativo (0.2%), Atualizar Metadados De Ativo (2.4%), Fazer Upload De Ativo (1.2%), Procurar Projeto (4.9%), Ler Projeto (6.6%), Adicionar Ativo (1.2%), Adicionar Projeto (1.2%), Criar Projeto (0.1%), Pesquisa Do Autor )
• Modo de execução: usuários simultâneos, interações mistas por usuário

TarMK

Este capítulo fornece diretrizes gerais de desempenho para o TarMK, especificando os requisitos mínimos de arquitetura e a configuração das configurações. Os testes de referência são também fornecidos para maior clarificação.

O Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes em todos os cenários de implantação, tanto para as instâncias de Autor e Publicação do AEM.

Para obter mais informações sobre o TarMK, consulte Cenários de implantação e Armazenamento Tar.

Diretrizes de arquitetura mínima do TarMK

Para estabelecer um bom desempenho ao usar o TarMK, você deve começar com a seguinte arquitetura:

• Uma instância de autor
• Duas instâncias de publicação
• Dois Dispatchers

As diretrizes de arquitetura para AEM sites e AEM Assets estão ilustradas abaixo.

Diretrizes de arquitetura Tar para a AEM Sites

Diretrizes de arquitetura Tar para a AEM Assets

Diretriz de configurações do TarMK

Para um bom desempenho, você deve seguir as diretrizes de configuração apresentadas abaixo. Para obter instruções sobre como alterar as configurações, consulte esta página.

Benchmark de desempenho do TarMK

Especificações técnicas

Os testes de benchmark foram realizados com as seguintes especificações:

Resultados da marca de desempenho

MongoMK

O motivo principal para escolher o back-end de persistência do MongoMK sobre o TarMK é dimensionar as instâncias horizontalmente. Isso significa ter duas ou mais instâncias de autor ativas em execução contínua e usar o MongoDB como o sistema de armazenamento de persistência. A necessidade de executar mais de uma instância de autor geralmente resulta do fato de que a CPU e a capacidade de memória de um único servidor, suportando todas as atividades de criação simultâneas, não são mais sustentáveis.

Para obter mais informações sobre o TarMK, consulte Cenários de implantação e Armazenamento Mongo.

Diretrizes de arquitetura mínima do MongoMK

Para estabelecer um bom desempenho ao usar o MongoMK, você deve começar com a seguinte arquitetura:

• Três instâncias de autor
• Duas instâncias de publicação
• Três instâncias do MongoDB
• Dois Dispatchers

Diretrizes de configurações do MongoMK

Para um bom desempenho, você deve seguir as diretrizes de configuração apresentadas abaixo. Para obter instruções sobre como alterar as configurações, consulte esta página.

Benchmark de desempenho do MongoMK

Especificações técnicas

Os testes de benchmark foram realizados com as seguintes especificações:

Resultados do benchmark de desempenho

TarMK vs MongoMK

A regra básica que precisa ser levada em conta ao escolher entre os dois é que o TarMK foi projetado para desempenho, enquanto o MongoMK é usado para escalabilidade. O Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes em todos os cenários de implantação, tanto para as instâncias de Autor e Publicação do AEM.

O motivo principal para escolher o back-end de persistência do MongoMK sobre o TarMK é dimensionar as instâncias horizontalmente. Isso significa ter duas ou mais instâncias de autor ativas em execução contínua e usar o MongoDB como o sistema de armazenamento de persistência. A necessidade de executar mais de uma instância de autor geralmente resulta do fato de que a CPU e a capacidade de memória de um único servidor, suportando todas as atividades de criação simultâneas, não são mais sustentáveis.

Para obter mais detalhes sobre TarMK vs MongoMK, consulte Implantações recomendadas.

Diretrizes do TarMK vs MongoMk

Benefícios do TarMK

• Propósito criado para aplicativos de gerenciamento de conteúdo
• Os arquivos são sempre consistentes e podem ser copiados em backup usando qualquer ferramenta de backup baseada em arquivo
• Fornece um mecanismo de failover - consulte Cold Standby para obter mais detalhes
• Fornece alto desempenho e armazenamento de dados confiável com o mínimo de sobrecarga operacional
• TCO mais baixo (custo total de propriedade)

Critérios para escolher MongoMK

• Número de usuários nomeados conectados em um dia: nos milhares ou mais
• Número de usuários simultâneos: nas centenas ou mais
• Volume de ingestões de ativos por dia: em centenas de milhares ou mais
• Volume de edições de página por dia: em centenas de milhares ou mais
• Volume de pesquisas por dia: em dezenas de milhares ou mais

TarMK vs MongoMK Benchmarks

Cenário 1 Especificações técnicas

Resultados do benchmark de desempenho do cenário 1

Cenário 2 Especificações técnicas

Resultados do benchmark de desempenho do cenário 2

Diretrizes de escalabilidade de arquitetura para AEM Sites e ativos

Resumo das diretrizes de desempenho

As diretrizes apresentadas nesta página podem ser resumidas da seguinte maneira:

• TarMK com Datastore de Arquivos é a arquitetura recomendada para a maioria dos clientes:

  • Topologia mínima: uma instância de Autor, duas instâncias de Publicação, dois Dispatchers
  • Replicação sem binário ativada se o armazenamento de dados do arquivo for compartilhado

• MongoMK com File Datastore é a arquitetura recomendada para a escalabilidade horizontal da camada Autor:

  • Topologia mínima: três instâncias de Autor, três instâncias de MongoDB, duas instâncias de Publicação, dois Dispatchers
  • Replicação sem binário ativada se o armazenamento de dados do arquivo for compartilhado

• ​​Os notebooks devem ser armazenados no disco local, não em um NAS (Network Attached Storage, armazenamento conectado à rede)

• Ao usar Amazon S3:

  • O armazenamento de dados do Amazon S3 é compartilhado entre a camada Autor e Publicação
  • A replicação sem binário deve ser ativada
  • A coleta de lixo do armazenamento de dados requer uma primeira execução em todos os nós Autor e Publicação e, em seguida, uma segunda execução no Autor

• O índice personalizado deve ser criado além do índice pronto para uso com base nas pesquisas mais comuns

  • Índices Lucene devem ser usados para índices personalizados

• A personalização do fluxo de trabalho pode melhorar substancialmente o desempenho, por exemplo, remover a etapa de vídeo no fluxo de trabalho "Atualizar ativo", desativar os ouvintes que não são usados etc.

Para obter mais detalhes, leia também a página Implantações recomendadas .