Esta página fornece diretrizes gerais sobre como otimizar o desempenho da implantação do AEM. Se você não AEM, passe o mouse sobre 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 (rolar para exibir todas as opções):
AEM Produto |
Topologia |
Sistema Operacional |
Servidor de aplicativos |
JRE |
Segurança |
Micro kernel |
Armazenamento de dados |
Indexação |
Servidor Web |
Navegador |
Marketing Cloud |
Sites |
Não-HA |
Windows |
CQSE |
Oracle |
LDAP |
Tar |
Segmento |
Propriedade |
Apache |
Edge |
Target |
Ativos |
Publicar-HA |
Solaris |
WebLogic |
IBM |
SAML |
MongoDB |
Arquivo |
Lucene |
IIS |
IE |
Analytics |
Communities |
Autor-CS |
Chapéu Vermelho |
WebSphere |
HP |
Oauth |
RDB/Oracle |
S3/Azure |
Solr |
iPlanet |
FireFox |
Campaign |
Forms |
Author-Offload |
HP-UX |
Tomcat |
|
|
RDB/DB2 |
MongoDB |
|
|
Cromo |
Social |
Móvel |
Cluster de Autores |
IBM AIX |
JBoss |
|
|
RDB/MySQL |
RDBMS |
|
|
Safari |
Público |
Vários sites |
ASRP |
SUSE |
|
|
|
RDB/SQLServer |
|
|
|
|
Ativos |
Commerce |
MSRP |
SO Apple |
|
|
|
|
|
|
|
|
Ativação |
Dynamic Media |
JSRP |
|
|
|
|
|
|
|
|
|
Móvel |
Brand Portal |
J2E |
|
|
|
|
|
|
|
|
|
|
AoD |
|
|
|
|
|
|
|
|
|
|
|
LiveFyre |
|
|
|
|
|
|
|
|
|
|
|
Screens |
|
|
|
|
|
|
|
|
|
|
|
Segurança de documento |
|
|
|
|
|
|
|
|
|
|
|
Gerenciamento de processos |
|
|
|
|
|
|
|
|
|
|
|
Aplicativo de desktop do |
|
|
|
|
|
|
|
|
|
|
|
As diretrizes de desempenho se aplicam principalmente ao AEM Sites.
Você deve usar as diretrizes de desempenho nas seguintes situações:
Este capítulo fornece uma visão geral da arquitetura de AEM e 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 de AEM consiste nos seguintes componentes:
Para obter mais informações sobre a plataforma de AEM, consulte O que é AEM.
Há três blocos fundamentais importantes para uma implantação de AEM. A Instância do autor que é usada por autores, editores e aprovadores de conteúdo para criar e revisar o conteúdo. Quando o conteúdo é aprovado, ele é publicado em um segundo tipo de instância chamado Publicar instância de onde é acessado pelos usuários finais. O terceiro bloco de construção é o Dispatcher que é um módulo que lida com o armazenamento em cache e a filtragem de URL e é instalado no servidor da Web. Para obter informações adicionais sobre a arquitetura de AEM, consulte Cenários de implantação típicos.
Micro Kernels atuam 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.
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 Data Store, enquanto o local dos nós e propriedades de conteúdo é chamado de Node Store.
O Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes para as instâncias de Autor do AEM e Publicação.
O Micro Kernel do Banco de Dados Relacional está sob suporte restrito. Entre em contato com o Adobe Customer Care antes de usar esse tipo de Micro Kernel.
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 o projeto exigir um grande número de ativos de mídia, armazená-los no Arquivo ou no Data Store do Azure/S3 fará com que o acesso seja 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.
O Adobe recomenda escolher a opção de implantar AEM no Azure ou no Amazon Web Services (AWS) usando o Adobe Managed Services, 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 o Adobe Managed Services.
Para recomendações sobre como implantar AEM no Azure ou AWS, fora do Adobe Managed Services, recomendamos trabalhar diretamente com o provedor de nuvem ou um de nossos parceiros que oferecem 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, pelo design e pela implementação da arquitetura que ele oferecerá suporte para atender aos requisitos específicos de desempenho, carga, escalabilidade e segurança.
Para obter detalhes adicionais, consulte também a página technical requirements.
Listados nesta seção são os provedores de índice personalizados usados com o AEM. Para saber mais sobre indexação, consulte Consultas e Indexação do Oak.
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 desenvolver para AEM com o objetivo de desempenho e escalabilidade. Apresentamos abaixo uma série de 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 consultas sempre que possível
Não use o Sling Bindings para obter serviços OSGi no código Java, mas use:
Para obter mais detalhes sobre o desenvolvimento no AEM, leia Desenvolvimento - Noções básicas. Para obter práticas recomendadas adicionais, consulte Práticas recomendadas de desenvolvimento.
Todos os testes de benchmark exibidos nesta página foram executados em uma configuração de 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
AEM Assets:
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, especificando 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 e não as especificações mínimas necessárias para executar o AEM.
Para estabelecer um bom desempenho ao usar o TarMK, você deve começar com a seguinte arquitetura:
As diretrizes de arquitetura para AEM sites e AEM Assets estão ilustradas abaixo.
A replicação sem binário deve ser ativada ON se o Armazenamento de Dados de Arquivos for compartilhado.
Diretrizes de arquitetura Tar para a AEM Sites
Diretrizes de arquitetura Tar para a AEM Assets
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 esta página.
Configuração | Parâmetro | Valor | Descrição |
Filas de Trabalho Sling | 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 do Granite | Max Parallel |
Defina o valor para metade do número de núcleos da CPU | |
Parâmetros da JVM |
|
500000 100000 250000 Verdadeiro |
Adicione esses parâmetros da JVM no script de início de AEM para impedir que consultas expansivas 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 do Data Store. |
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 workflow gerencia XMP write-back para o binário original e define a data da última modificação no JCR. |
Os testes de benchmark foram realizados com as seguintes especificações:
Nó do autor | |
---|---|
Servidor | Hardware de metal nu (HP) |
Sistema Operacional | RedHat Linux |
CPU / núcleos | CPU Intel® Xeon® CPU E5-2407 @2,40GHz, 8 núcleos |
RAM | 32 GB |
Disco | Magnético |
Java | Oracle JRE versão 8 |
Heap da JVM | 16 GB |
Produto | AEM 6.2 |
Nodestore | TarMK |
Armazenamento de dados | DS de arquivo |
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 reais da taxa de transferência.
O motivo principal para escolher o back-end de persistência do MongoMK sobre o TarMK é dimensionar as instâncias horizontalmente. Isso significa ter duas ou mais instâncias de autor ativas em execução contínua e usar 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 CPU e a capacidade de memória de um único servidor, suportando todas as atividades de criação simultâneas, não são 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 começar com a seguinte arquitetura:
Em ambientes de produção, o MongoDB sempre será usado como um conjunto de réplicas com um primário e dois segundos. Leituras e gravações vão para o primário e as 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 árbitro, mas os conjuntos de réplicas do MongoDB devem sempre ser compostos por um número ímpar de instâncias.
A replicação sem binário deve ser ativada ON se o Armazenamento de Dados de Arquivos for compartilhado.
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 esta página.
Configuração | Parâmetro | Value (padrão) | Descrição |
Filas de Trabalho Sling | 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 do Granite | Max Parallel |
Defina o valor para metade do número de núcleos da CPU. | |
Parâmetros da JVM |
|
500000 100000 250000 Verdadeiro 60000 |
Adicione esses parâmetros da JVM no script de início de AEM para impedir que consultas expansivas 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 do Data Store. |
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. |
oak-observation |
|
mín. e máx. = 20 50000 |
Os testes de benchmark foram realizados com as seguintes especificações:
Nó Autor | Nó MongoDB | |
---|---|---|
Servidor | Hardware de metal nu (HP) | Hardware de metal nu (HP) |
Sistema Operacional | RedHat Linux | RedHat Linux |
CPU / núcleos | CPU Intel® Xeon® CPU E5-2407 @2,40GHz, 8 núcleos | CPU Intel® Xeon® CPU E5-2407 @2,40GHz, 8 núcleos |
RAM | 32 GB | 32 GB |
Disco | Magnético - >IOPS de 1k | Magnético - >IOPS de 1k |
Java | Oracle JRE versão 8 | N/A |
Heap da JVM | 16 GB | N/D |
Produto | AEM 6.2 | MongoDB 3.2 WiredTiger |
Nodestore | MongoMK | N/D |
Armazenamento de dados | DS de arquivo | N/D |
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 reais da taxa de transferência.
A regra básica que precisa ser levada em conta 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 motivo principal para escolher o back-end de persistência do MongoMK sobre o TarMK é dimensionar as instâncias horizontalmente. Isso significa ter duas ou mais instâncias de autor ativas em execução contínua e usar 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 CPU e a capacidade de memória de um único servidor, suportando todas as atividades de criação simultâneas, não são mais sustentáveis.
Para obter mais detalhes sobre TarMK vs MongoMK, consulte Implantações recomendadas.
Benefícios do TarMK
Critérios para escolher MongoMK
Os números apresentados abaixo foram normalizados para 1 como linha de base e não são números reais da taxa de transferência.
Nó OAK do autor | Nó MongoDB | ||
Servidor | Hardware de metal nu (HP) | Hardware de metal nu (HP) | |
Sistema Operacional | RedHat Linux | RedHat Linux | |
CPU / núcleos | CPU Intel(R) Xeon(R) CPU E5-2407 @2,40GHz, 8 núcleos | CPU Intel(R) Xeon(R) CPU E5-2407 @2,40GHz, 8 núcleos | |
RAM | 32 GB | 32 GB | |
Disco | Magnético - >IOPS de 1k | Magnético - >IOPS de 1k | |
Java | Oracle JRE versão 8 | N/D | |
JVM Heap16GB | 16 GB | N/D | |
Produto | AEM 6.2 | MongoDB 3.2 WiredTiger | |
Nodestore | TarMK ou MongoMK | N/D | |
Armazenamento de dados | DS de arquivo | N/D | |
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 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 | RedHat Linux | RedHat Linux | RedHat Linux |
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/D |
JVM Heap16GB | 30 GB | 30 GB | N/D |
Produto | AEM 6.2 | AEM 6.2 | MongoDB 3.2 WiredTiger |
Nodestore | TarMK | MongoMK | N/D |
Armazenamento de dados | DS de arquivo | DS de arquivo |
N/D |
Cenário |
|
As diretrizes apresentadas nesta página podem ser resumidas da seguinte maneira:
TarMK com Datastore de Arquivos é 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 NAS (Network Attached Storage, armazenamento conectado à rede)
Ao usar Amazon S3:
O índice personalizado deve ser criado além do índice pronto para uso com base nas pesquisas mais comuns
A personalização do fluxo de trabalho pode melhorar substancialmente o desempenho, por exemplo, remover a etapa de vídeo no fluxo de trabalho "Atualizar ativo", desativar os ouvintes que não são usados etc.
Para obter mais detalhes, leia também a página Implantações recomendadas .