Observação:

Você está lendo a versão das dicas de ajuste de desempenho do Adobe Experience Manager 6.x. Este artigo também está disponível para versão 5.x.

O tempo de resposta está lento para edição e para solicitações de visitantes

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

Causa

Os seguintes fatores influenciam problemas de desempenho no AEM:

  • Design impróprio
  • Código de aplicação
  • Falta de armazenamento em cache
  • Configuração de E/S de disco errada
  • Dimensionamento de memória
  • Largura de banda de rede e latência
  • 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, conforme descrito abaixo, pode ajudar a melhorar o desempenho no AEM.

Evitando problemas de desempenho

Veja algumas etapas para garantir que você encontre e corrija problemas de desempenho antes que eles afetem seus usuários:

  1. Implemente e execute testes de carga que simulem cenários realistas nas instâncias de autor e de publicação. A pesquisa e a definição da carga esperada é um passo crucial nesse processo. Esta etapa ajuda a demonstrar se a arquitetura do aplicativo AEM, além da instalação, terão um bom desempenho ao operar em um ambiente de produção.

    Os resultados deste exercício ajudam a determinar se há um erro de configuração, problema com o aplicativo, dimensionamento, problema de hardware ou outro problema que afeta o desempenho do sistema. Veja também as diretrizes de desempenho e diretrizes de monitoramento

  2. Além do teste de carga, o teste de estresse 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 recomendados do AEM, pacotes de correção cumulativos e hotfixes:

    https://helpx.adobe.com/br/experience-manager/aem-releases-updates.html

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

  5. Se você planeja carregar grandes quantidades de Ativos (imagens, vídeos e assim por diante) no AEM, certifique-se de aplicar as Melhores práticas de ativos.

  6. Provisione RAM suficiente e evite a saturação de E/S

    Se você pretende executar a produção em qualquer escala, o ambiente Linux deverá ser provisionado com o máximo de RAM, já que os arquivos tar do segmento aumentarão entre a compactação off-line (ou os picos de compactação online).  Além disso, o seguinte evitará saturação de E/S.

    • Discos separados de sistema operacional /Dados/Log
    • Montar discos de dados com noatime
    • defina buffers de leitura antecipada para <32 no disco de dados.
    • O ideal é usar o xfs em vez do ext4 nos discos de dados.
    • Se em RedHat executando em uma VM, certifique-se de que o pool de entropia seja sempre> 1K bits (use rngtools se necessário)
  7. Desativar Páginas Enormes e Transparentes no Linux

    O AEM executa leituras/escritas refinadas, enquanto o Linux Transparent Huge Pages é otimizado para operações grandes, portanto, recomenda-se desativar Transparent Huge Pages ao usar armazenamento Mongo ou Tar.

Ativando fluxo de trabalho transitórios

Fluxos de trabalho transitórios podem ser usados para quaisquer fluxo de trabalho que:

  • sejam executados com freqüência.
  • não precisem do histórico do fluxo de trabalho.

Eles irão gerar um aumento de desempenho nessas situações.

Este caso de uso é normalmente encontrado quando há altos volumes de ingestão de ativos.

Siga o procedimento documentado em https://helpx.adobe.com/br/experience-manager/6-4/assets/using/performance-tuning-guidelines.html#Workflows

Ajustando Filas de Trabalho de Sling

O upload em massa de ativos grandes é normalmente um processo que requer muitos recursos. Por padrão, o número de encadeamentos simultâneos por fila de tarefas é igual ao número de núcleos da CPU. Dessa forma, a configuração de valor pode causar um impacto geral no desempenho e alto consumo de heap Java.

A Adobe recomenda que você não exceda 50% dos núcleos da CPU. Para ajustar este valor, vá para o seguinte:

http://<host>:<port> /system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration

Defina queue.maxparallel para um valor que represente 50% dos núcleos da CPU do servidor que hospeda suas instâncias do AEM. Por exemplo, para 8 núcleos de CPU, defina o valor como 4.

Ajustando seu Oak Repository

Primeiro, verifique se você tem a última versão do Oak instalada para as suas instâncias do AEM 6. Verifique a página de hotfixes recomendada mencionada acima.

Otimizações do mecanismo de consulta/índice do Oak

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

    • Para obter informações sobre como analisar consultas lentas, veja este artigo.
    • Crie os índices personalizados nooak:index nó para todas as propriedades de pesquisa com as quais deseja pesquisar seguindo este artigo.
    • Para cada índice personalizado baseado no Lucene, tente definir a configuração de includedPaths (String []) para restringir a aplicação do índice a apenas a determinados caminhos de conteúdo. Em seguida, restrinja as pesquisas aplicáveis aos caminhos incluídos pelo índice.
  2. Parâmetros da JVM

    Inclua esses parâmetros da JVM no script de início do AEM para evitar que as consultas expansivas sobrecarreguem os sistemas. Observe que estes são valores padrão iniciando com o AEM 6.3.

    • -Doak.queryLimitInMemory=500000 (veja também Documentação do Oak)
    • -Doak.queryLimitReads = 100000 (ver também Documentação do Oak)
    • -Atualização.limit = 250000 (somente para DocumentNodeStore, por exemplo. MongoMK,RDBMK)

    A seguinte opção poderia também melhorar o desempenho, mas altera o significado do tamanho da chamada resultante. Principlamente, apenas 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 estão visíveis para a sessão atual ainda serão incluídos na contagem retornada. Assim, a contagem retornada poderá ser maior que o número de resultados e a contagem precisa só poderá ser determinada pela iteração feita por meio dos resultados:

  3. Configuração do índice do Lucene

    Abra /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderServiceand

    • habilite CopyOnRead (ativado por padrão desde o AEM 6.2)
    • habilite CopyOnWrite (ativado por padrão desde o AEM 6.2)
    • habilite Arquivos de Indexação Pré-busca (ativados por padrão desde o AEM 6.2)

    Consulte http://jackrabbit.apache.org/oak/docs/query/lucene.html para mais informações sobre os parâmetros disponíveis

    Como alguns caminhos não precisam ser indexados, você poderá fazer o seguinte:

    No CRXDE Lite, acesse /oak:index/lucene, defina uma propriedade de sequência de caracteres com vários valores (sequência de caracters[])com nome excludedPaths com estes valores /var, /etc/workflow/instances, /etc/replication.

  4. Armazenamento de dados

    Se você usa AEM Assets ou tem um aplicativo AEM que usa arquivos binários extensivamente, a Adobe recomenda que você use umarmazenamento de dados externo. Usar um armazenamento de dados externo ajuda a garantir o máximo desempenho.  Consulte documentaçãopara instruções detalhadas.

    Ao usar um FileDataStore, ajuste o cacheSizeInMB para uma porcentagem do seu 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 para 1 MB (1048576). Dessa forma, ele apenas armazena em cache arquivos com um máximo de 1 MB.  Ajustar essa configuração para um valor menor também poderá fazer sentido.

    Ao lidar com um grande número de binários, você desejará maximizar o desempenho. Portanto, a Adobe recomenda que um externoarmazenamento de dados externoseja usado em vez dos armazenamentos de nó padrão. Além disso, a Adobe recomenda que você ajuste os seguintes parâmetros:

    • maxCachedBinarySize=10485760
    • cacheSizeInMB=4096

Observação:

A configuração cacheSizeInMB poderá fazer com que o processo Java fique sem memória, caso ele esteja definido como muito alto. Caso tenha o tamanho de heap máximo configurado para 8 GB (-Xmx8g) e espere que o AEM e seu aplicativo utilizem um heap combinado de 4 GB, é recomendável definir cacheSizeInMB para 82 em vez de 164. O 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 o teste de carga e, ao mesmo tempo, monitore a utilização da memória.

Ajuste de armazenamento do Mongo

  1. Tamanho do cache do MongoBlobStore: Oblobstoreé usado para armazenar e ler grandes objetos binários. Internamente, o armazenamento com cache é implementado, o que divide osbinários emblocos relativamente pequenos (dados ou código hash ou hash indireto), para que cada bloco se encaixe na memória. 

    Em uma configuração padrão, o MongoBlobStore usa um tamanho de cache fixo de 16MB.  Para implantações nas quais mais RAM está disponível e o armazenamento de blobs é acessado com freqüência (por exemplo, quando o índice do Lucene é grande), aumente o tamanho do cache. Esse tamanho de cache só se aplica quando você usa o MongoBlobStore (padrão), não quando usa umblobstore.

  2. Tamanho do cache de documentos: para otimizar o desempenho dos nós de leitura do MongoDB, você precisará 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ê poderá configurar o tamanho do cache (MB) por meio da configuração de cache no DocumentNodeStoreService. Por exemplo, cache=2048.
    • Defina todas as seguintes configurações de cache emcrx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.configand e, em seguida, carregue o teste com vários valores para ver qual é a configuração ideal para o seu ambiente. Observe que o percentual de cache restante é dado ao cache de documentos:
      • cache=2048
      • nodeCachePercentage=35
      • childrenCachePercentage=20
      • diffCachePercentage=30
      • docChildrenCachePercentage=10
    • Com a configuração acima, as porcentagens totalizam 95%.  Os 5% restantes do cache são fornecidos para documentCache.
        documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache
    • Ao distribuir as porcentagens de cache, assegure-se de que o cache deixado para documentCache não seja muito grande. Ou seja, mantenha até ~500 MB no máximo ou menos; um documentCache grande pode levar a um aumento no tempo gasto para executar a invalidação do cache.
  3. Configurações de cache no AEM 6.2 com o Oak 1.4.x:

    • No AEM 6.2, alterações foram feitas na maneira como essas configurações de cache funcionam. No AEM 6.2 com o Oak 1.4, há um novo cache: prevDocCache.  Você poderá configurar esse cache usando a configuração prevDocCachePercentage.O padrãoé 4.
    • OdocumentCache usa o MB restante do cache (configuração de cache menos o tamanho de todos os outros caches):
      documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache - prevDocCache
  4. Implementar a lista de verificação de produção do MongoDB
    http://docs.mongodb.org/manual/administration/production-checklist/ - de acordo com o suporte do Mongo DB, muitos dos itens na listatêmum grande impacto no desempenho. Para qualquer dúvida, entre em contato diretamente com o Suporte do MongoDB.

  5. Desempenho de leitura: Adicione este parâmetro de sequência de consulta ao seu URL do Mongo DB em cada nó do AEM: ?readPreference=secondaryPreferred
    Esse parâmetro informa ao sistema para fazer leituras a partir do secundário, o que fornece algum desempenho de leitura adicional.

  6. Aumente o pool de encadeamento para oak-observation: abra /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory
    Defina o nome para oak-observation e defina o tamanho mínimo e máximo do pool para 20.

  7. Aumentar o comprimento da fila de observação: Criar um arquivo chamado com.adobe.granite.repository.impl.SlingRepositoryManager.cfg contendo o parâmetro oak.observation.queue = 50000 . Coloque-o na pasta /crx-­‐quickstart/install.

  8. Evite consultas demoradas: Defina a propriedade do sistema na JVM parâmetros: -Doak.mongo.maxQueryTimeMS=60000 para evitar que as consultas demorem mais de 1 minuto.

Ajuste de armazenamento de tar

Micro kernels não chamam diretamente arquivos mapeados na memória. No entanto, o JDK usa internamente arquivos mapeados na memória para leitura eficiente. Em determinados sistemas operacionais Windows de 64 bits, pode haver falhas na limpeza de arquivos mapeados na memória e no consumo de toda a memória nativa do sistema operacional. Certifique-se de instalar os patches/hotfixes relacionados ao desempenho damicrosoft(Consulte KB 2731284) e Oracle.

TarMK revisão de limpeza (compactação)

Para o AEM 6.2, a Adobe recomenda que você use compactação off-line, por meio da ferramenta oak-run. Confira também o Guia de Manutenção do AEM 6.x.

Começando com o AEM 6.3, a compactação on-line (também conhecida como revisão de limpeza on-line) é ativada por padrão. Consulte este artigo para obter mais informações. Visite também a revisão de limpeza on-line Perguntas frequentes.

Cloud Manager para clientes do Adobe Managed Services (AMS)

Cloud Manager (Somente clientes AMS) permite que os clientes garantam a implantação bem-sucedida do AEM com um teste de desempenho guiado e autoescalonamento.

O que fazer a seguir?

Para obter mais ajuda sobre os problemas de desempenho do seu AEM:

  1. Junte-se à discussão nos Fóruns da Adobe para qualquer pergunta ou comentários.

  2. Receba suporte oficial

    1. Colete os seguintes dados:
      1. Saída de Profiler
      2. Despejos de encadeamento
      3. Todos os arquivos de log
    2. Entre em contato com o Atendimento ao Cliente AEM

Esta obra está licenciada sob uma licença não adaptada da Creative Commons Attribution-Noncommercial-Share Alike 3.0  As publicações do Twitter™ e do Facebook não são cobertas pelos termos do Creative Commons.

Avisos legais   |   Política de privacidade online