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:

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

OBSERVAÇÃO

As diretrizes de desempenho se aplicam principalmente à 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 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:

chlimage_1

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.

chlimage_1-1

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.

chlimage_1-2

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

OBSERVAÇÃO

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.

CUIDADO

O Micro Kernel do Banco de Dados Relacional está sob suporte restrito. Entre em contato com o Atendimento ao cliente do Adobe antes de usar esse tipo de Micro Kernel.

chlimage_1-3

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.

OBSERVAÇÃO

A Adobe recomenda escolher a opção de implantar AEM no Azure ou nos serviços da Web da Amazon (AWS) usando os serviços gerenciados da Adobe, onde os clientes se beneficiarão de uma equipe que tem a experiência e as habilidades de implantar e operar 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 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 de 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 requisitos técnicos.

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.

OBSERVAÇÃO

Para a maioria das implantações, o Adobe recomenda o uso do Índice Lucene. Você deve usar o Solr somente para escalabilidade em implantações especializadas e complexas.

chlimage_1-4

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

OBSERVAÇÃO

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

OBSERVAÇÃO

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 mínimas necessárias para executar AEM.

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.

OBSERVAÇÃO

A replicação sem binários deve ser ativada ON se o Repositório de Dados de Ficheiros for partilhado.

Diretrizes da arquitetura Tar para AEM Sites

chlimage_1-5

Diretrizes da arquitetura Tar para AEM Assets

chlimage_1-6

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

OBSERVAÇÃO

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.

chlimage_1-7 chlimage_1-8

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
OBSERVAÇÃO

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.

OBSERVAÇÃO

A replicação sem binários deve ser ativada ON se o Repositório de Dados de Ficheiros for partilhado.

chlimage_1-9

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

OBSERVAÇÃO

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.

chlimage_1-10 chlimage_1-11

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

OBSERVAÇÃO

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

chlimage_1-12

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

OBSERVAÇÃO

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

chlimage_1-13

Diretrizes de escalabilidade da arquitetura para AEM Sites e ativos

chlimage_1-14

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.

Nesta página