AEM 6.x | Dicas para ajustar o desempenho

Implemente e execute testes de carga que simulam cenários realistas em instâncias de autor e de publicação. Pesquisar e definir a carga esperada é uma etapa crucial nesse processo. Essa etapa ajuda a demonstrar se o aplicativo AEM, a arquitetura e a instalação do AEM terão bom desempenho quando estiverem ativos em um ambiente de produção.
Os resultados deste exercício ajudam a determinar se há um erro de configuração, problema de aplicativo, dimensionamento, problema de hardware ou outro problema que afete o desempenho do sistema. Consulte também as diretrizes de desempenho e diretrizes de monitoramento.

Além do teste de carga, o teste de tensão ajuda a definir a carga máxima que o sistema pode suportar. Esse teste pode ajudar você a se preparar para picos de tráfego. Mais informações sobre o teste de desempenho podem ser encontradas aqui.

Instale os service packs do AEM recomendados, cumulative fix packs e hotfixes: atualizações de versão do Adobe Experience Manager.

Se você estiver usando o Windows Server, consulte este artigo.

Se você estiver planejando carregar grandes quantidades de ativos (imagens, vídeos e assim por diante) no AEM, aplique as práticas recomendadas do Assets.

Provisionar RAM suficiente e evitar saturação de E/S
Se você pretende executar a produção em qualquer escala, o ambiente Linux deve ser provisionado com a mesma RAM que os arquivos tar do segmento crescerão entre a compactação offline (ou picos de compactação online). Além disso, os itens a seguir evitarão a saturação de E/S.

• Separar SO, dados e discos de registro
• Montar discos de dados com Noatime.
• Defina buffers de leitura antecipada como 32 no disco de dados.
• Idealmente, use o XFS sobre o ext4 nos discos de dados.
• Se o RedHat estiver em execução em uma VM, verifique se o pool de entropia tem sempre > bits de 1 K (use rngtools, se necessário)

Desativar páginas grandes transparentes no Linux
O AEM executa leituras/gravações refinadas, enquanto as Páginas Grandes Transparentes do Linux são otimizadas para operações grandes. Portanto, é recomendável desabilitar Páginas Grandes Transparentes ao usar o armazenamento Mongo ou Tar.

Habilitar workflows transitórios
Os workflows transitórios podem ser usados para qualquer workflow que:

• são executados com frequência.
• não precisam do histórico do workflow.

Eles gerarão um aumento no desempenho nessas situações.
Normalmente, esse caso de uso é atendido quando há grandes volumes de assimilação de ativos.
Siga o procedimento documentado em Performance tuning Assets.

Ajuste de filas de trabalhos do Sling
O upload em massa de ativos grandes normalmente é um processo que consome muitos recursos. Por padrão, o número de threads simultâneos por fila de trabalhos é igual ao número de núcleos da CPU. Dessa forma, essa configuração de valor pode causar um impacto geral no desempenho e um alto consumo de heap Java.
A Adobe recomenda que você não exceda 50% dos núcleos da CPU. Para ajustar esse valor, vá para o seguinte: https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration
Defina queue.maxparallel com um valor que represente 50% dos núcleos da CPU do servidor que hospeda sua instância do AEM. Por exemplo, para 8 núcleos de CPU, defina o valor como 4.

Ajuste do repositório do Oak
Primeiro, verifique se você tem a versão mais recente do Oak instalada para sua instância do AEM 6. Verifique a página de hotfixes recomendados mencionada acima.

Otimizações de Mecanismo de Consulta/Índice do Oak

• Crie índices oak personalizados para todas as consultas de pesquisa usadas com frequência.

  • Para obter informações sobre como analisar consultas lentas, consulte este artigo.
  • Crie os índices personalizados no nó oak:index para todas as propriedades de pesquisa que você deseja pesquisar seguindo este artigo.
  • Para cada índice personalizado baseado em Lucene, tente definir a configuração includedPaths (String) para restringir o índice e aplicá-lo somente a determinados caminhos de conteúdo. Em seguida, restrinja as pesquisas aplicáveis aos caminhos incluídos pelo índice.

• Parâmetros JVM
  Adicione esses parâmetros JVM no script de inicialização AEM para evitar que consultas extensas sobrecarreguem os sistemas. Observe que esses são valores padrão a partir do AEM 6.3.

  • Doak.queryLimitInMemory=500000 (consulte também documentação do Oak)
  • Doak.queryLimitReads=100000 (consulte também documentação do Oak)
  • Dupdate.limit=250000 (somente para DocumentNodeStore, por exemplo, MongoMK, RDBMK)

  A opção a seguir também pode melhorar o desempenho, mas altera o significado da chamada de tamanho do resultado. Especialmente, somente as restrições de consulta que fazem parte do índice usado são consideradas ao calcular o tamanho.
  Além disso, as ACLs não são aplicadas aos resultados, portanto, os nós que não estiverem visíveis para a sessão atual ainda serão incluídos na contagem retornada. Dessa forma, a contagem retornada pode ser maior que o número real de resultados e a contagem precisa só pode ser determinada iterando pelos resultados:

  • Doak.fastQuerySize=true (consulte também Tamanho do Resultado na documentação do Oak)

  Cuidado: a habilitação de fastQuerySize resulta em respostas de consulta mais rápidas. No entanto, o AEM retorna contagens de resultados imprecisas para algumas consultas. Se você depender das contagens precisas de resultados no aplicativo, não use o fastQuerySize.

• Configuração do índice Lucene
  Abra /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService e

  • habilitar CopyOnRead (habilitado por padrão desde o AEM 6.2)
  • habilitar CopyOnWrite (habilitado por padrão desde o AEM 6.2)
  • habilitar Buscar Arquivos de Índice previamente (habilitado por padrão desde o AEM 6.2)

  Consulte https://jackrabbit.apache.org/oak/docs/query/lucene.html para obter mais informações sobre os parâmetros disponíveis
  Como alguns caminhos não precisam ser indexados, você pode fazer o seguinte:
  No CRXDE Lite, vá para /oak:index/lucene, defina uma propriedade de cadeia de caracteres de vários valores (String)chamada excludedPaths com esses valores /var, /etc/workflow/instances, /etc/replication.

• Armazenamento de dados
  Se você usa o AEM Assets ou tem um aplicativo AEM que usa amplamente arquivos binários, a Adobe recomenda o uso de um armazenamento de dados externo. O uso de um armazenamento de dados externo ajuda a garantir o máximo desempenho. Consulte a documentação para obter instruções detalhadas.
  Ao usar um FileDataStore, ajuste cacheSizeInMB para uma porcentagem do heap disponível. Um valor conservador é 2% do heap máximo. Por exemplo, para um heap de 8 GB:

  • maxCachedBinarySize=1048576
  • cacheSizeInMB=164

  Observe que maxCachedBinarySize está definido como 1 MB (1048576). Dessa forma, ele só armazena em cache arquivos com no máximo 1 MB. Ajustar essa configuração a um valor menor também pode fazer sentido.
  Ao lidar com um grande número de binários, você deseja maximizar o desempenho. Portanto, o Adobe recomenda que um armazenamento de dados externo seja usado em vez dos armazenamentos de nó padrão. Além disso, o Adobe recomenda que você ajuste os seguintes parâmetros:

  • maxCachedBinarySize=10485760
  • cacheSizeInMB=4096

  Observação: a configuração cacheSizeInMB pode fazer com que o processo Java fique sem memória se for definido como muito alto. Por exemplo, se você tiver o tamanho máximo de heap definido como 8 GB (-Xmx8g) e esperar que o AEM e seu aplicativo utilizem um heap combinado de 4 GB, faz sentido definir cacheSizeInMB como 82 em vez de 164. No intervalo de 2 a 10% do heap máximo é uma configuração segura. No entanto, a Adobe recomenda que você valide as alterações de configuração com testes de carga e, ao mesmo tempo, monitore a utilização da memória.

Ajuste do armazenamento Mongo

• Tamanho do cache do MongoBlobStore: O blobstore é usado para armazenar e ler objetos binários grandes. Internamente, o armazenamento com cache é implementado, o que divide os binários em blocos relativamente pequenos (dados ou código de hash ou hash indireto), de modo que cada bloco se ajuste na memória. Em uma configuração padrão, o MongoBlobStore usa um tamanho de cache fixo de 16 MB. Para implantações em que mais RAM está disponível e o armazenamento de blobs é acessado com frequência (por exemplo, quando o índice Lucene é grande), aumente o tamanho do cache. Esse tamanho do cache só se aplica quando você usa MongoBlobStore (padrão), não ao usar um blobstore externo.

  • Você pode definir o tamanho do cache (em MB) por meio da configuração blobCacheSize em DocumentNodeStoreService.
    Por exemplo: blobCacheSize=1024
  • Revise também AEM-MongoDB checklist.

• Tamanho do cache de documentos: Para otimizar o desempenho dos nós de leitura do MongoDB, você precisa ajustar os tamanhos dos caches do DocumentNodeStore. O tamanho padrão do cache é definido como 256 MB, que é distribuído entre vários caches usados no DocumentNodeStore. Ver http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

  • Você pode definir o tamanho do cache (MB) por meio da configuração de cache em DocumentNodeStoreService. Por exemplo, cache=2048.

  • Defina todas as seguintes configurações de cache em crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config e, em seguida, faça um teste de carregamento com vários valores para ver qual é a configuração ideal para seu ambiente. Observe que a porcentagem de cache restante é fornecida para o cache de documentos:

    • cache=2048
    • nodeCachePercentage=35
    • childCachePercentage=20
    • diffCachePercentage=30
    • docChildrenCachePercentage=10

  • Com a configuração acima, as porcentagens somam 95%. Os 5% restantes do cache são fornecidos para documentCache. documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

  • Ao distribuir as porcentagens de cache, certifique-se de que o cache deixado para documentCache não seja muito grande. Ou seja, mantenha-o com um máximo de 500 MB ou menos; um documentCache grande pode levar a um aumento no tempo necessário para executar a invalidação de cache.

• Configurações de cache no AEM 6.2 com Oak 1.4.x:

  • No AEM 6.2, foram feitas alterações no modo como essas configurações de cache funcionam. No AEM 6.2 com Oak 1.4, há um novo cache: prevDocCache. Você pode configurar esse cache usando a configuração prevDocCachePercentage. O padrão é 4.
  • O documentCache usa o cache restante em MB (configuração de cache menos o tamanho de todos os outros caches): documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache

• Implementar a lista de verificação de produção do MongoDB:
  https://docs.mongodb.org/manual/administration/production-checklist/ - de acordo com o suporte ao Mongo DB, muitos dos itens têm um grande impacto no desempenho. Em caso de dúvidas, entre em contato diretamente com o Suporte MongoDB.

• Desempenho de leitura: Adicione este parâmetro da cadeia de caracteres de consulta à URL do Mongo DB em cada nó AEM: ?readPreference=secondaryPreferred
  Esse parâmetro informa ao sistema para fazer leituras do secundário, o que oferece algum desempenho de leitura adicional.

• Aumentar pool de threads para observação do oak: abra /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.fatory Defina o nome como oak-observe e defina o tamanho mínimo e máximo do pool como 20.

• Aumentar comprimento da fila de observação: Crie um arquivo chamado com.adobe.granite.repository.impl.SlingRepositoryManager.cfg que contém o parâmetro oak.observo.queue-length=50000. Coloque-o na pasta /crx—quickstart/install.

• Evitar consultas de longa execução: Defina a propriedade do sistema nos parâmetros JVM: -Doak.mongo.maxQueryTimeMS=60000 para evitar que as consultas sejam executadas por mais de 1 minuto.

Ajuste do armazenamento TAR
Os microkernels não chamam diretamente arquivos mapeados por memória. No entanto, o JDK usa internamente arquivos mapeados por memória para uma leitura eficiente. Em determinados sistemas operacionais Windows de 64 bits, poderia ocorrer uma falha na limpeza de arquivos mapeados de memória e no consumo de toda a memória nativa do sistema operacional. Instale os patches/hotfix de desempenho da microsoft (consulte KB 2731284) e do Oracle.

Uma opção alternativa é desabilitar o modo de mapa de memória adicionando tarmk.mode=32 em SegmentNodeStoreService.config até que o problema do sistema operacional seja resolvido. A desativação torna a E/S intensa. Certifique-se de elevar o limite de bloqueio de página de E/S.

Limpeza de revisão TarMK (compactação)
A partir do AEM 6.3, a compactação online (também conhecida como limpeza de revisão online) é ativada por padrão. Consulte esta página para obter mais informações.

Cloud Manager para usuários do Adobe Managed Services (AMS)
O Cloud Manager (somente usuários do AMS) permite garantir uma implantação bem-sucedida do AEM com testes de desempenho guiados e dimensionamento automático.