Testes de Carga Parte 3 Final - Testes

March 28, 2021

Chegou o grande momento!! Nos dois últimos posts desta série falamos sobre as etapas de preparação da infraestrutura para suportar os testes, no primeiro Testes de Carga Parte 1 - Infraestrutura foi falado das restrições impostas pela CPU, memória, rede e disco. No segundo post Testes de Carga - Parte 2 - Redes e SO foi abordado técnicas básicas de “tuning” de SO, redes, utilização de sistemas de cache e monitoração do ambiente para coleta de métricas.

Este é o último post, sobre o que vamos falar? Testes de performance, é claro!!! Finalmente!!!

Os testes de performance servem para conhecer os limites de um sistema ou aplicação, saber qual é o seu comportamento em uma situação de super utilização, observar os indicadores, conhecer seus gargalos e bugs com a finalidade de fornecer métricas que sejam capazes de ajudar a melhorar a estabilidade, confiabilidade da aplicação.

Tipos de testes

Antes de sairmos disparando testes de carga é preciso conhecer alguns tipos de testes e suas finalidades, mas existem vários tipos de testes??! “Claro meu jovem!!” Existem sim vamos conhecer alguns deles:

Performance Test: Tem como objetivo conhecer os desempenho e os tempos de resposta mínimos do website, componente ou API. Esse tipo de teste deve ser realizado com bastante frequência em componentes novos ou a cada nova versão de código. Métricas a serem observadas: speed, throughput, response time.(*)
Load Testing: Tem como objetivo avaliar o comportamento do website, aplicação ou API se estão dentro dos limites mínimos de desempenho. Esse tipo de teste deve ser realizado normalmente sempre ao fim de um sprint ou próximo da data de entrega do componente. Métricas a serem observadas: speed, stability, throughput, response time. (*)
Stress Testing: Tem como objetivo avaliar se aplicação, website ou API alcançam um determinado nível de desempenho ao ser submetido a diferentes cenários de utilização, geralmente é definido uma cargas maiores que a carga padrão. Esse tipo de teste deve ser realizado com bastante frequência, pois, ele é a forma mais próxima de simular o comportamento do usuário utilizando sua aplicação. Métricas a serem observadas: throughput response time, stability, scalability, resource usage, reliability. (*)
Endurance testing: Tem como objetivo avaliar o comportamento do website, aplicação ou API sob uma alta carga por um longo período de tempo. Esse tipo de teste busca revelar comportamentos anormais tais como vazamento de memória (memory leak), falha de renovação de objetos no cache, problemas de ampliação automática da infra entre outros. Métricas a serem observadas: speed, stability, throughput, response time. (*)

(*) Achei melhor deixar os nomes das métricas em inglês pois são os mesmos termos utilizados nos resultados das ferramentas de teste.

Jmeter como ferramenta de testes

O Apache Jmeter é uma das ferramentas mais utilizadas para fazer testes de carga, seja via console ou embutido em algum hardware. Com ela é possível testar HTTP, TCP, FTP entre muitos outros protocolos, ainda é possível montar seus planos de teste com diferentes números de usuários, definir a cadência de entrada dos usuários e ao final, é possível verificar os gráficos de resultados e as métricas.

Recomendo dar uma olhada nesse vídeo que é bem simples mas muito explicativo:

Vejamos um exemplo prático

Esse é um plano de testes do Jmeter que eu usei para fazer um trabalho pessoal. Ele faz cinco mil requisições simultânes a um conjunto de URLs. Pode ser usado como modelo para um teste, veja o código em:

https://github.com/leoml/mestrado2018/blob/master/jmeter/AWS_CT_HTTP_Request_cinco_mix.jmx

Código para chamar o teste via linha de comando

1#!/bin/bash
2
3JMETER_BIN="/home/ubuntu/apache-jmeter-4.0/bin/ApacheJMeter.jar" 
4JMETER_TEST_PLAN="/jmeter/run_teste/jmeter_5000/ct/AWS_CT_HTTP_Request_cinco_mix.jmx" 
5JMETER_CSV="/jmeter/run_teste/jmeter_5000/ct/report/HTTP-teste-table-cinco.csv"
6JMETER_HTML="/jmeter/run_teste/jmeter_5000/ct/html/"
7JMETER_OPT="-jar -Xms43g -Xmx43g -d64 -server -XX:+UseConcMarkSweepGC -XX:NewSize=128m -XX:MaxNewSize=128m"
8
9/usr/bin/java $JMETER_OPT $JMETER_BIN -f -n -t $JMETER_TEST_PLAN -l $JMETER_CSV -e -o $JMETER_HTML

Gerando os gráficos com o GNUPlot

 1reset
 2# 
 3set terminal png size 1280,720 font 'Verdana,12'
 4
 5set datafile separator "," 
 6
 7# Plot formating
 8set ylabel "Número de requisições/URL"
 9set xlabel "URL de teste"
10set title "Distribuição de requisições - Bateria BT-1 CT"
11set grid y
12set key font ",10"
13
14set style fill solid 0.5 border -1
15set border 3 front linetype black linewidth 1.0 dashtype solid
16set bmargin 8
17
18#TESTE
19set xtics rotate by 60 right
20set format y "%.2f"
21
22set key off
23
24plot 'saida_url_source_plot.txt' u 1:xtic(2) with impulses lw 20 lc "blue"

OBS: Você não é obrigado a utilizar o GNUPlot, eu utilizei por uma necessidade bastante específica.

Conclusão

Meu caros, fazer testes de carga é muito mais do que apontarmos uma ferramenta para uma uma URL e mandar 400.000 mil requisições por segundo. Fazer testes é lidar com restrições de todos os tipos: da infra, do SO, da rede, do código, do ambiente, da ferramenta de testes, etc., etc….. mas sem dúvida essa é uma disciplina obrigatória para quem deseja entrar nessa área.

Recomendo conhecer outras ferramentas além do Jmeter e metodologias de testes como: White box, Gray box e Black Box são temas que vão expandir seus conhecimentos e vai ajudar no seu dia a dia.

Referências:

Eu adoraria ouvir suas outras histórias e situações semelhantes ao que acabei de escrever neste post, você pode me encontrar em @infraascode_br ou linkedin.com/in/leonardoml/ .

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- ---
As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.