Show Menu
TÓPICOS×

Diretrizes de desempenho

Esta página fornece orientações gerais sobre como otimizar o desempenho de sua implantação do AEM. Se você for novo no AEM, passe as páginas a seguir antes de começar a ler as diretrizes de desempenho:
As opções de implantação disponíveis para o AEM estão ilustradas abaixo (role para exibir 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
Comércio
MSRP
Apple OS
Ativação
Mídia dinâmica
JSRP
Móvel
Brand Portal
J2E
AoD
LiveFyre
Screens
Segurança do Documento
Process Mgt
aplicativo para desktop
As diretrizes de desempenho se aplicam principalmente ao AEM Sites.

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 de sites ou ativos AEM 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 às 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, atualizar do AEM 6.1 para o 6.2 ou do AEM 6.0 CRX2 para o 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 Data Store 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 do 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 do AEM, consulte O que é o AEM .

A arquitetura do AEM

Há três blocos componentes importantes para uma implantação do AEM. A Instância do autor 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 é acessado 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 do AEM, consulte Cenários de implantação típicos.

Micro Kernels

Micro Kernels atua como gerentes de persistência no AEM. Há três tipos de Micro Kernels usados com o 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 Implantações recomendadas 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 é conhecido como o Data Store , enquanto o local dos nós e propriedades do conteúdo é chamado de Node Store .
A Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes para as instâncias de autor e publicação do AEM.
O Micro Kernel do Banco de Dados Relacional está sob suporte restrito. Entre em contato com o Atendimento ao cliente da Adobe antes de usar esse tipo de Micro Kernel.

Data Store

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ós e armazenamentos de dados.
A Adobe recomenda escolher a opção de implantar o AEM no Azure ou Amazon Web Services (AWS) usando os Adobe Managed Services, onde os clientes se beneficiarão com uma equipe que tem a experiência e as habilidades de implantar e operar o AEM nesses ambientes de computação em nuvem. Consulte nossa documentação adicional sobre os Serviços gerenciados da Adobe.
Para obter recomendações sobre como implantar o AEM no Azure ou AWS, fora dos Serviços gerenciados da Adobe, recomendamos trabalhar diretamente com o provedor de nuvem ou um de nossos parceiros que ofereçam suporte à implantação do AEM no ambiente de nuvem de sua escolha. O provedor ou parceiro de nuvem selecionado é responsável pelas especificações de dimensionamento, design e implementação da arquitetura que eles suportarão para atender aos seus requisitos específicos de desempenho, carga, escalabilidade e segurança.
Para obter detalhes adicionais, consulte também a página de requisitos Plataformas compatíveis técnicos.

Pesquisar

Nesta seção estão listados os provedores de índice personalizados usados com o AEM. Para saber mais sobre a indexação, consulte Consultas Oak e Indexação .
Para a maioria das implantações, a Adobe recomenda usar o Índice Lucene. Você deve usar o Solr somente para escalabilidade em implantações especializadas e complexas.

Diretrizes de desenvolvimento

Você deve desenvolver o AEM com o objetivo de 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 APIs AEM 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 fluxos de trabalho 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 consultas 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 no AEM, leia Desenvolvimento - Noções básicas . Para obter mais práticas recomendadas, consulte Práticas recomendadas de desenvolvimento .

Cenários de benchmark

Todos os testes de referência mostrados nesta página foram realizados em laboratório.
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 Benchmark de desempenho TarMK 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.
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, 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 de Tar.

Diretrizes de arquitetura mínima do TarMK

As diretrizes mínimas de arquitetura apresentadas abaixo são para ambientes de produção e sites de alto tráfego. Essas não são as especificações Pré-requisitos mínimas necessárias para executar o AEM.
Para estabelecer um bom desempenho ao usar o TarMK, você deve começar pela seguinte arquitetura:
  • Uma instância de autor
  • Duas instâncias de publicação
  • Dois despacho
Veja a seguir as diretrizes de arquitetura para sites do AEM e ativos AEM.
A replicação sem binários deve ser ativada ​se o Repositório de Dados de Arquivo for compartilhado.
Diretrizes de arquitetura do Tar para o AEM Sites
Diretrizes de arquitetura do Tar para ativos AEM

Diretriz de configurações do TarMK

Para 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 inicialização do AEM para impedir que consultas expansivas 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 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 a gravação XMP de volta para o 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(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos
RAM
32GB
Disco
Magnético
Java
Oracle JRE versão 8
Heap JVM
16GB
Produto
AEM 6.2
Nodestore
TarMK
Armazenamento de dados
Arquivo DS
Cenário
Produto único: Ativos / 30 threads simultâneos

Resultados de benchmark de desempenho

Os números apresentados abaixo foram normalizados para 1 como linha de base e não são os números de débito reais.

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 permanente 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 Armazenamento Mongo 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 MongoDB
  • Dois despacho
Em ambientes de produção, o MongoDB sempre será usado como um conjunto de réplicas com um primário e dois secundários. Leituras e escritos vão para o primário e leituras podem ir para os secundários. Se o armazenamento não estiver disponível, um dos secundários pode ser substituído por um árbiter, mas os conjuntos de réplicas MongoDB sempre devem ser compostos por um número ímpar de instâncias.
A replicação sem binários deve ser ativada ​se o Repositório de Dados de Arquivo for compartilhado.

Diretrizes de configurações do MongoMK

Para 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 inicialização do AEM para impedir que consultas expansivas 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(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos
CPU Intel(R) Xeon(R) E5-2407 @2,40GHz, 8 núcleos
RAM
32GB
32GB
Disco
Magnético - >1 k IOPS
Magnético - >1 k IOPS
Java
Oracle JRE versão 8
N/A
Heap JVM
16GB
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

Os números apresentados abaixo foram normalizados para 1 como linha de base e não são os números de débito reais.

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. 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, 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 permanente 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 gerenciamento 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
  • Fornece armazenamento de dados confiável e de alto desempenho com o mínimo de 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

Benchmarks TarMK vs MongoMK

Os números apresentados abaixo foram normalizados para 1 como linha de base e não são números reais de débito.

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 32GB 32GB
Disco Magnético - >1 k IOPS Magnético - >1 k IOPS
Java Oracle JRE versão 8 N/A
Heap16 GB JVM 16GB 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

Para ativar o mesmo número de autores com MongoDB como com um sistema TarMK, você precisa de um cluster com dois nós AEM. Um cluster MongoDB de quatro nós pode lidar com 1,8 vezes o número de autores de uma instância TarMK. Um cluster MongoDB de oito nós pode lidar com 2,3 vezes o número de Autores de uma instância TarMK.
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 60GB 60GB 60GB
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 30GB 30GB 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 sites e ativos AEM

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
  • O notebook deve ser armazenado no disco local, não em um NAS (Network Attached Storage, armazenamento conectado à rede)
  • Ao usar o 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, em seguida, uma segunda execução em Autor
  • O índice personalizado deve ser criado além do índice de saída da caixa 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 Implantações recomendadas recomendadas.