AEM 6.x | Dicas para ajustar o desempenho

Conheça estratégias e dicas eficazes para otimizar o desempenho do Adobe Experience Manager (AEM), testes de carga, parâmetros JVM e ajuste de cache.

Descrição description

Ambiente

  • Adobe Experience Manager 6.4
  • Adobe Experience Manager 6.5

Problema/Sintomas

O tempo de resposta é insatisfatório quando os autores editam o conteúdo ou os sites respondem lentamente às solicitações do visitante.

Essas dicas de ajuste de desempenho podem ajudar a acelerar consultas e o desempenho.

Causa

Os seguintes fatores influenciam os problemas de desempenho no AEM:

  • Design impróprio
  • Código do aplicativo
  • Falta de armazenamento em cache
  • Configuração de E/S de disco defeituoso
  • Dimensionamento de memória
  • Largura de banda e latência da rede
  • AEM instalado em algumas versões selecionadas do windows 2008 e 2012, onde o gerenciamento de memória é um problema
  • Modificar as configurações prontas para uso conforme descrito abaixo pode ajudar a melhorar o desempenho no AEM.

Resolução resolution

Evitando problemas de desempenho

Estas são algumas etapas que você pode seguir para garantir que encontre e corrija problemas de desempenho antes que eles tenham impacto nos usuários:

  1. 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 a diretrizes de desempenho e diretrizes de monitoramento.

  2. 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 testes de desempenho podem ser encontradas aqui.

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

  4. Se você estiver usando o servidor Windows, revise este artigo.

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

  6. 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 sendo executado em uma VM, verifique se o pool de entropia está sempre > 1 K bits (use rngtools se necessário)
  7. 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.

  8. 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 Ativos de ajuste de desempenho.

  9. 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 Set queue.maxparallel para um valor que representa 50% dos núcleos da CPU do servidor que hospeda a instância do AEM. Por exemplo, para 8 núcleos de CPU, defina o valor como 4.

  10. 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 índice/mecanismo de consulta 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 esta artigo.
      • Crie os índices personalizados sob o 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:

      Cuidado: Ativando fastQuerySize resultados em respostas de consulta mais rápidas. No entanto, o AEM retorna contagens de resultados imprecisas para algumas consultas. Se você confiar na contagem precisa de resultados no seu aplicativo, não use fastQuerySize.

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

      • habilitar CopyOnRead (ativado por padrão desde o AEM 6.2)
      • habilitar CopyOnWrite (ativado por padrão desde o AEM 6.2)
      • habilitar Buscar previamente arquivos de índice (ativado 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 multivalor (Cadeia de caracteres)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 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 variável 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.

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

    • 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. Consulte 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
    • Implemente a lista de verificação de produção MongoDB:
      https://docs.mongodb.org/manual/administration/production-checklist/ - de acordo com o apoio do 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 esse parâmetro da string de consulta ao 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: open /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 contendo parâmetro oak.observação.queue-length=50000. Coloque-o sob o /crx—início rápido/instalação pasta.

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

  12. 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. Certifique-se de instalar os patches/hotfixes relacionados ao desempenho da microsoft (consulte KB 2731284) e Oracle.

    Uma opção alternativa é desativar o modo de mapa de memória adicionando tarmk.mode=32 in 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.

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

  14. Cloud Manager para clientes do Adobe Managed Services (AMS)
    Cloud Manager (Somente para clientes do AMS) permite que os clientes garantam uma implantação bem-sucedida do AEM com testes de desempenho orientados e dimensionamento automático.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f