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 |
|
|
|
|
|
|
|
|
|
|
|
As diretrizes de desempenho se aplicam principalmente à AEM Sites.
Você deve usar as diretrizes de desempenho nas seguintes situações:
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 consiste nos seguintes componentes:
Para obter mais informações sobre a plataforma AEM, consulte O que é 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 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.
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ó.
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 do Adobe antes de usar esse tipo de Micro Kernel.
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.
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.
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.
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.
Você deve se desenvolver para AEM visando desempenho e escalabilidade. Abaixo estão apresentadas várias práticas recomendadas que podem ser seguidas:
DO
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:
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.
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:
Cenário de combinação de produtos
AEM Sites + Ativos:
Cenário de caso de uso vertical
Mídia:
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.
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:
Veja a seguir as diretrizes de arquitetura para AEM sites e AEM Assets.
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
Diretrizes da arquitetura Tar para AEM Assets
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 |
|
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 |
|
Ativado Ativado Ativado |
Para obter mais detalhes sobre os parâmetros disponíveis, consulte esta página. |
Armazenamento de dados = Armazenamento de dados S3 |
|
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. |
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 |
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.
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.
Para estabelecer um bom desempenho ao usar o MongoMK, você deve start da seguinte arquitetura:
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 ON se o Repositório de Dados de Ficheiros for partilhado.
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 |
|
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 |
|
Ativado Ativado Ativado |
Para obter mais detalhes sobre os parâmetros disponíveis, consulte esta página. |
Armazenamento de dados = Armazenamento de dados S3 |
|
1048576 (1MB) ou menor 2-10% do tamanho máximo do heap |
Consulte também Configurações de armazenamento de dados. |
DocumentNodeStoreService |
|
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 |
|
mín. & máx. = 20 50000 |
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 |
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.
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.
Benefícios do TarMK
Critérios de escolha de 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.
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 |
|
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 |
|
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:
MongoMK com File Datastoreé a arquitetura recomendada para a escalabilidade horizontal da camada Autor:
Os notebooks devem ser armazenados no disco local, não em um armazenamento conectado à rede (NAS)
Ao usar Amazon S3:
O índice personalizado deve ser criado além do indexado predefinido com base nas pesquisas mais comuns
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.