Práticas recomendadas para testes de desempenho best-practices-for-performance-testing

Introdução introduction

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.

Essa 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 simulating-reality

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:

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.

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.

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.

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 setting-goals

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 tools

Há muitas ferramentas de teste de desempenho disponíveis comercialmente no mercado. 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 testing-tools

Ferramentas de otimização optimization-tools

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. Este arquivo jar é incluído com uma instalação AEM no /crx-quickstart/opt/helpers pasta. 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 author-environment

Realização de testes performing-tests

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 mongodb-specific-steps

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:

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.

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 , que pode ser encontrada na variável SlingRepositoryManager no Console do OSGi. Se o número mais elevado mostrado para a fila de observação exceder o valor de queue-length , entre em contato com o Suporte do Adobe para obter ajuda com a elevação da configuração. A configuração padrão é 1.000, mas a maioria das implantações geralmente precisa aumentá-la para 20.000 ou 50.000.

Ambiente de publicação publish-environment

Realização de testes performing-tests-1

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 troubleshooting-performance-issues

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:

Depois que as áreas com problemas são identificadas, o código do aplicativo pode ser inspecionado para obter otimizações de desempenho. Qualquer recurso pronto para uso AEM que não esteja funcionando corretamente pode ser resolvido com o Suporte ao Adobe.