Tipos de teste de carga

Os tipos de teste a seguir são baseados nas questões básicas listadas anteriormente no guia.

Quanta carga minha aplicação pode comportar?

Ao configurar um teste para determinar a carga que sua aplicação pode comportar, primeiro decida se você deseja medir em solicitações por segundo (sol/s), tempo de resposta (segundos) ou usuários simultâneos. Em ambos os casos, defina qual parte da aplicação será testada.

• Navegar no site é uma carga gerada ao se visitar várias páginas ou endpoints ou solicitar dados de um único endpoint usando parâmetros diferentes para cada solicitação. Muitas vezes, é possível fazer isso usando as ferramentas básicas descritas na seção Ferramentas que podem ser usadas. Como o cache geralmente é um componente vital de uma aplicação, decida se deseja incluir uma camada de cache no teste.

• Testar fluxos de trabalho transacionais, como um checkout em que as solicitações dependem umas das outras e transportam dados entre as solicitações, exige ferramentas mais complexas. Além disso, como a medida das solicitações tem relevância limitada no contexto de uma transação em várias etapas, é mais preciso contar toda a transação, a qual deve ser emitida como um ponto de dados separado pela ferramenta. As ferramentas Apache JMeter e k6 podem ser configuradas para fornecer esses pontos de dados.

Defina o limite aceitável para a performance e a taxa de erro do sistema de destino. Para alguns sistemas, talvez você não se preocupe com os tempos de resposta desde que o evento seja processado com sucesso. Para muitas aplicações, como aquelas com interação com o usuário, defina limites para o que é aceitável para o usuário final.

Geralmente, é útil realizar os testes em etapas. A carga é aumentada a cada etapa até que o limite definido seja alcançado. Para testes repetidos, é possível aprender com os testes anteriores e melhorar seu roteiro para realizar menos etapas em um teste e ainda obter resultados válidos.

Minha aplicação pode lidar com a carga X?

Semelhante ao teste anterior, a carga nesse teste pode ser definida como solicitações por segundo ou usuários simultâneos, dependendo da natureza da aplicação que está sendo testada. Esse teste é uma versão simplificada do anterior. Aqui, uma workload específica deve ser enviada e o sistema deve ser capaz de lidar com ela. É importante escolher uma ferramenta de teste que ofereça suporte à especificação do volume de carga necessário.

O tempo para executar o teste também pode ser relevante. Alguns efeitos podem ser observados somente quando um teste é executado por um longo período de tempo. Por exemplo, a contrapressão pode causar sobrecarga nas filas. Se você desejar replicar um sistema de produção e tirar conclusões válidas, o tempo necessário para executar o teste pode afetar o tamanho do sistema de teste.

A minha aplicação pode aumentar ou reduzir a escala verticalmente?

A elasticidade é um dos principais pontos de venda da nuvem e uma importante fonte de redução de custos. Testar se sua aplicação está dimensionada adequadamente para que você possa se beneficiar da elasticidade com confiança deve fazer parte de sua jornada para a nuvem.

As principais métricas usadas para aumentar e diminuir a escala verticalmente precisam ser identificadas. Normalmente, essa é a carga da CPU dos sistemas de destino. Um endpoint que cria carga de CPU pode ser usado como destino.

Como esse teste não exige representabilidade, é possível se beneficiar da segmentação de um endpoint livre de efeitos colaterais. Você também não quer iniciar um fluxo que persista dados que possam se acumular ou que inicie processos subsequentes e induza custos desnecessários ou bloqueie a carga.

Execute o teste em um processo incremental, aumentando gradualmente a carga. Os intervalos devem ser longos o suficiente para que, em cada etapa, as métricas possam iniciar o escalonamento. Por exemplo, se você tem como regra que a carga da CPU deve ser superior a 70% em um período de 5 minutos, suas etapas devem durar mais de 5 minutos para fornecer tempo para que o evento de escalabilidade seja iniciado e executado. Você também quer ver se o escalonamento estava funcionando e corrigiu a situação de carga que você criou.

Considere iniciar seu teste de escalabilidade com mais de um servidor. Em um ambiente pequeno, aumentar a escala verticalmente pode ser lento e exigir vários ciclos para lidar com a carga. E um cluster do EC2 Auto Scaling só pode dobrar de tamanho. Isso significa que, se você começar com um servidor e iniciar o teste de carga, o primeiro evento de escalabilidade máximo só poderá ser de dois servidores. Se a carga gerada exigisse três servidores, você precisaria de dois eventos de escalabilidade, o que poderia exigir 20 minutos ou mais.

Monitore o gatilho desejado para o evento de aumento de escala verticalmente e se o dimensionamento foi apropriado para a carga real.

Se você implementou um evento de redução de escala verticalmente, também pode testá-lo de forma escalonada. Monitore se a redução na escala verticalmente é aplicável e apropriada para a carga existente e confirme se ela não inicia um aumento na escala novamente.

O comportamento da minha aplicação se degrada com o tempo com uma carga elevada constante?

Alguns efeitos podem ser observados somente quando a carga é gerada ao longo de um período prolongado de tempo. Um dos efeitos mais importantes é a contrapressão. Isso significa que, quando um sistema demora muito para processar o número de solicitações na velocidade em que elas estão chegando, a performance dos seus sistemas clientes diminui.

Isso será mais fácil de observar se o sistema lento for o alvo da carga. Em uma configuração mais complexa, é possível observar o efeito somente quando o impacto do teste de carga se propaga. Uma solução de rastreamento capaz de visualizar os tempos de resposta entre cada um dos serviços em um sistema distribuído não apenas mostra os resultados mais rapidamente, mas pode ajudar a identificar o sistema que está atuando como um gargalo. Você pode identificar o sistema de gargalo obtendo o ID de correlação de mensagens dos arquivos de log. Cada solicitação retém o mesmo ID em todos os sistemas que passam pelo teste de carga.

Usar um ID de correlação ajuda a acompanhar toda a jornada de uma única mensagem por meio de todos os diferentes componentes da sua plataforma. Com essas informações, você pode calcular o tempo de processamento de cada componente que sua mensagem está percorrendo (processing_time = departure_time - arrival_time) e identificar o mais lento. O Zipkin, o Jaeger e o AWS X-Ray são soluções proeminentes neste espaço.

Para obter os resultados mais confiáveis, escolha uma ferramenta que ofereça suporte à definição de uma taxa de solicitação constante. Isso significa que, se o sistema de destino estiver ficando mais lento, a simultaneidade da ferramenta de teste deve aumentar ou manter oreq/s constant. When the system starts to respond more slowly, it will tie up more threads and lower the request rate of your load-generating tool. A tool with a constant request rate must increase concurrency when happens, and you will see failure faster. Instead of measuring degradation by achieved req/s, você medirá pela latência e até mesmo pelas solicitações malsucedidas.

Minha aplicação está funcionando?

Normalmente, você não criaria uma carga alta, mas sim um número razoável de solicitações que verificassem a funcionalidade. Você também pode fazer isso periodicamente em relação à produção, quando os clientes não estão visitando os fluxos testados, para ter outra camada de monitoramento.

Como atalho, cenários já criados para testes de carga podem ser reutilizados na produção com uma carga menor configurada.