K6 x JMeter: comparativo de ferramentas para testes de carga
A Vericode preparou um comparativo entre 2 ferramentas para testes de carga: K6 e JMeter. Confira qual tem melhor usabilidade, consumo e alcance!
Por Edmilson Moraes
Resumo
O artigo abrange o uso das ferramentas para teste de carga, K6 e JMeter, bem como a comparação entre ambas em termos de usabilidade, consumo e alcance.
Objetivo
Avaliar o desempenho das aplicações JMeter e Grafana K6 para comparar aspectos específicos do desempenho das ferramentas, como o consumo de recursos e requisições, para ajudar a entender melhor as diferenças e características entre elas.
1. As ferramentas K6 x JMeter
As ferramentas K6 e JMeter são populares no mundo do teste de carga de software.
O K6 é uma ferramenta de teste de carga de código aberto lançada pela LoadImpact em 2017, que anteriormente consistia na plataforma SaaS (agora k6 Cloud). Desenvolvido em linguagem de programação GO e com scripts criados a partir da linguagem Javascript, o K6 busca ser performático, visando eficiência com menor consumo computacional possível, o que o torna atraente para desenvolvedores em busca de uma ferramenta de teste de carga mais suave.
Por outro lado, o JMeter é uma ferramenta de teste de carga de software livre, desenvolvida inteiramente em linguagem Java pela Apache Foundation. Baseado em threads, o JMeter utiliza JVMs para instanciar seus testes. Embora os scripts também possam ser estendidos usando código, a maioria dos scripts no JMeter é criada por meio da interface do usuário.
O objetivo deste material é comparar essas duas ferramentas em termos de recursos e usabilidade, fornecendo insights valiosos para os profissionais de desenvolvimento que buscam a ferramenta mais adequada (entre essas duas) para avaliar o desempenho de suas aplicações sob condições de carga simuladas.
Ambas as ferramentas, permitem desenvolvimento de plugins, facilitando acesso a oportunidades. As principais diferenças entre as ferramentas são as seguintes:
Comparison table: JMeter vs k6 (link original)
Sem levar em consideração os plugins e possíveis ferramentas extras para a utilização dos softwares de ingestão de carga, podemos dizer que:
K6 OSS
- Melhor utilização de recursos computacionais, o que o torna eficiente em termos de consumo;
- Instalação simples, proporcionando uma configuração rápida e fácil;
- Suporta plugins, mas para a maioria dos casos de uso, a funcionalidade integrada do k6 deve ser mais do que suficiente, o que simplifica o processo;
- Baseado no desempenho do GO e com scripts desenvolvidos em Javascript, permitindo uma abordagem familiar para os desenvolvedores;
- Facilidade de implementação em esteiras de testes e automação de testes, tornando-o adequado para integração contínua;
- Fácil manutenção de scripts de testes, o que facilita a adaptação e a evolução dos testes ao longo do tempo.
JMeter
- Maior facilidade (atualmente) para o desenvolvimento do robô, o que pode agilizar o processo de criação de testes;
- Maior quantidade de protocolos suportados, ampliando a capacidade de testar diversos tipos de aplicações;
- Maior facilidade para efetuar troubleshooting e debug do código, auxiliando na identificação e resolução de problemas nos testes;
- Gera gráfico com dados do teste a partir do jtl do próprio JMeter, o que facilita a análise dos resultados;
- Interface gráfica (GUI) facilita a utilização e aprendizado, tornando-o mais acessível para usuários que preferem uma abordagem visual;
- Maior comunidade de desenvolvimento devido ao tempo de lançamento, o que significa que há uma base sólida de suporte e recursos disponíveis.
Em resumo, o K6 se destaca por sua eficiência no uso de recursos, simplicidade de instalação e implementação, enquanto o JMeter oferece uma maior variedade de protocolos suportados, facilidade de desenvolvimento e uma interface gráfica amigável.
2. Detalhamento dos testes de carga
O K6 e o Jmeter foram instalados em um servidor na AWS EC2 Linux para simular as requisições efetuadas para as API’s de pagamentos Pix, que foi o alvo dos testes.
O cenário dos testes contidos nos scripts foram:
- Conectar
- Status
- Transferir
- Listar Reinvindicação
- Listar Infração
- Buscar Mensagens Múltiplas
Abaixo estão os principais pontos destacados na comparação dos resultados:
- Consumo de recursos computacionais
- Quantidade de requisições ao ambiente de teste
- Comportamento do servidor injetor
- Rampa de usuários
A rampa de execução foi a seguinte:
- 5 minutos com 1 VU
- 5 minutos com 2 VU’s
- 5 minutos com 4 VU’s
- 5 minutos com 6 VU’s
A JVM de inicialização do Jmeter estava configurada para 1GB.
O K6 não necessita de uma configuração inicial para efetuar testes, ele usa a memória do gerador de carga nativamente, o que se torna um ponto positivo.
3. Resultado dos testes de carga com as ferramentas K6 e JMeter
a) Consumo de Recursos – CPU
A análise do consumo de recursos é uma informação essencial para entender o desempenho das ferramentas K6 e JMeter durante o teste de carga. Com base no gráfico fornecido, pode-se observar o seguinte:
Consumo inicial de CPU:
- Ambos os scripts, tanto o K6 quanto o JMeter, apresentaram um alto consumo de CPU no início do teste, atingindo cerca de 20 a 30%. Esse comportamento é comum no início dos testes de carga, quando as ferramentas estão preparando a infraestrutura e iniciando as requisições aos servidores de teste.
Estabilidade do K6:
- O gráfico mostra que o K6 manteve um crescimento mais linear gerando uma estabilidade no consumo de CPU ao longo do teste, o que indica uma eficiência em gerenciar os recursos computacionais mesmo com o aumento das requisições. Essa estabilidade sugere que o K6 está otimizado para o uso eficiente da CPU e consegue lidar bem com a carga de trabalho.
Aumento do consumo de CPU do JMeter:
- Por outro lado, o JMeter mostrou um aumento significativo no consumo de CPU após os 10 minutos de teste, chegando a mais de 80%. Esse aumento pode indicar que o JMeter pode ter dificuldades em lidar com altas cargas de trabalho e pode exigir mais recursos para manter o desempenho.
b) Consumo de Recursos – Memória
A análise do consumo de memória também é fundamental para avaliar o desempenho e a eficiência das ferramentas K6 e JMeter durante o teste de carga. Com base no gráfico e nas informações fornecidas, podemos destacar os seguintes pontos:
Crescimento linear do consumo de memória do JMeter:
- O gráfico mostra que o JMeter apresentou um crescimento linear no consumo de memória, começando com cerca de 20% e atingindo aproximadamente 40% nos minutos finais do teste. Esse comportamento indica que o JMeter conseguiu gerenciar o uso de memória de forma estável e previsível ao longo do teste.
Consumo de memória do K6:
- O K6 iniciou o teste com cerca de 30% de consumo de memória e, à medida que mais usuários virtuais foram escalados, seu consumo de memória aumentou consideravelmente. Isso pode ser atribuído ao volume de requisições efetuadas pelo K6, que foi muito superior ao JMeter durante o teste.
Diferença no consumo de memória entre K6 e JMeter:
- O gráfico mostra claramente que o K6 consumiu mais memória em comparação ao JMeter. Essa diferença pode ser explicada não apenas pelo maior volume de requisições realizadas pelo K6, mas também pelo fato de o JMeter ter sua memória de inicialização parametrizada para utilizar somente 1GB. Esse limite pode ter limitado o crescimento do consumo de memória do JMeter durante o teste.
Em resumo as ferramentas de teste de carga:
- K6 apresentou um consumo de memória maior do que o JMeter durante o teste de carga, principalmente devido ao volume de requisições e à ausência de uma limitação parametrizada em relação à memória, como no caso do Jmeter, o que é um fator positivo para o K6.
c) Utilização de Rede
Com base nos dados apresentados, podemos destacar os seguintes pontos:
O gráfico mostra que o tráfego de rede subiu gradualmente ao longo do teste com o Jmeter, chegando em aproximadamente 16 Mb/s, o tráfego atingiu um pico de 20 Mb/s no final do teste.
A utilização de rede pelo K6 foi maior, como visto no gráfico abaixo, o tráfego subiu gradualmente até ficar acima dos 20 Mb/s a partir de 10 minutos de teste e permanecendo assim até o final.
c) Requisições
O Jmeter executou um pico de 3.4 mil requisições por segundo conforme demonstrado no gráfico abaixo. O volume total de requisições em 20 minutos de teste foi de aproximadamente 2.7 milhões de requisições.
O K6 executou picos acima de 8 mil requisições por segundo conforme demonstrado no gráfico. O volume total de requisições em 20 minutos de teste foi de aproximadamente 5.9 milhões de requisições, efetuando assim cerca de 119% mais requisições do que o Jmeter.
Resumo do teste efetuado, dados foram gerados automaticamente pelo K6.
Embora o K6 tenha utilizado mais memória durante o teste, isso não significa que ele foi pior, pois ele conseguiu enviar um número de requisições muito superior para a aplicação em teste.
Esse é o resultado do K6 não ter a necessidade de parametrizar a memória que ele vai utilizar durante o teste, limitando a um número exato como acontece com o Jmeter ele pode aproveitar melhor o hardware disponível do servidor injetor.
Outro fator importante para se levar em consideração é que se houvesse a necessidade de enviar mais requisições pelo Jmeter, seria necessário aumentar o parâmetro da JVM para que ele pudesse utilizar mais de 1GB de memória (que foi o valor configurado inicialmente para esse teste), e ainda assim não seria garantia de um volume maior de requisições, já que o consumo de CPU da injetora estava próximo do limite. Além de gastar mais horas, pois o teste teria que ser feito novamente.
Sendo assim, considerando somente o hardware da injetora como limite para o envio de requisições o K6 seria a ferramenta de teste de performance que conseguiu utilizar da melhor forma os recursos e enviar o maior número de requisições.
4. Conclusão – qual a melhor ferramenta para testes de carga?
A análise dos resultados deste teste mostra que o K6 se destacou em termos de consumo de recursos e quantidade de requisições em comparação ao JMeter. Além disso, o K6 apresenta um benefício significativo ao não necessitar de parametrização da memória inicial de teste. Essa característica poupa tempo de execução, evitando a necessidade de repetir os testes com diferentes configurações de memória no JMeter para alcançar o número desejado de requisições.
Essa particularidade do K6 proporcionou um melhor desempenho, mesmo com uma quantidade maior de requisições, tornando-o uma opção mais viável para cenários em que alta carga de usuários e requisições são necessárias.
Diante disso, caso haja a necessidade de realizar testes com alta carga de usuários/requisições, que demandem um servidor com mais CPU ou memória, o K6 se apresenta como uma solução mais eficiente, reduzindo a necessidade de recursos computacionais para alcançar os mesmos objetivos em comparação ao JMeter.
No entanto, é importante lembrar que cada ferramenta de teste de carga tem suas próprias características e vantagens, e a escolha ideal dependerá das necessidades específicas de cada projeto. Outros fatores, como a natureza da aplicação, a disponibilidade de recursos e a familiaridade da equipe com a ferramenta, também devem ser levados em conta antes de fazer uma escolha final.
Em suma, essa conclusão reforça que o K6 pode ser uma opção valiosa para equipes que buscam uma ferramenta de teste de carga eficiente, capaz de lidar com alto volume de requisições, enquanto otimiza o uso dos recursos disponíveis no servidor injetor.
REFERÊNCIAS:
Apache Jmeter – Documentação oficial – Disponível em: https://jmeter.apache.org/usermanual/get-started.html
K6 – Documentação oficial – Disponível em: https://k6.io/docs/
K6 vs JMeter – Disponível em: https://k6.io/blog/k6-vs-jmeter/
Nicole Van Der Hoeven – Disponível em: https://nicolevanderhoeven.com/
Rafaela Azevedo – Disponível em: https://azevedorafaela.com/2020/07/06/load-tests-jmeter-vs-k6/