Dicas de teste de desempenho

Divida o script em cenários configuráveis, que devem abranger, por exemplo:

• Abrir Página Inicial

• Abrir página de categoria (PLP)

• Visualizar produtos simples (PDP) - 2 loops em cada iteração

• Visualizar produtos configuráveis - 2 loops em cada iteração

  • Por exemplo, defina as etapas acima para 60% do tráfego

• Pesquisa de produto

  • Por exemplo, defina a pesquisa no catálogo para 37% do tráfego

• Carrinho e check-out

  • Por exemplo, um usuário que conclui o carrinho e conclui a parte do script deve usar como padrão uma taxa de conversão de site de comércio eletrônico padrão do setor de cerca de 3%
  • Como o fluxo de check-out não é armazenado em cache e geralmente é uma operação que consome muitos recursos, definir um número irrealisticamente alto para o número de pessoas concluindo pedidos em comparação ao número de navegadores de site forneceria um resultado não confiável para o volume de tráfego que seu site poderia lidar.

Limpar todos os caches antes de cada execução de teste:

• O cache do Dispatcher do AEM deve ser totalmente limpo
• O Fastly e o cache interno do Adobe Commerce devem ser totalmente liberados e limpos - isso pode ser feito por meio do controle de cache no administrador do Adobe Commerce.

Incluir um período de rampa no teste Jm: não ter um período de rampa definido significa que não há aumento gradual de tráfego e não há chance para o site armazenar em cache nenhuma das páginas e componentes comumente visitados da página. Na vida real, seria incomum que todo o tráfego de pico chegasse em um site totalmente sem cache exatamente ao mesmo tempo, portanto, um período de aumento deve ser incluído nos scripts de teste Jm para permitir que o cache seja construído como aconteceria em um site real de comércio eletrônico.

Um "tempo de espera" entre cada etapa em uma iteração deve ser usado - na realidade, um usuário não
ir imediatamente para a próxima página no site durante a jornada - haveria um tempo de espera enquanto o usuário lia a página e decidia sobre sua próxima ação.

Configurar os grupos de segmentos para fazer um loop infinito, mas para um tempo definido de x (por exemplo, 60 minutos), fornecerá um teste repetível, com tempos de resposta medianos comparáveis aos de execuções de teste anteriores. Isso significa que após o período de aumento definido, haverá o número alvo de usuários virtuais em execução simultânea e isso continuará pelo tempo de loop definido.

A mediana do tempo deve ser utilizada para fornecer uma melhora/declínio no tempo médio de resposta, não na média. Se
há vários resultados de borda que demoram muito mais do que os outros resultados, isso distorceria esse resultado médio, mas no que estamos interessados no tempo de resposta do usuário final para a maioria dos usuários, que é mais adequado para a medida mediana.

Por padrão, os recursos incorporados não são coletados em jmeter (por exemplo, JS, CSS e outros recursos baixados quando um usuário real visita a página). Isso pode ser ativado, mas somente para o domínio que você está testando - as chamadas de recursos externos ainda devem ser excluídas (por exemplo, não queremos incluir tempos de resposta de serviços hospedados externamente, por exemplo, código do google analytics, já que não temos controle sobre ele).

O HTTP Cache Manager deve estar ativado, isso permite que o Jm armazene em cache elementos de página durante uma jornada como
a jornada de um usuário real ocorreria durante a navegação do site em seu próprio navegador. Durante a jornada pelo site, o navegador do usuário baixava o recurso incorporado relacionado apenas uma vez e, em seguida, eles eram armazenados em cache pelo navegador do usuário. Além disso, se o mesmo usuário retornar ao site algum tempo após sua visita original, ainda poderá ser o cache em que esses ativos são armazenados.

Os ouvintes devem ser mantidos dentro das execuções de teste de carga reais (por exemplo, "Exibir árvore de resultados" e "Relatório agregado"). A inclusão disso na execução do teste de carga real não-GUI pode afetar os resultados de desempenho relatados pelo Jmeter, pois os recursos são usados durante a execução do teste real para gerar os relatórios. Esses ouvintes foram removidos do script de teste para serem substituídos por um arquivo de resultados JTL, que pode ser processado usando a funcionalidade Report Dashboard do Jm.

Um tempo de resposta alvo para ser avaliado, de modo que a "pontuação Apdex" do relatório do painel possa ser usada como uma maneira rápida de medir o efeito das alterações no desempenho entre execuções de teste. A pontuação do Apdex é baseada em uma certa quantidade de pessoas capazes de acessar o site em um tempo tolerável . Se o tempo de resposta ultrapassar uma determinada quantia "frustrante", a pontuação será reduzida. Os horários podem ser definidos usando os parâmetros "apdex_completed_ threshold" e "apdex_tolerated_threshold".

Defina uma métrica de destino "Pedidos por hora" para apresentar aos usuários empresariais, não uma contagem de Usuários virtuais. "Usuários virtuais" pode ser um tópico complexo para entender o que, na vida real, o teste está medindo. Calculando a taxa de conversão do site, os pedidos por hora, o tempo médio que um usuário gasta no site e o tempo de processamento entre cada carregamento de página, os cálculos padrão do setor podem ser usados para apresentar diferentes cenários de teste de carga com base nos pedidos por hora a serem realizados.

Por fim, o servidor de testes Jm deve ser executado em um servidor geograficamente próximo de onde a maioria do tráfego de usuários vem e onde sua infraestrutura em nuvem está hospedada - espera-se que sejam os mesmos.