AEM 6.4 chegou ao fim do suporte estendido e esta documentação não é mais atualizada. Para obter mais detalhes, consulte nossa períodos de assistência técnica. Encontre as versões compatíveis here.
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 |
Destino |
Assets |
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 |
|
|
Chrome |
Social |
Móvel |
Cluster de Autores |
IBM AIX |
JBoss |
|
|
RDB/MySQL |
RDBMS |
|
|
Safari |
Público |
Vários sites |
ASRP |
SUSE |
|
|
|
RDB/SQLServer |
|
|
|
|
Assets |
Commerce |
MSRP |
Apple OS |
|
|
|
|
|
|
|
|
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. O 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, ele é publicado em um segundo tipo de instância chamado de Instância de publicação 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 mais informações sobre a arquitetura de AEM, consulte Cenários típicos de implantação.
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 para atender às suas necessidades depende da finalidade da sua instância e do tipo de implantação que você está considerando. Para obter mais informações sobre Micro Kernels, consulte o Implantações recomendadas página.
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 Armazenamento de dados, enquanto a localização dos nós e propriedades de conteúdo é chamada de Loja de nós.
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. Contato Atendimento ao cliente do Adobe 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 a documentação adicional sobre o Adobe Managed Services.
Para recomendações sobre como implantar AEM no Azure ou no 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 seção requisitos técnicos página.
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 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 mais práticas recomendadas, 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 referencial específico, leia o campo Cenário da Especificações técnicas tabela.
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 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. Estes not o especificações mínimas necessário 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 desativada ATIVADO se o armazenamento de dados do arquivo 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, veja 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 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 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 | 32GB |
Disco | Magnético |
Java | Oracle JRE versão 8 |
Heap da JVM | 16GB |
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 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 desativada ATIVADO se o armazenamento de dados do arquivo 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, veja 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 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. |
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 | 32GB | 32GB |
Disco | Magnético - >IOPS de 1k | Magnético - >IOPS de 1k |
Java | Oracle JRE versão 8 | N/A |
Heap da JVM | 16GB | N/A |
Produto | AEM 6.2 | MongoDB 3.2 WiredTiger |
Nodestore | MongoMK | N/A |
Armazenamento de dados | DS de arquivo | 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 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 | 32GB | 32GB | |
Disco | Magnético - >IOPS de 1k | Magnético - >IOPS de 1k | |
Java | Oracle JRE versão 8 | N/A | |
JVM Heap16GB | 16GB | N/A | |
Produto | AEM 6.2 | MongoDB 3.2 WiredTiger | |
Nodestore | TarMK ou MongoMK | N/A | |
Armazenamento de dados | DS de arquivo | 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 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 | 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 |
JVM Heap16GB | 30GB | 30GB | N/A |
Produto | AEM 6.2 | AEM 6.2 | MongoDB 3.2 WiredTiger |
Nodestore | TarMK | MongoMK | N/A |
Armazenamento de dados | DS de arquivo | DS de arquivo |
N/A |
Cenário |
|
As diretrizes apresentadas nesta página podem ser resumidas da seguinte maneira:
TarMK com armazenamento de dados de arquivo é a arquitetura recomendada para a maioria dos clientes:
MongoMK com armazenamento de dados de arquivo é a arquitetura recomendada para a escalabilidade horizontal do nível Autor:
Nodestore deve ser armazenado 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 predefinido com base nas pesquisas mais comuns
A personalização do fluxo de trabalho pode melhorar substancialmente o desempenho, por exemplo, remoção da etapa de vídeo no fluxo de trabalho "Atualizar ativo", desativação de ouvintes que não são usados etc.
Para obter mais detalhes, leia também a Implantações recomendadas página.