Diretrizes de desempenho

Esta página fornece orientações gerais sobre como otimizar o desempenho da sua implantação de AEM. Se você for novo em AEM, passe as páginas a seguir antes de ler as diretrizes de desempenho do start:

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

As opções de implantação disponíveis para AEM são ilustradas abaixo (role para visualização em todas as opções):

AEM Produto	Topologia	Sistema Operacional	Servidor de aplicativos	JRE	Segurança	Kernel Micro	Armazenamento de dados	Indexação	Servidor Web	Navegador	Marketing Cloud
Sites	Não-HA	Windows	CQSE	Oracle	LDAP	Tar	Segmento	Propriedade	Apache	Borda	Target
Ativos	Publicar-HA	Solaris	WebLogic	IBM	SAML	MongoDB	Arquivo	Lucene	IIS	IE	Análise
Communities	Autor-CS	Chapéu vermelho	WebSphere	HP	Oauth	RDB/Oracle	S3/Azure	Solr	iPlanet	FireFox	Campanha
Forms	Descarga do autor	HP-UX	Tomcat			RDB/DB2	MongoDB			Cromo	Social
Móvel	Author-Cluster	IBM AIX	JBoss			RDB/MySQL	RDBMS			Safari	Público
Vários sites	ASRP	SUCO				RDB/SQLServer					Ativos
Commerce	MSRP	Apple OS									Ativação
Dynamic Media	JSRP										Móvel
Brand Portal	J2E
AoD
LiveFyre
Screens
Segurança do Documento
Process Mgt
aplicativo para desktop

Quando usar as Diretrizes de Desempenho

Você deve usar 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 compreender as opções disponíveis ao configurar o Micro Kernel, o Node Store e o Data Store (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.
• Atualizando para uma nova versão: Ao atualizar para uma nova versão, é importante entender as diferenças de desempenho em relação ao ambiente em execução. Por exemplo, atualizando de AEM 6.1 para 6.2 ou de AEM 6.0 CRX2 para 6.2 OAK.
• O tempo de resposta é lento: Quando a arquitetura de notebook selecionada não atender aos seus requisitos, é importante entender as diferenças de desempenho em comparação a outras opções de topologia. Por exemplo, implantar o TarMK em vez de MongoMK ou usar um Arquivo de armazenamento de dados em vez de um Amazon S3 ou Microsoft Azure Data Store.
• Adicionar mais autores: Quando a topologia TarMK recomendada não atender aos requisitos de desempenho e o upgrade do nó Autor atingir 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 de 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 entender as diferenças de desempenho em relação a 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 AEM e de 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 AEM consiste nos seguintes componentes:

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

A arquitetura AEM

Há três blocos componentes importantes para uma implantação AEM. A Instância do autor que é usada por autores, editores e aprovadores de conteúdo para criar e revisar conteúdo. Quando o conteúdo é aprovado, é publicado em um segundo tipo de instância chamada Instância de publicação de onde é acessada pelos usuários finais. O terceiro elemento é o Dispatcher, que é um módulo que lida com o armazenamento em cache e a 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 atua 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

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

Armazenamento de dados

Ao lidar com um grande número de binários, recomenda-se que um armazenamento de dados externo seja usado em vez dos armazenamentos de nó padrão para maximizar o desempenho. Por exemplo, se seu projeto exigir um grande número de ativos de mídia, armazená-los no Arquivo ou no Arquivo de Dados do Azure/S3 tornará o acesso 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ó e Armazenamento de Dados.

Pesquisar

Nesta seção estão listados os provedores de índice personalizados usados com AEM. Para saber mais sobre indexação, consulte Oak Query e Indexing.

Diretrizes de desenvolvimento

Você deve se desenvolver para AEM visando desempenho e escalabilidade. Abaixo estão apresentadas várias práticas recomendadas que podem ser seguidas:

DO

• Aplicar separação de apresentação, lógica e conteúdo
• Usar AEM APIs existentes (por exemplo: Linho) e ferramentas (ex: Replicação)
• Desenvolver no contexto do conteúdo real
• Desenvolver para obter um cache ideal
• Minimizar o número de salvamentos (ex: usando workflows transitórios)
• Verifique se todos os pontos finais HTTP são RESTful
• Restringir o escopo da observação do JCR
• Tenha cuidado com o fio assíncrono

NÃO

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

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

• Não use query sempre que possível

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

  • @Referência em um componente DS
  • @Injetar em um modelo Sling
  • sling.getService() em uma classe Sightly Use
  • sling.getService() em um JSP
  • um ServiceTracker
  • acesso direto ao registro do serviço OSGi

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

Cenários de benchmark

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

Ativos AEM:

• Interações do usuário: Procurar ativos / Pesquisar ativos / Baixar ativos / Ler metadados do ativo / Atualizar metadados do ativo / Carregar ativo / Executar fluxo de trabalho de upload do ativo
• Modo de execução: usuários simultâneos, interação única 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 / Pesquisa do autor
• Interações do usuário do Assets: Procurar ativos / Pesquisar ativos / Baixar ativos / Ler metadados do ativo / Atualizar metadados do ativo / Carregar ativo / Executar fluxo de trabalho de upload do 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%), Ler Página (10.9%), Criar Sessão (2.6%), Ativar Página Do Conteúdo (1.7%), Criar Página Do Conteúdo (0.4%), Criar Parágrafo (4.3%), Editar Parágrafo (0.9%), Componente Da Imagem (0.9%), Pesquisar Ativos (20%), Ler Metadados Do Ativo (8.5%), Baixar Ativo (4.2%), Pesquisar Ativo (0.2%), Atualizar Metadados de Ativo (2.4%), Carregar Ativo (1.2%), Procurar Projeto (4.9%), Ler Projeto (6.6%), Adicionar Ativo do Projeto (1.2%), Adicionar Site do 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 que especificam 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 mínimas de arquitetura do TarMK

Para estabelecer um bom desempenho ao usar o TarMK, você deve start da seguinte arquitetura:

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

Veja a seguir as diretrizes de arquitetura para AEM sites e AEM Assets.

Diretrizes da arquitetura Tar para AEM Sites

Diretrizes da arquitetura Tar para AEM Assets

Diretriz de configurações do TarMK

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

Configuração	Parâmetro	Valor	Descrição
Sling Job Queues	queue.maxparallel	Defina o valor para metade do número de núcleos da CPU.	Por padrão, o número de threads simultâneos por fila de trabalhos é igual ao número de núcleos da CPU.
Fila de Fluxo de Trabalho Transitório Granite	Max Parallel	Defina o valor para metade do número de núcleos da CPU
Parâmetros JVM	Doak.queryLimitInMemory Doak.queryLimitReads Dupdate.limit Doak.fastQuerySize	500000 100000 250000 Verdadeiro	Adicione esses parâmetros JVM no script de start AEM para impedir que query expansivos sobrecarreguem os sistemas.
Configuração do índice Lucene	CopyOnRead CopyOnWrite Prefetch Index Files	Ativado Ativado Ativado	Para obter mais detalhes sobre os parâmetros disponíveis, consulte esta página.
Armazenamento de dados = Armazenamento de dados S3	maxCachedBinarySize cacheSizeInMB	1048576 (1MB) ou menor 2-10% do tamanho máximo do heap	Consulte também Configurações de armazenamento de dados.
Fluxo de trabalho do Ativo de atualização do DAM	Transient Workflow	verificado	Esse fluxo de trabalho controla a atualização de ativos.
Writeback de metadados DAM	Transient Workflow	verificado	Esse fluxo de trabalho gerencia XMP gravação no binário original e define a última data modificada no JCR.

Benchmark de desempenho TarMK

Especificações técnicas

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

	Nó do autor
Servidor	Hardware Bare Metal (HP)
Sistema Operacional	Linux RedHat
CPU / núcleos	CPU Intel® Xeon® E5-2407 @2,40GHz, 8 núcleos
RAM	32 GB
Disco	Magnético
Java	Oracle JRE versão 8
Heap JVM	16 GB
Produto	AEM 6.2
Nodestore	TarMK
Armazenamento de dados	Arquivo DS
Cenário	Produto único: Ativos / 30 threads simultâneos

Resultados do benchmark de desempenho

MongoMK

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

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

Diretrizes mínimas de arquitetura do MongoMK

Para estabelecer um bom desempenho ao usar o MongoMK, você deve start da seguinte arquitetura:

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

Diretrizes de configurações do MongoMK

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

Configuração	Parâmetro	Valor (padrão)	Descrição
Sling Job Queues	queue.maxparallel	Defina o valor para metade do número de núcleos da CPU.	Por padrão, o número de threads simultâneos por fila de trabalhos é igual ao número de núcleos da CPU.
Fila de Fluxo de Trabalho Transitório Granite	Max Parallel	Defina o valor para metade do número de núcleos da CPU.
Parâmetros JVM	Doak.queryLimitInMemory Doak.queryLimitReads Dupdate.limit Doak.fastQuerySize Doak.mongo.maxQueryTimeMS	500000 100000 250000 Verdadeiro 60000	Adicione esses parâmetros JVM no script de start AEM para impedir que query expansivos sobrecarreguem os sistemas.
Configuração do índice Lucene	CopyOnRead CopyOnWrite Prefetch Index Files	Ativado Ativado Ativado	Para obter mais detalhes sobre os parâmetros disponíveis, consulte esta página.
Armazenamento de dados = Armazenamento de dados S3	maxCachedBinarySize cacheSizeInMB	1048576 (1MB) ou menor 2-10% do tamanho máximo do heap	Consulte também Configurações de armazenamento de dados.
DocumentNodeStoreService	cache nodeCachePercentage childrenCachePercentage diffCachePercentage docChildrenCachePercentage prevDocCachePercentage persistentCache	2048 35 (25) 20 (10) 30 (5) 10 (3) 4 (4) ./cache,size=2048,binary=0,-compact,-compress	O tamanho padrão do cache é definido como 256 MB. Tem impacto no tempo necessário para executar a invalidação do cache.
observação do carvalho	thread pool length	mín. & máx. = 20 50000

Benchmark de desempenho MongoMK

Especificações técnicas

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

	Nó Autor	Nó MongoDB
Servidor	Hardware Bare Metal (HP)	Hardware Bare Metal (HP)
Sistema Operacional	Linux RedHat	Linux RedHat
CPU / núcleos	CPU Intel® Xeon® E5-2407 @2,40GHz, 8 núcleos	CPU Intel® Xeon® E5-2407 @2,40GHz, 8 núcleos
RAM	32 GB	32 GB
Disco	Magnético - >1 k IOPS	Magnético - >1 k IOPS
Java	Oracle JRE versão 8	N/A
Heap JVM	16 GB	N/A
Produto	AEM 6.2	MongoDB 3.2 WiredTiger
Nodestore	MongoMK	N/A
Armazenamento de dados	Arquivo DS	N/A
Cenário	Produto único: Ativos / 30 threads simultâneos	Produto único: Ativos / 30 threads simultâneos

Resultados do benchmark de desempenho

TarMK vs MongoMK

A regra básica que precisa ser considerada 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 principal motivo para escolher o backend de persistência MongoMK sobre TarMK é dimensionar as instâncias horizontalmente. Isso significa ter duas ou mais instâncias do autor ativas em execução o tempo todo e usar o MongoDB como sistema de armazenamento de persistência. A necessidade de executar mais de uma instância do autor geralmente resulta do fato de a CPU e a capacidade de memória de um único servidor, suportando todas as atividades de criação simultâneas, não serem mais sustentáveis.

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

Diretrizes TarMK vs MongoMk

Benefícios do TarMK

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

Critérios de escolha de 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

Especificações técnicas do cenário 1

	Nó OAK do autor	Nó MongoDB
Servidor	Hardware Bare Metal (HP)	Hardware Bare Metal (HP)
Sistema Operacional	Linux RedHat	Linux RedHat
CPU / núcleos	CPU Intel(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos	CPU Intel(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos
RAM	32 GB	32 GB
Disco	Magnético - >1 k IOPS	Magnético - >1 k IOPS
Java	Oracle JRE versão 8	N/A
Heap16 GB JVM	16 GB	N/A
Produto	AEM 6.2	MongoDB 3.2 WiredTiger
Nodestore	TarMK ou MongoMK	N/A
Armazenamento de dados	Arquivo DS	N/A
Cenário	Produto único: Ativos / 30 threads simultâneos por execução

Resultados do benchmark de desempenho do cenário 1

Especificações técnicas do cenário 2

	Nó TarMK do autor	Nó MongoMK do autor	Nó MongoDB
Servidor	AWS c3.8xlarge	AWS c3.8xlarge	AWS c3.8xlarge
Sistema Operacional	Linux RedHat	Linux RedHat	Linux RedHat
CPU / núcleos	32	32	32
RAM	60 GB	60 GB	60 GB
Disco	SSD - IOPS de 10 mil	SSD - IOPS de 10 mil	SSD - IOPS de 10 mil
Java	Oracle JRE versão 8	Oracle JRE versão 8	N/A
Heap16 GB JVM	30 GB	30 GB	N/A
Produto	AEM 6.2	AEM 6.2	MongoDB 3.2 WiredTiger
Nodestore	TarMK	MongoMK	N/A
Armazenamento de dados	Arquivo DS	Arquivo DS	N/A
Cenário	Caso de uso vertical: Threads simultâneos de mídia/2000

Resultados do benchmark de desempenho do cenário 2

Diretrizes de escalabilidade da arquitetura para AEM Sites e ativos

Resumo das diretrizes de desempenho

As orientações apresentadas nesta página podem resumir-se da seguinte forma:

• O TarMK com File Datastoreé a arquitetura recomendada para a maioria dos clientes:

  • Topologia mínima: uma instância do autor, duas instâncias de publicação, dois Dispatchers
  • Replicação sem binários ativada se o Repositório de Dados de 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ários ativada se o Repositório de Dados de Arquivo for compartilhado

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

• Ao usar Amazon S3:

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

• O índice personalizado deve ser criado além do indexado predefinido com base nas pesquisas mais comuns

  • Os índices de Lucene devem ser usados para os índices personalizados

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

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