Diretrizes de desempenho performance-guidelines
Esta página fornece diretrizes gerais sobre como otimizar o desempenho da implementação do AEM. Se você é novo no AEM, reveja as seguintes páginas antes de começar a ler as diretrizes de desempenho:
Ilustradas abaixo estão as opções de implantação disponíveis para AEM (role a tela para exibir todas as opções):
Quando usar as diretrizes de desempenho when-to-use-the-performance-guidelines
Use as diretrizes de desempenho nas seguintes situações:
- Primeira implantação: ao planejar a implantação do AEM Sites ou do Assets pela primeira vez, é importante entender as opções disponíveis. Especialmente ao configurar o Micro Kernel, o Armazenamento de nós e o Armazenamento de dados (em comparação às configurações padrão). Por exemplo, alterar as configurações padrão do Armazenamento de dados para TarMK para Armazenamento de dados de arquivo.
- Atualizando 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 o 6.2 OAK.
- O tempo de resposta está lento: quando a arquitetura do Nodestore selecionada não atende aos seus requisitos, é importante entender as diferenças de desempenho em comparação a outras opções de topologia. Por exemplo, implantar TarMK em vez de MongoMK ou usar um Armazenamento de dados de arquivo em vez de um Armazenamento de dados Amazon S3 ou Microsoft® Azure.
- Adicionando mais autores: quando a topologia TarMK recomendada não estiver atendendo aos requisitos de desempenho e o upsizing do nó Autor tiver atingido a capacidade máxima disponível, entenda as diferenças de desempenho. Compare com o uso de MongoMK com três ou mais nós de Autor. Por exemplo, implantar MongoMK em vez de TarMK.
- Adicionando mais conteúdo: quando a arquitetura de Repositório de Dados recomendada não atender aos seus requisitos, é importante entender as diferenças de desempenho em comparação a outras opções de Repositório de Dados. Exemplo: usar o Amazon S3 ou o Microsoft® Azure Data Store em vez de um File Data Store.
Introdução introduction
Este capítulo fornece uma visão geral da arquitetura do AEM e seus componentes mais importantes. Também fornece diretrizes de desenvolvimento e descreve os cenários de teste usados nos testes de referência TarMK e MongoMK.
A plataforma AEM the-aem-platform
A plataforma AEM consiste nos seguintes componentes:
Para obter mais informações sobre a plataforma AEM, consulte O que é AEM.
A arquitetura do AEM the-aem-architecture
Há três componentes importantes para uma implantação do AEM. A Instância do Autor, que é usada pelos autores, editores e aprovadores de conteúdo para criar e revisar o conteúdo. Quando o conteúdo é aprovado, ele é publicado em um tipo de segunda instância chamado Instância do Publish de onde é acessado pelos usuários finais. O terceiro bloco de construção é o Dispatcher, que é um módulo que lida com armazenamento em cache e filtragem de URL e está instalado no servidor Web. Para obter informações adicionais sobre a arquitetura AEM, consulte Cenários de implantação típicos.
Micro Kernels micro-kernels
Os micronúcleos atuam como gerenciadores de persistência no AEM. Há três tipos de Micro Kernels usados com AEM: TarMK, MongoDB e Banco de Dados Relacional (sob suporte restrito). Escolher um para atender às suas necessidades depende da finalidade da instância e do tipo de implantação que você está considerando. Para obter informações adicionais sobre Micro Kernels, consulte a página Implantações recomendadas.
Nodestore 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 Armazenamento de Dados, enquanto o local dos nós e propriedades de conteúdo é chamado de Armazenamento de Nós.
Armazenamento de dados data-store
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 seu projeto requer muitos ativos de mídia, armazená-los no Arquivo ou no Armazenamento de dados do Azure/S3 torna mais rápido acessá-los do que armazená-los diretamente em um MongoDB.
Para obter mais detalhes sobre as opções de configuração disponíveis, consulte Configurando Nó e Repositórios de Dados.
Pesquisar search-features
Listados nesta seção estão os provedores de índice personalizados usados com AEM. Para saber mais sobre indexação, consulte Consultas e indexação do Oak.
Diretrizes de desenvolvimento development-guidelines
Desenvolva para AEM visando desempenho e escalabilidade. Estas são as práticas recomendadas que você pode seguir:
FAZER
- Aplicar separação de apresentação, lógica e conteúdo
- Usar APIs (por exemplo: Sling) e ferramentas (por exemplo: Replication) do AEM existentes
- Desenvolver no contexto do conteúdo real
- Desenvolver para uma capacidade de armazenamento em cache ideal
- Minimizar o número de salvamentos (por exemplo: usando fluxos de trabalho transitórios)
- Verifique se todos os pontos de extremidade HTTP são RESTful
- Restringir o escopo de observação do JCR
- Considere o thread assíncrono
NÃO
-
Não use APIs JCR diretamente, se você puder
-
Não altere /libs, mas use sobreposições
-
Não usar consultas sempre que possível
-
Não use Ligações Sling 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 do AEM, leia Desenvolvimento - Noções básicas. Para obter práticas recomendadas adicionais, consulte Práticas recomendadas de desenvolvimento.
Cenários de benchmark benchmark-scenarios
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 referência de desempenho específico, leia o campo Cenário na tabela Especificações técnicas.
Cenário de produto único
AEM Assets:
- Interações do usuário: Navegar no Assets/Pesquisar no Assets/Baixar ativo/Ler metadados de ativo/Atualizar metadados de ativo/Fazer upload de ativo/Executar upload de fluxo de trabalho de ativo
- Modo de execução: usuários simultâneos, única interação por usuário
Cenário de mix de produtos
AEM Sites + Assets:
- Interações de usuário do Sites: Ler página de artigo / Ler página / Criar parágrafo / Editar parágrafo / Criar página de conteúdo / Ativar página de conteúdo / Pesquisar autor
- Interações de usuário do Assets: Navegar no Assets/Pesquisar Assets/Baixar ativo/Ler metadados de ativo/Atualizar metadados de ativo/Fazer upload de ativo/Executar upload de fluxo de trabalho 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:
Read Article Page (27.4%), Read Page (10.9%), Create Session (2.6%), Activate Content Page (1.7%), Create Content Page (0.4%), Create Paragraph (4.3%), Edit Paragraph (0.9%), Image Component (0.9%), Browse Assets (20%), Read Asset Metadata (8.5%), Download Asset (4.2%), Search Asset (0.2%), Update Asset Metadata (2.4%), Upload Asset (1.2%), Browse Project (4.9%), Read Project (6.6%), Project Add Asset (1.2%), Project Add Site (1.2%), Create Project (0.1%), Author Search (0.4%)- Modo de execução: usuários simultâneos, interações mistas por usuário
TarMK tarmk
Este capítulo fornece as diretrizes gerais de desempenho para TarMK especificando os requisitos mínimos de arquitetura e a configuração das configurações. Os testes de referência também são apresentados para maior clarificação.
A Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes em todos os cenários de implantação, para as instâncias do AEM Author e Publish.
Para obter mais informações sobre TarMK, consulte Cenários de Implantação e Armazenamento Tar.
Diretrizes de arquitetura mínima da TarMK tarmk-minimum-architecture-guidelines
Para estabelecer um bom desempenho ao usar TarMK, você deve começar com a seguinte arquitetura:
- Uma instância de Author
- Duas instâncias do Publish
- Dois Dispatchers
Ilustradas abaixo estão as diretrizes de arquitetura para sites AEM e AEM Assets.
Diretrizes de arquitetura Tar para o AEM Sites
Diretrizes de arquitetura Tar para o AEM Assets
Diretriz de configurações TarMK tarmk-settings-guideline
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 Otimização do Desempenho.
Benchmark de desempenho TarMK tarmk-performance-benchmark
Especificações técnicas technical-specifications
Os testes de referência foram realizados nas seguintes especificações:
Resultados do Benchmark de Desempenho performance-benchmark-results
MongoMK mongomk
O principal motivo para escolher o back-end de persistência MongoMK em vez do TarMK é dimensionar as instâncias horizontalmente. Essa capacidade significa ter duas ou mais instâncias de autor ativas sempre em execução e usando 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 capacidade da CPU e da memória de um único servidor, que suporta todas as atividades de criação simultâneas, não é mais sustentável.
Para obter mais informações sobre TarMK, consulte Cenários de Implantação e Armazenamento Mongo.
Diretrizes de arquitetura mínima do MongoMK mongomk-minimum-architecture-guidelines
Para estabelecer um bom desempenho ao usar o MongoMK, você deve começar pela seguinte arquitetura:
- Três instâncias de autor
- Duas instâncias do Publish
- Três instâncias do MongoDB
- Dois Dispatchers
Diretrizes de configurações do MongoMK mongomk-settings-guidelines
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 Otimização do Desempenho.
Benchmark de desempenho MongoMK mongomk-performance-benchmark
Especificações técnicas technical-specifications-1
Os testes de referência foram realizados nas seguintes especificações:
Resultados do Benchmark de Desempenho performance-benchmark-results-1
TarMK vs MongoMK tarmk-vs-mongomk
A regra básica para considerar ao escolher entre os dois é que o TarMK é projetado para desempenho, enquanto o MongoMK é usado para escalabilidade. A Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes em todos os cenários de implantação, para as instâncias do AEM Author e Publish.
O principal motivo para escolher o back-end de persistência MongoMK em vez do TarMK é dimensionar as instâncias horizontalmente. Essa funcionalidade significa ter duas ou mais instâncias de autor ativas sempre em execução e usando 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 capacidade da CPU e da memória de um único servidor, que suporta todas as atividades de criação simultâneas, não é mais sustentável.
Para obter mais detalhes sobre TarMK vs MongoMK, consulte Implantações Recomendadas.
Diretrizes TarMK vs MongoMk tarmk-vs-mongomk-guidelines
Vantagens do TarMK
- Desenvolvido especificamente para aplicativos de gerenciamento de conteúdo
- Os arquivos são sempre consistentes e podem ser submetidos a backup usando qualquer ferramenta de backup baseada em arquivos
- Fornece um mecanismo de failover - consulte Modo de Espera a Frio para obter mais detalhes
- Oferece alto desempenho e armazenamento de dados confiável com sobrecarga operacional mínima
- TCO mais baixo (custo total de propriedade)
Critério para escolher MongoMK
- Número de usuários nomeados conectados em um dia: milhares ou mais
- Número de usuários simultâneos: centenas ou mais
- Volume de assimilaçõ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
Referenciais TarMK vs MongoMK tarmk-vs-mongomk-benchmarks
Especificações técnicas do cenário 1 scenario-technical-specifications
Resultados do teste de desempenho do cenário 1 scenario-performance-benchmark-results
Especificações técnicas do cenário 2 scenario-technical-specifications-1
Resultados do teste de desempenho do cenário 2 scenario-performance-benchmark-results-1
Diretrizes de escalabilidade da arquitetura para AEM Sites e Assets architecture-scalability-guidelines-for-aem-sites-and-assets
Resumo das diretrizes de desempenho summary-of-performance-guidelines
As diretrizes apresentadas nesta página podem ser resumidas da seguinte maneira:
-
TarMK com File Datastore - A arquitetura recomendada para a maioria dos clientes:
- Topologia mínima: uma instância de autor, duas instâncias do Publish, dois Dispatchers
- Replicação sem binários ativada se o armazenamento de dados de arquivos estiver compartilhado
-
MongoMK com File Datastore - A arquitetura recomendada para escalabilidade horizontal da camada do Autor:
- Topologia mínima: três instâncias de autor, três instâncias MongoDB, duas instâncias Publish, dois Dispatchers
- Replicação sem binários ativada se o armazenamento de dados de arquivos estiver compartilhado
-
Nodestore - Armazenado no disco local, não um NAS (armazenamento conectado à rede)
-
Ao usar o Amazon S3:
- O armazenamento de dados do Amazon S3 é compartilhado entre o nível do Autor e do Publish
- A replicação sem binários deve estar ativada
- A coleta de lixo do armazenamento de dados exige uma primeira execução em todos os nós do Author e do Publish, depois uma segunda execução em Author
-
O índice personalizado deve ser criado além do índice pronto - com base nas pesquisas mais comuns
- Os índices Lucene devem ser usados para os índices personalizados
-
A personalização do fluxo de trabalho pode melhorar substancialmente o desempenho - Remova a etapa de vídeo do fluxo de trabalho "Atualizar ativo", desabilite os ouvintes que não são usados e assim por diante.
Para obter mais detalhes, leia também a página Implantações Recomendadas.