Práticas recomendadas para testes de desempenho

Introdução

O teste de desempenho é uma parte importante de qualquer implantação de AEM. Dependendo dos requisitos do cliente, o teste de desempenho pode ser realizado nas instâncias de publicação, nas instâncias do autor ou em ambos.

Esta documentação destacará estratégias e metodologias gerais de realização de testes de desempenho, bem como algumas das ferramentas disponibilizadas pelo Adobe para auxiliar no processo. Por fim, vamos analisar algumas das ferramentas disponíveis no AEM 6 para auxiliar no ajuste do desempenho, tanto de uma análise de código como da perspectiva de configuração do sistema.

Simular realidade

O que é mais importante ao executar testes de desempenho é garantir que você imite um ambiente de produção o mais próximo possível. Embora isso possa ser frequentemente difícil, é imperativo garantir a exatidão desses testes. Ao trabalhar na criação de testes de desempenho, é importante ter os seguintes pontos em consideração:

  • Conteúdo semelhante à produção

Muitas medidas de desempenho no AEM, como o tempo de resposta da consulta, podem ser afetadas pelo tamanho do conteúdo no sistema. É importante garantir que o ambiente de teste tenha o mais próximo possível de uma cópia dos dados de produção.

  • Código de produção

A versão AEM e os hotfixes implantados em produção devem ser os mesmos no ambiente de teste. Também é importante testar a versão do código implantada na produção.

  • Configuração de hardware e rede semelhante à produção

Os testes serão sem sentido sem um ambiente que se assemelhe ao da produção. Idealmente, as especificações de hardware, as interfaces de rede, os balanceadores de carga e a CDN devem ser idênticos à produção no ambiente de teste.

  • Carga de produção

Muitos problemas de desempenho não são vistos até que o sistema esteja sob carga pesada. Os bons ensaios de desempenho devem simular a carga em que os sistemas de produção estarão no seu pico.

Definir metas

Antes de iniciar os ensaios de desempenho, é necessário definir requisitos não funcionais para especificar os tempos de carga e resposta. Se você estiver migrando de um sistema existente, verifique se o tempo de resposta é semelhante aos valores de produção atuais. Para carga, é melhor pegar a carga de pico atual e duplicá-la. Isso garantirá que o site possa continuar a ter um bom desempenho enquanto cresce.

Ferramentas

There are many commercially available performance testing tools on the market. Ao executar uma ferramenta de geração de carga, é importante garantir que os computadores que estão executando os testes tenham largura de banda de rede suficiente. Caso contrário, quando a máquina de teste atingir os limites de sua conexão, nenhuma carga adicional será gerada no ambiente em teste.

Ferramentas de teste

  • Adobe's Dia difícil A ferramenta pode ser usada para gerar carga em instâncias AEM e coletar dados de desempenho. A equipe de engenharia de AEM da Adobe usa a ferramenta para fazer o teste de carregamento do próprio produto AEM. Os scripts executados em Tough Day são configurados por meio de arquivos de propriedade e arquivos XML JMX. Para obter mais informações, consulte o Documentação do Dia difícil.

  • AEM fornece ferramentas prontas para uso para ver rapidamente consultas, solicitações e mensagens de erro problemáticas. For more information, see the Diagnosis Tools section of the Operations Dashboard documentation.

  • O Apache fornece um produto chamado JMeter que podem ser usados para testes de desempenho e carga, bem como comportamento funcional. Ele é um software de código aberto e gratuito, mas tem um conjunto de recursos menor do que os produtos corporativos e uma curva de aprendizado mais acentuada. O JMeter pode ser encontrado no site da Apache em https://jmeter.apache.org/

  • Carregar Executador é um produto de teste de carga de nível empresarial. Uma versão de avaliação gratuita está disponível. Mais informações podem ser encontradas em https://www.microfocus.com/en-us/products/loadrunner-load-testing/overview

  • Ferramentas de teste de carga baseadas em nuvem como Neustar também pode ser usado.

  • Quando se trata de testar sites móveis ou responsivos, um conjunto separado de ferramentas precisa ser usado. Eles funcionam diminuindo a largura de banda da rede, simulando conexões móveis mais lentas, como 3G ou EDGE. Entre as ferramentas mais utilizadas estão:

    • Condicionador de links de rede - fornece uma interface de usuário fácil de usar e funciona em um nível relativamente baixo na pilha de rede. Ele inclui versões para OS X e iOS;
    • Charles - um aplicativo proxy de depuração da Web que, além de várias outras utilizações, fornece controle de rede. Versions are provided for Windows, OS X and Linux.

Ferramentas de otimização

Monitoramento

O Monitorar desempenho a documentação é um bom recurso para ferramentas e métodos que podem ser usados para diagnosticar problemas e identificar áreas para ajuste.

Modo de desenvolvedor na interface do usuário de toque

Um dos novos recursos na interface de toque do AEM 6 é o Modo do desenvolvedor. Da mesma forma que os autores podem alternar entre os modos de edição e visualização, os desenvolvedores podem alternar para o modo desenvolvedor na interface do autor para ver o tempo de renderização de cada um dos componentes na página e ver rastreamentos de pilha de quaisquer erros. Para obter mais informações sobre o modo de desenvolvedor, consulte este Apresentação de Gems CQ.

Usar o rlog.jar para ler os logs de solicitação

Para obter uma análise mais abrangente dos logs de solicitação em um sistema de AEM, rlog.jar pode ser usado para pesquisar e classificar o request.log arquivos que AEM gerados. This jar file is included with an AEM installation in the /crx-quickstart/opt/helpers folder. Para obter mais informações sobre a ferramenta de log e o log de solicitações em geral, consulte o Monitoramento e manutenção documentação.

A ferramenta Explain Query

O Explique a ferramenta Query em ACS AEM Tools podem ser usados para exibir os índices usados ao executar um query. Isso pode ser muito útil ao otimizar consultas de execução lenta.

Ferramentas PageSpeed

As ferramentas PageSpeed da Google oferecem análise do site para seguir as práticas recomendadas para o desempenho da página, bem como um plug-in que pode ser instalado junto com o dispatcher em uma instância do Apache para obter otimizações adicionais. Para obter mais informações, consulte o Site de ferramentas do PageSpeed.

Ambiente de criação

Realização de testes

Para realizar testes de desempenho no ambiente do autor, é necessário simular a experiência dos autores de produção. Isso significa que as instalações do autor devem conter todos os componentes, pacotes OSGi, personalização da interface do usuário, índices personalizados e quaisquer outras adições que você tenha em vigor para as instâncias do autor de produção.

Há muitas estruturas de automação disponíveis projetadas para testes de desempenho e carga. Os scripts personalizados podem ser gravados nessas ferramentas e reproduzidos para simular um número máximo de autores que executam atividades de ativação e criação de conteúdo semelhantes simultaneamente. É recomendável usar a ferramenta Tough Day para simular atividades como o upload de milhares de ativos ou a ativação de um grande número de páginas.

Para os tipos de ambientes que têm requisitos de carregamento pesado de ativos ou criação de páginas, é fundamental usar ferramentas como Tough Day para garantir que o ambiente opere com eficiência em carga de pico. WebDAV é uma ferramenta que não requer scripts e também pode ser usada para carregar grandes quantidades de ativos.

Etapas específicas do MongoDB

Em sistemas com back-end do MongoDB, o AEM fornece vários JMX MBeans que precisam ser monitoradas ao executar testes de carga ou desempenho:

  • O Estatísticas de Cache Consolidadas MBean. Ele pode ser acessado diretamente indo até:

https://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D6%2Cname%3D%22Consolidated+Cache+statistics%22%2Ctype%3D%22ConsolidatedCacheStats%22

Para o cache nomeado Document-Diff, a taxa de ocorrência deve estar acima .90. Se a taxa de ocorrência cair abaixo de 90%, é provável que você precise modificar seu DocumentNodeStoreService configuração. O suporte ao produto Adobe pode recomendar configurações ideais para seu ambiente.

  • O Estatísticas do Repositório Oak Feijão. Ele pode ser acessado diretamente indo até:

https://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D16%2Cname%3D%22Oak+Repository+Statistics%22%2Ctype%3D%22RepositoryStats%22

O ObservationQueueMaxLength A seção mostrará o número de eventos na fila de observação do Oak nas últimas horas, minutos, segundos e semanas. Encontre o maior número de eventos na seção "por hora". Esse número precisa ser comparado ao oak.observation.queue-length configuração. Se o número mais elevado mostrado para a fila de observação exceder o valor de queue-length configuração:

  1. Crie um arquivo chamado: com.adobe.granite.repository.impl.SlingRepositoryManager.cfg contendo o parâmetro oak.observation.queue‐length=50000
  2. Coloque-o na pasta /crx-quickstart/install.
OBSERVAÇÃO

Veja também o artigo KB sobre AEM 6.x | Dicas de ajuste de desempenho

A configuração padrão é 10.000, mas a maioria das implantações geralmente precisa aumentá-la para 20.000 ou 50.000.

Ambiente de publicação

Realização de testes

A parte mais importante de uma implantação que precisa ser submetida a testes de carga é o ambiente de publicação ou dispatcher voltado para o usuário final.

Ferramentas de testes automatizados de terceiros podem ser usadas para testar o desempenho do site. Essas ferramentas permitirão registrar as etapas pelas quais os usuários passarão no site e executar muitas dessas sessões ao mesmo tempo para simular a carga típica de um site de produção.

A maioria dos sites de produção tem otimizações em vigor, como o armazenamento em cache do dispatcher e uma rede de entrega de conteúdo em vigor. Ao testar, você precisa garantir que essas otimizações também estejam disponíveis para o ambiente de teste. Além de monitorar os tempos de resposta para os usuários finais, também é necessário monitorar as métricas do sistema nos servidores de publicação e despachantes para garantir que o sistema não seja restrito pelos recursos de hardware.

Em um sistema que não requer um alto nível de personalização, o dispatcher deve armazenar a maioria das solicitações em cache. Como resultado, a carga na instância de publicação deve permanecer relativamente plana. Se um alto nível de personalização for necessário, é recomendável usar tecnologias como iFrames ou solicitações de AJAX para o conteúdo personalizado, de forma a permitir o máximo possível de armazenamento em cache do dispatcher.

Para testes básicos, o Apache Bench pode ser usado para medir os tempos de resposta do servidor da Web e ajudar a criar carga para medir coisas como vazamentos de memória. Para obter mais informações, consulte o exemplo na Documentação de monitoramento.

Solução de problemas de desempenho

Após executar testes de desempenho na instância do autor, todos os problemas precisarão ser investigados, diagnosticados e resolvidos. Você pode usar várias ferramentas e técnicas ao executar análises e solucionar problemas:

  • Você pode inspecionar o Log de desempenho da solicitação no Painel de operações. Essa ferramenta pode ser usada para identificar solicitações de página lentas

  • Analise consultas de execução lenta com o Ferramenta Desempenho da Consulta

  • Observe a lista de erros em busca de erros ou avisos. Para obter mais informações, consulte Registro

  • Monitore recursos de hardware do sistema, como utilização de memória e CPU, E/S de disco ou E/S de rede. Esses recursos são frequentemente as causas de gargalos de desempenho

  • Optimize the architecture of the pages and how they are addressed to minimize the usage of URL parameters to allow for as much caching as possible

  • Siga as Otimização de desempenho e Dicas para ajuste de desempenho documentação

  • Se houver problemas com a edição de determinadas páginas ou componentes em instâncias do autor, use o Modo de desenvolvedor da interface sensível ao toque para inspecionar a página em questão. Isso fornecerá um detalhamento de cada área de conteúdo na página, bem como seu tempo de carregamento

  • Reduza todos os JS e CSS no site. Para obter mais informações sobre como fazer isso, consulte esta seção publicação do blog.

  • Elimine o CSS e o JS incorporados dos componentes. Eles devem ser incluídos e minificados com as bibliotecas do lado do cliente para minimizar o número de solicitações necessárias para renderizar a página

  • Use ferramentas do navegador, como a guia Rede do Chrome para inspecionar as solicitações do servidor e ver quais estão demorando mais.

Once problem areas are identified, application code can be inspected for performance optimizations. Qualquer recurso pronto para uso AEM que não esteja funcionando corretamente pode ser resolvido com o Suporte ao Adobe.

Nesta página