loadtest.app

Lei de Amdahl: fórmula, exemplos e limites

Sun, 01 Nov 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

A lei de Amdahl (Amdahl's law) diz que a aceleração obtida ao executar um trabalho em paralelo é limitada pela parte que não pode rodar em paralelo. Se uma fração p do trabalho se divide entre n processadores, servidores ou threads, a aceleração é S = 1 / ((1 − p) + p/n), e por mais que n cresça ela nunca passa de 1 / (1 − p). Com 95% do trabalho em paralelo, o teto é de 20 vezes, mesmo em mil máquinas.

Os números abaixo são aritmética, sem nenhum teste executado por trás. Os artigos citados foram conferidos em 1º de novembro de 2026.

Fração paralela p	n = 2	n = 8	n = 64	n → ∞
0,50	1,33	1,78	1,97	2
0,90	1,82	4,71	8,77	10
0,95	1,90	5,93	15,42	20
0,99	1,98	7,48	39,26	100

O que a lei diz em termos simples?

Um trabalho não pode terminar mais rápido do que sua parte sequencial, então workers extras só encurtam o resto. Quando a parte paralela já é pequena perto da sequencial, mais workers quase não mudam o tempo total.

Pense em um trabalho de 10 segundos em que 1 segundo é sequencial (um lock, uma escrita única) e 9 segundos se dividem por igual, ou seja, p = 0,9. Oito workers o terminam em 1 + 9/8 = 2,125 segundos (4,71 vezes mais rápido); sessenta e quatro precisam de cerca de 1,14 segundo. Nada o leva abaixo de 1 segundo, então 10 é o teto.

De onde vem a lei?

Gene Amdahl apresentou o argumento em 1967, na AFIPS Spring Joint Computer Conference, em um artigo que defendia a abordagem de processador único.

Não lemos o texto completo de Validity of the single processor approach to achieving large scale computing capabilities. Mark Hill e Michael Marty o resumem em Amdahl's Law in the Multicore Era (IEEE Computer, 2008): uma fração paralelizável sem limite e sem custo de escalonamento, o resto totalmente sequencial, e a aceleração descrita sem apresentar uma equação ("without presenting an equation").

O que isso significa para testes de carga e de capacidade?

A vazão para de crescer no ritmo dos servidores, threads ou pods assim que um componente compartilhado atende parte de cada requisição uma de cada vez. Um teste de carga mostra isso como uma curva de vazão que se achata enquanto você continua adicionando capacidade.

O artigo de Neil Gunther de 2008, citado abaixo, escreve a mesma lei como N / (1 + σ(N − 1)), com σ como fração sequencial, e mede a escalabilidade como a vazão com N dividida pela vazão com 1. Em um sistema web, a parte sequencial é tudo por onde cada requisição precisa passar na sua vez: um lock ou uma linha que toda requisição atualiza, um único banco de dados primário que recebe todas as escritas, um único consumidor de fila ou uma API de terceiros com limite de taxa.

Como encontrar a parte sequencial em um teste de carga?

Rode o mesmo teste em vários níveis de carga e observe qual recurso satura enquanto a vazão se achata. O componente que está no limite quando a capacidade extra deixa de compensar é a parte sequencial, ou a fila na frente dela.

Sinais típicos: a vazão estaciona enquanto a camada de aplicação ainda tem CPU livre, as esperas crescem em um único ponto compartilhado (locks, conexões com o banco, profundidade da fila), e o tempo de resposta sobe no mesmo ritmo que os usuários, que é a lei de Little diante de um teto. Uma execução com carga constante não consegue mostrar isso, então suba a carga em degraus. A configuração Ramp Up Steps da LoadFocus adiciona usuários virtuais em lotes iguais. O painel Capacity (página em inglês) agrupa uma execução terminada por usuários virtuais ativos e, nos planos pagos, lista o p95, as requisições por segundo e a taxa de erro de cada degrau nas execuções com um só gerador de carga. Só indica um nível de capacidade quando a execução passou por pelo menos três degraus e o mais alto foi pelo menos o dobro do mais baixo. Ele não ajusta nenhum modelo de escalabilidade, então o ajuste mais abaixo fica com você.

O que é a lei de Gustafson?

É o contraponto: se o problema cresce junto com a máquina, a parte sequencial continua pequena e a aceleração cresce quase de forma linear. Amdahl fixa o trabalho; Gustafson fixa o tempo de execução.

A nota de John Gustafson de 1988, Reevaluating Amdahl's law, relatou acelerações de 1016 a 1021 em um hipercubo de 1024 processadores em Sandia, para aplicações com parte sequencial de 0,4 a 0,8%, e argumentou que os usuários aumentam o problema até preencher o tempo de que dispõem. Com s' como a parte sequencial medida na execução paralela, a aceleração escalada, uma fórmula que a nota atribui a E. Barsis, de Sandia, é N + (1 − N)s'.

Com s' = 0,05 e 64 processadores, isso dá 60,85, contra 15,42 segundo Amdahl, porque os dois valores de 5% são medidos em máquinas diferentes. Em um sistema web, Gustafson se aplica quando cada servidor adicionado trabalha com sua própria parte dos dados; Amdahl se aplica quando cada usuário a mais continua tocando a mesma linha compartilhada.

O que a Universal Scalability Law acrescenta?

Um segundo termo de coerência, o custo de manter dados compartilhados consistentes entre workers, que cresce com o número de pares de workers. Com ele, a vazão pode chegar a um máximo e depois cair à medida que você adiciona capacidade.

O artigo de Gunther A General Theory of Computational Scalability Based on Rational Functions (arXiv, 2008) formula a Universal Scalability Law (USL) assim:

C(N) = N / (1 + σ(N - 1) + κN(N - 1))
peak at N* = sqrt((1 - σ) / κ)

σ é a contenção (serialização ou filas) e κ é a coerência (cópias inconsistentes dos dados); com κ = 0 sobra a fórmula de Amdahl. Entre os exemplos de Gunther para o pior caso está a atualização de registros em banco de dados, e ele chama de "retrograde", ou seja, decrescente, a vazão além de N*. Com os valores de exemplo σ = 0,05 e κ = 0,001, o máximo fica perto de 31 workers: a vazão relativa é 9,03 com 32 e 7,82 com 64, onde o termo σ sozinho prevê 15,42.

Como ajustar a USL a uma série de testes de carga?

Meça a vazão em vários níveis de concorrência, divida cada valor pela vazão com um usuário e ajuste σ e κ por mínimos quadrados.

Rearranjada, a fórmula fica N / C − 1 = σ(N − 1) + κN(N − 1), que é linear em σ e κ. Os valores abaixo foram gerados a partir de σ = 0,05 e κ = 0,001; coloque em x suas próprias requisições por segundo de cada degrau:

import numpy as np

n = np.array([1, 2, 4, 8, 16, 32])          # virtual users
x = np.array([50, 95, 172, 284, 402, 452])  # req/s per level
c = x / x[0]                                # relative capacity
A = np.column_stack([n - 1, n * (n - 1)])
(s, k), *_ = np.linalg.lstsq(A, n / c - 1, rcond=None)
print(f"sigma={s:.3f} kappa={k:.4f}")
print(f"peak near {np.sqrt((1 - s) / k):.0f} users")

O script imprime sigma=0.050, kappa=0.0010 e um máximo perto de 31 usuários. Mude só a concorrência entre os degraus e inclua um degrau com um usuário, já que cada ponto é dividido por ele.

Onde esses modelos deixam de ser úteis?

Eles resumem uma curva de vazão em uma ou duas constantes, então não conseguem apontar o lock culpado nem acompanhar um sistema que muda sob carga. Use-os para ler uma curva medida e estendê-la um pouco: um ajuste com degraus muito abaixo do joelho diz pouco sobre o máximo.

Parâmetros constantes. Um cache que esquenta, um autoscaler ou um pool que chega ao limite mudam σ e κ no meio do teste.
Só vazão. O p95 e o p99 podem piorar antes: confira também a latência de cauda.
O gerador de carga. Se ele saturar primeiro, a curva plana é dele.
Testes fechados. Um número fixo de usuários virtuais mede um sistema fechado; usuários reais chegam no próprio ritmo.

FAQ

Você pode explicar a lei de Amdahl de forma simples? Um trabalho nunca é mais rápido do que a parte que não pode ser dividida. Se um décimo do trabalho precisa rodar em série, nenhum número de workers extras o deixa mais de dez vezes mais rápido, porque esse décimo continua levando o mesmo tempo.

O que é a lei de Gustafson? A lei de Gustafson diz que, quando o problema cresce com o número de processadores, a aceleração cresce quase de forma linear, como N + (1 − N)s', em que s' é a parte sequencial da execução paralela. John Gustafson a publicou em 1988 (atribuindo a fórmula a seu colega de Sandia E. Barsis) como contraponto à suposição de Amdahl de um problema de tamanho fixo.

Leituras relacionadas

Teoria das filas: o que é e por que a latência dispara

Sun, 01 Nov 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

A teoria das filas (em inglês, queueing theory) é a matemática da espera: a partir do ritmo em que o trabalho chega, de quanto cada tarefa demora e de quantos servidores existem, ela prevê quanto tempo as tarefas esperam e quanto a fila cresce. Para software, o resultado mais útil é que o tempo de resposta cresce devagar com carga moderada e depois de forma brusca quando um servidor se aproxima de 100% de ocupação. No modelo mais simples, um servidor ocupado 90% do tempo responde em média dez vezes mais devagar que um ocioso.

Os números abaixo são aritmética a partir de fórmulas padrão, conferidos com um script, sem nenhum teste por trás. As fontes foram conferidas em 1º de novembro de 2026.

Utilização ρ	Tempo no sistema W ÷ tempo de atendimento S	Se S = 20 ms
0,5	2	40 ms
0,7	3,3	67 ms
0,8	5	100 ms
0,9	10	200 ms
0,95	20	400 ms
0,99	100	2.000 ms

São médias para a fila M/M/1: um servidor, chegadas de Poisson e tempos de atendimento exponenciais.

O que é teoria das filas?

É o ramo da probabilidade que modela trabalho que chega, espera e é atendido. Uma fila é descrita pelas chegadas, pelos tempos de atendimento, pelo número de servidores e pela disciplina de fila, ou seja, a ordem em que as tarefas em espera são atendidas.

O livro Urban Operations Research, de Larson e Odoni, um texto aberto do MIT, cita caixas de banco, caixas de supermercado e praças de pedágio como casos clássicos. Um servidor web cabe no mesmo esquema: as requisições chegam, threads ou núcleos as atendem e o resto espera numa fila.

De onde vem a teoria das filas?

Da central telefônica, onde A. K. Erlang chegou aos primeiros resultados para a Companhia Telefônica de Copenhague.

Segundo a biografia no MacTutor, o artigo de Erlang de 1909 mostrou que chamadas feitas ao acaso seguem a distribuição de Poisson, e sua fórmula de 1917 para perdas e tempo de espera logo passou a ser usada por companhias telefônicas de muitos países. O artigo de David Kendall de 1953, Stochastic Processes Occurring in the Theory of Queues and their Analysis by the Method of the Imbedded Markov Chain, introduziu a notação usada até hoje, como registra o relato da obra dele escrito por Geoffrey Grimmett. A prova de L = λW de Little e os resultados de Kingman sobre tráfego intenso vieram em 1961.

O que significa a notação de Kendall, como M/M/1?

Ela nomeia uma fila em três partes, A/S/c: a distribuição dos intervalos entre chegadas, a dos tempos de atendimento e o número de servidores. M/M/1 significa chegadas aleatórias, tempos de atendimento exponenciais e um servidor.

M vem de memoryless, sem memória (chegadas de Poisson ou tempos exponenciais), D de determinístico e G de general, ou seja, qualquer distribuição: M/D/1 é um servidor com tempo de atendimento constante.

Como o tempo de resposta cresce com a utilização?

Numa fila M/M/1, o tempo médio no sistema é W = 1/(μ − λ), que é igual a S/(1 − ρ). Quando a utilização ρ se aproxima de 1, W cresce sem limite.

lambda = arrival rate        mu = service rate (1 / S)
rho    = lambda / mu         (utilization, must stay below 1)
W      = 1 / (mu - lambda)   = S / (1 - rho)

Larson e Odoni deduzem isso para uma central de atendimento com uma só telefonista e mostram que não há estado estacionário com ρ ≥ 1: a fila não para de crescer. A mesma fonte mostra que o tempo no sistema segue uma distribuição exponencial, então cada percentil cresce pelo mesmo fator 1/(1 − ρ), e o p95 fica em torno de três vezes a média: 600 ms na linha 0,9 acima.

Por que a latência faz um joelho antes de a CPU chegar a 100%?

Porque uma requisição espera sempre que encontra o servidor ocupado, e isso acontece com mais frequência à medida que a utilização sobe. Com as premissas do M/M/1, o tempo de resposta já dobrou a 50% de utilização.

O recurso que satura também pode ser um pool de conexões, um lock do banco de dados ou um event loop de uma só thread, e o mais carregado define a curva. Esse joelho precoce explica por que a utilização alvo fica bem abaixo de 100%. Faça a conta de trás para frente a partir do seu orçamento de latência: com S = 20 ms e uma média alvo de 100 ms, a tabela permite cerca de 80%, e um alvo de 60 ms cerca de 67%, antes que os picos levem a parte deles.

O painel Capacity da LoadFocus (página em inglês) agrupa um teste concluído pelo número de usuários virtuais ativos e informa o último nível que aguentou antes de a taxa de erros passar de 1% ou de o p95 passar do dobro do melhor nível, desde que nenhum nível mais alto tenha se recuperado. Ele precisa de um teste com um único gerador de carga que suba por pelo menos três degraus de carga, com o mais alto pelo menos o dobro do mais baixo. Pela conta acima, se o nível mais leve deixou o gargalo quase ocioso, a duplicação dispara logo acima de 50% de utilização; se o nível mais leve já o carregava a ρ0, ela dispara mais tarde, acima de (1 + ρ0)/2 no M/M/1.

Por que a variabilidade importa tanto quanto a utilização?

Filas nascem do acaso: chegadas em rajadas e tarefas lentas de vez em quando. Com tráfego intenso, o tempo de espera cresce com a variabilidade de ambas, multiplicada por um termo ρ/(1 − ρ).

O artigo de Kingman de 1961, The single server queue in heavy traffic, mostra que, quando a intensidade de tráfego de um servidor único se aproxima de 1, a fila fica longa e o tempo de espera é aproximadamente exponencial. Notas de aula da TU Eindhoven e do Technion dão uma aproximação para a média (o Technion a chama de aproximação de Allen-Cunneen; ela também é amplamente conhecida como fórmula de Kingman):

Wq ≈ rho / (1 - rho) × (ca² + cs²) / 2 × S
ca, cs = coefficient of variation (std dev / mean)
         of arrival gaps and of service times

Wq é a espera antes de o atendimento começar, e ca, cs são os coeficientes de variação. Tempos exponenciais têm c² = 1, o que devolve a espera do M/M/1 de 9S a 90% de utilização. Um tempo de atendimento constante corta a espera pela metade, para 4,5S; com cs² = 4, o que uma mistura de acertos de cache e chamadas lentas ao banco de dados pode produzir, ela sobe para 22,5S. Tráfego sintético regular varia menos que o de produção, então um teste costuma mostrar menos fila do que os picos reais.

Como mais servidores (M/M/c) ajudam?

Vários servidores que compartilham uma fila absorvem rajadas aleatórias muito melhor que os mesmos servidores com uma fila cada, então cada servidor pode trabalhar mais ocupado com a mesma espera.

Pelas fórmulas M/M/m de Larson e Odoni, com cada servidor 90% ocupado, W é 10S com um servidor, 5,3S com dois compartilhando a fila e 3,0S com quatro. Quatro instâncias atrás de um balanceador que escolhe uma livre se comportam como o último caso; quatro que recebem cada uma um quarto aleatório do tráfego, como filas M/M/1 separadas a 10S.

Onde entra a lei de Little?

A lei de Little, L = λW, liga o número médio de requisições num sistema à taxa de chegada e ao tempo que elas passam lá dentro, quaisquer que sejam as distribuições. A teoria das filas dá W, e a lei de Little o transforma em L.

Na linha 0,9, 45 requisições por segundo com W = 200 ms significam em média 9 requisições dentro do sistema. Nosso artigo sobre a lei de Little usa a mesma lei para dimensionar e conferir testes de carga.

Onde esses modelos deixam de valer em teste de carga?

Eles supõem um fluxo aberto de chegadas independentes e um estado estacionário. Um teste com número fixo de usuários virtuais é um sistema fechado, em que as chegadas desaceleram quando as respostas desaceleram.

Testes fechados. Com N usuários virtuais há no máximo N requisições no sistema, então a taxa de requisições cai onde uma fila aberta cresceria, e o tempo de pensamento a reduz ainda mais. Nosso artigo sobre o modelo de carga aberto vs fechado explica por que isso esconde a saturação.
A LoadFocus roda scripts k6, mas os cenários arrival-rate rodam lá com um número fixo de usuários, como avisa o validador de scripts dela. Leia esses testes como fechados: depois do joelho, espere uma taxa de requisições estável e tempos de resposta subindo.
Estado estacionário. Aquecimento, caches e autoscaling mudam a taxa de atendimento durante o teste, então compare níveis mantidos por tempo suficiente para se estabilizar.

FAQ

Escreve-se queueing theory ou queuing theory? As duas grafias em inglês estão corretas e nomeiam o mesmo campo. O artigo de Kingman de 1961 escreve "queueing time", enquanto a prova de Little do mesmo ano traz "Queuing Formula" no título.

A teoria das filas exige chegadas de Poisson? Só para os resultados exatos do M/M/1. Aproximações G/G/1 como a fórmula de Kingman usam a média e a variabilidade dos intervalos entre chegadas e dos tempos de atendimento, e a lei de Little não supõe nada sobre as distribuições.

Leituras relacionadas

SLO vs SLA: a diferença, os SLIs e o orçamento de erros

Sun, 01 Nov 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Um SLA (acordo de nível de serviço) é um contrato com um cliente que diz o que acontece quando um serviço não atinge um nível prometido, em geral um crédito de serviço. Um SLO (objetivo de nível de serviço) é a meta interna com que uma equipe opera o serviço; o livro de SRE recomenda defini-la mais rígida que o SLA, para que os problemas sejam resolvidos antes de o contrato ser violado. Um SLI (indicador de nível de serviço) é a medida em que os dois são escritos, como a parcela de requisições bem-sucedidas.

	SLI	SLO	SLA
O que é	Uma medida	Uma meta para um SLI	Um contrato baseado em SLOs
Quem define	Engenharia	Product owner e engenharia	Times de negócio e jurídico
Se não for cumprido	Nada por si só	Orçamento de erros gasto	Créditos de serviço ou multas
Exemplo	Chamadas de checkout com sucesso	99,95% em quatro semanas	99,9% ao mês, ou um crédito

Os exemplos são ilustrativos; as fontes são o livro e o workbook de SRE do Google e o SLA de computação da AWS, conferidos em 1º de novembro de 2026.

O que significam SLI, SLO e SLA?

Service level indicator, service level objective e service level agreement: indicador, objetivo e acordo de nível de serviço. O indicador é o que você mede, o objetivo é o valor que você busca e o acordo é o que você promete a outra pessoa, com consequências.

O capítulo "Service Level Objectives" do livro de SRE define um SLA como "um contrato explícito ou implícito com seus usuários que inclui consequências por cumprir (ou não cumprir) os SLOs que ele contém". O teste do capítulo é uma única pergunta: o que acontece se os SLOs não forem cumpridos? Se não há consequência explícita, você quase certamente está diante de um SLO.

O capítulo acrescenta que a maioria das pessoas quer dizer SLO quando diz SLA, e que uma violação real de SLA pode acabar num processo por quebra de contrato. Então, quando uma reunião virar uma discussão de SLA vs SLO, pergunte primeiro se há uma consequência, em geral dinheiro, prevista em contrato.

O livro de SRE aconselha manter uma margem de segurança: "um SLO interno mais rígido que o SLO anunciado aos usuários dá espaço para responder a problemas crônicos antes que fiquem visíveis externamente". O capítulo "Embracing Risk" aplica a mesma ideia a um contrato: uma meta externa de 99,9% apoiada por uma interna mais exigente.

O que é um orçamento de erros?

É 100% menos o SLO: a parcela das requisições ou do tempo que pode falhar dentro da janela. Enquanto sobra orçamento, a equipe continua entregando; quando ele acaba, o trabalho de confiabilidade vem primeiro.

O capítulo "Implementing SLOs" do workbook de SRE faz a conta: com um SLO de 99,9%, um serviço que recebe 3 milhões de requisições em quatro semanas pode falhar 3.000 delas, então uma queda com 1.500 erros gasta metade do orçamento. O capítulo "Embracing Risk" do livro explica o propósito: a gestão de produto define o SLO, o monitoramento mede a disponibilidade real e a diferença é a margem de falta de confiabilidade que resta para o trimestre. Quando esse orçamento acaba, os deploys param ou desaceleram.

Quanto tempo de indisponibilidade 99,9% permite?

Cerca de 43 minutos numa janela de 30 dias. Cada nove a mais divide a margem por dez, então 99,99% deixa pouco mais de 4 minutos.

SLO	Orçamento de erros	Indisponibilidade em 30 dias	Falhas por milhão
99%	1%	7 h 12 min	10.000
99,5%	0,5%	3 h 36 min	5.000
99,9%	0,1%	43 min 12 s	1.000
99,95%	0,05%	21 min 36 s	500
99,99%	0,01%	4 min 19 s	100

Multiplique os 43.200 minutos de uma janela de 30 dias pelo orçamento de erros. Lembre do aviso do workbook: cada nove adicional custa mais, enquanto o valor dele para os usuários tende a zero.

Como é um SLA de verdade?

Ele traz uma porcentagem medida, um período de cobrança, uma tabela de créditos e o que não conta. O SLA de computação da AWS é um exemplo público e curto.

O Amazon Compute Service Level Agreement (atualizado em 25 de maio de 2022; conferido em 1º de novembro de 2026) se compromete com uma Monthly Uptime Percentage de pelo menos 99,99% por região para instâncias EC2 distribuídas em duas ou mais Availability Zones, e 99,5% para uma instância isolada. A disponibilidade é 100% menos a parcela dos minutos em que o EC2 ficou indisponível. Pelo Region-Level SLA, abaixo de 99,99% o crédito é de 10% da fatura mensal de EC2 na região, abaixo de 99,0% é de 30% e abaixo de 95,0% é de 100%; para uma instância isolada, a faixa de 10% começa abaixo de 99,5%. Os créditos são aplicados a pagamentos futuros, precisam ser solicitados pelo suporte da AWS e são o remédio "único e exclusivo", salvo disposição em contrário no contrato do cliente.

Comparada com a tabela acima, a faixa de 10% do Region-Level SLA vai de cerca de 4 minutos a 7 horas de indisponibilidade num mês de 30 dias. Um SLA limita o que o fornecedor deve; evitar que as quedas prejudiquem seus usuários é tarefa dos seus próprios objetivos.

Como escolher SLIs de latência e disponibilidade?

Meça a latência como percentil e a disponibilidade como eventos bons divididos por todos os eventos, o mais perto possível do usuário. Médias e números só do servidor escondem as requisições de que as pessoas reclamam.

Latência. O livro de SRE prefere percentis à média, porque uma média pode ficar estável enquanto as requisições mais lentas ficam bem mais lentas. O workbook escreve SLIs de latência como uma razão, por exemplo as chamadas concluídas em menos de 100 ms divididas por todas as chamadas. Então "99% das chamadas de checkout em menos de 400 ms" é o mesmo que "p99 do checkout abaixo de 400 ms" na janela, o que vai direto para um teste. Nosso artigo sobre latência de cauda explica por que o p99 importa assim que uma página chama vários serviços.

Disponibilidade. A disponibilidade por tempo conta os minutos no ar, como faz o SLA da AWS. A disponibilidade por requisições conta as requisições bem-sucedidas: "Embracing Risk" descreve um serviço com 2,5 milhões de requisições por dia e uma meta diária de 99,99%, que pode devolver 250 erros e ainda cumprir a meta.

Onde os SLOs dão errado?

Quase sempre por excesso de objetivos, metas de 100% e indicadores medidos onde os usuários não estão. Cada um deixa um número que ninguém usa para agir, ou um que parece bom enquanto os usuários sofrem.

SLOs demais. O livro de SRE aconselha ter o mínimo possível: se citar um SLO nunca ajuda a ganhar uma discussão sobre prioridades, provavelmente ele não vale a pena.
Metas de 100%. O workbook diz que 100% é a meta errada: componentes falham, mudanças são a principal fonte de quedas e um SLO de 100% só deixa tempo para reagir.
Medir só no servidor. Métricas do servidor deixam passar problemas que os usuários sentem, como um script lento na página. O workbook sugere medir no balanceador de carga ou no cliente.

O que o teste de carga tem a ver com SLOs?

Um SLO dá ao teste de carga seus critérios de aprovação, e um teste no pico esperado mostra se o SLO de latência se sustenta antes de esse tráfego chegar. O monitoramento em produção só conta depois.

O livro de SRE observa que mais requisições por segundo (QPS) costumam trazer latências maiores e que é comum os serviços terem um penhasco de desempenho a partir de certo limiar de carga. Um teste de carga pode encontrar esse penhasco se rodar no pico esperado, com um mix realista de requisições, e medir o mesmo SLI que o SLO usa. Defina cada limite de aprovação do teste um pouco mais rígido que o SLO, como descreve nosso guia de critérios de aprovação de um teste de carga. Uma execução dura minutos, então não consegue medir a disponibilidade mensal.

A LoadFocus, que publica este site, avalia testes de carga com limites de aprovação salvos no teste: Max P95 e Max P99 do tempo de resposta, uma taxa de erros máxima e uma vazão mínima, para testes cloud, JMeter e k6. O monitoramento de APIs dela tem relatórios de SLA e SLO que definem uma meta de SLO por monitor e mostram a disponibilidade, o orçamento de erros consumido e um status OK ou Breached.

FAQ

O que significa SLO? Service level objective, ou objetivo de nível de serviço: um valor-alvo para um nível de serviço medido, como 99,9% das requisições bem-sucedidas em quatro semanas. Ele é definido internamente, por produto e engenharia, e, sozinho, não traz nenhuma multa contratual.

Dá para ter um SLO sem um SLA? Sim. O livro de SRE cita a busca do Google como um serviço importante sem SLA público que, mesmo assim, é gerido com SLIs e SLOs.

Um SLO deveria ser de 100% em algum caso? Não. Um objetivo de 100% não deixa orçamento de erros, então qualquer falha o viola e nenhuma mudança fica segura para entregar.

Leituras relacionadas

TPC-H: o que o benchmark mede e como executá-lo

Sun, 01 Nov 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

O TPC-H é o benchmark de suporte à decisão do Transaction Processing Performance Council (TPC): 22 consultas de negócio e duas funções de atualização rodam sobre oito tabelas que o programa dbgen do TPC preenche com um fator de escala escolhido, em que o fator 1 equivale a cerca de 1 GB. A métrica dele, QphH@Size, combina um teste de potência com um único fluxo e um teste de vazão com vários fluxos, e os resultados oficiais acrescentam um preço por kQphH@Size. Só resultados auditados e publicados no tpc.org são oficiais; qualquer número no estilo TPC-H publicado fora do tpc.org conta como carga derivada pelas regras de uso justo do TPC e não pode ser comparado com resultados oficiais.

Não executamos o benchmark para este guia. Os fatos vêm do tpc.org, da especificação na revisão 3.0.1, que o tpc.org indica como atual, e da documentação de cada ferramenta, tudo conferido em 1º de novembro de 2026. As avaliações são nossas.

	TPC-H	TPC-C	TPC-DS
Carga	Suporte à decisão: consultas ad hoc mais atualizações de dados	OLTP: os pedidos de um atacadista	Suporte à decisão: consultas mais manutenção de dados
Escopo	8 tabelas, 22 consultas, 2 funções de atualização	9 tipos de tabela, 5 tipos de transação	Esquema floco de neve, 7 tabelas fato, 99 consultas
Métrica principal	QphH@Size e $/kQphH@Size	tpmC	QphDS@SF e $/kQphDS@SF
Versão atual	3.0.1	5.11.0	4.0.0

O que o TPC-H mede?

A rapidez com que um sistema responde a consultas analíticas complexas sobre um grande volume de dados enquanto vendas novas chegam e antigas são apagadas. Uma única especificação define o esquema, as consultas, os dados e as regras.

A página do TPC-H descreve um conjunto de consultas ad hoc orientadas a negócio com modificações de dados simultâneas (conferido em 1º de novembro de 2026). A especificação define oito tabelas: PART, PARTSUPP, LINEITEM, ORDERS, CUSTOMER, SUPPLIER, NATION e REGION. Todas, menos as duas últimas, crescem com o fator de escala; a LINEITEM, a maior, tem cerca de 6.000.000 de linhas por unidade. A função de atualização RF1 insere linhas novas em ORDERS e LINEITEM, e a RF2 remove vendas antigas (conferido em 1º de novembro de 2026).

Como a pontuação do TPC-H é calculada?

Uma execução é um teste de potência seguido de um teste de vazão, e o QphH@Size é a média geométrica dos dois resultados. A métrica de preço é o preço total do sistema dividido pelo QphH@Size, vezes 1.000.

No teste de potência, um fluxo de atualização roda a RF1, uma única sessão de consultas roda as 22 consultas uma vez, depois o fluxo de atualização roda a RF2. O Power@Size é 3.600 vezes o fator de escala, dividido pela média geométrica desses 24 tempos. No teste de vazão, vários fluxos de consultas rodam ao lado de um fluxo de atualização: no mínimo 2 com fator 1, chegando a 11 com fator 100.000. O Throughput@Size é o número de consultas por hora somando todos os fluxos, vezes o fator de escala. Um teste completo tem duas execuções, e o patrocinador informa a que tem o QphH mais baixo (tudo segundo a especificação, conferido em 1º de novembro de 2026).

A média geométrica dá o mesmo peso a cada consulta, então reduzir pela metade o tempo de uma única consulta aumenta o Power em só cerca de 3%. Um resultado oficial usa um fator de escala de uma lista fixa: 1, 10, 30, 100 e assim por diante até 100.000.

Quem publica resultados do TPC-H, e quais contam?

Os fornecedores que patrocinam um teste publicam resultados auditados no tpc.org, e só esses são oficiais. Qualquer outra execução é uma carga derivada, com regras próprias.

A especificação exige uma auditoria independente feita por um auditor certificado pelo TPC. A referência rápida de uso justo (fair use) do TPC só permite o nome do TPC ao lado de resultados oficiais publicados. Todo o resto precisa do prefixo "Derived from", não pode usar a métrica do TPC, deve trazer um aviso de que não é comparável aos resultados publicados, deveria descrever o ambiente e os desvios e não pode ser comparado com resultados oficiais (conferido em 1º de novembro de 2026).

Como você roda o TPC-H por conta própria?

Gere os dados e o texto das consultas, carregue as tabelas e depois rode o teste de potência seguido do teste de vazão. Você pode usar as ferramentas do TPC, um kit feito para um banco específico ou um motor com gerador embutido.

A página de especificações atuais do TPC oferece um pacote de ferramentas gratuito: você se cadastra, aceita uma licença e recebe o link por e-mail. Segundo a especificação, o DBGen deve produzir os dados e o QGen o texto das consultas (conferido em 1º de novembro de 2026).

Para PostgreSQL, a página TPC-H da wiki não traz um procedimento passo a passo e aponta para o DBT-3, um kit completo que a página do DBT-3 na wiki chama de implementação da especificação compatível com o uso justo. O HammerDB traz o TPROC-H, que a documentação dele descreve como uma carga de código aberto derivada do TPC-H e não comparável aos resultados publicados. Ele roda no PostgreSQL, MySQL, Oracle e outros motores, e a documentação recomenda comparar a média geométrica dos tempos de consulta em vez de calcular um QphH (tudo conferido em 1º de novembro de 2026).

O DuckDB tem uma extensão tpch que, segundo a documentação, implementa o gerador de dados e as consultas. Estas linhas geram o fator 1, rodam a consulta 4 e listam as 22 consultas:

CALL dbgen(sf = 1);
PRAGMA tpch(4);
FROM tpch_queries();

A mesma página avisa que os dados diferem um pouco da especificação, que cada consulta roda com parâmetros fixos e que o dbgen não apaga as tabelas existentes. Para dados totalmente conformes, ela aponta para o tpchgen-cli (conferido em 1º de novembro de 2026).

Como ler resultados do TPC-H com honestidade?

Compare resultados só com o mesmo fator de escala e a mesma versão do benchmark, e leia cada métrica com o sufixo de tamanho. Um gráfico de tempos de consultas isoladas não mostra nem o teste de potência nem o teste de vazão.

A página de resultados agrupa os resultados por tamanho do banco e traz três notas: resultados das versões 2 e 3 não são comparáveis, preço/desempenho em moedas diferentes não deve ser comparado, e comparações entre tamanhos de banco são enganosas (conferido em 1º de novembro de 2026). A especificação acrescenta que resultados com números de fluxos diferentes são comparáveis com o mesmo tamanho de banco.

Numa execução informal, procure o que as regras de uso justo pedem: hardware e memória, mudanças no esquema ou no texto das consultas e se as funções de atualização rodaram. Um post que mede as 22 consultas uma vez, com cache quente e sem fluxo de atualização, só se aproxima da parte de consultas de um teste de potência, embora uma execução assim ainda ajude a acompanhar as suas próprias regressões. Sobre taxa de consultas e tempo de resposta, veja vazão vs latência.

Quando usar outra coisa em vez do TPC-H?

Quando a carga é transacional, quando você quer um benchmark analítico mais novo ou quando a pergunta é o que os usuários sentem. O benchmark modela uma carga analítica, sem transações curtas nem camada de aplicação.

Escolha o TPC-DS para um teste de suporte à decisão mais amplo: a especificação na versão 4.0.0 usa um esquema floco de neve com sete tabelas fato e 99 consultas, e a página de apresentação diz que os resultados da versão 4 não são comparáveis com versões anteriores. Escolha o TPC-C, ou o TPROC-C do HammerDB, para OLTP de entrada de pedidos: a página do TPC-C descreve cinco tipos de transação medidos em tpmC (tudo conferido em 1º de novembro de 2026). Para uma checagem rápida de um único banco, o pgbench cobre o PostgreSQL e o sysbench cobre o MySQL.

A LoadFocus, que publica este site, não roda o TPC-H; os testes dela são voltados a endpoints web e de API. A LoadFocus roda planos de teste JMeter e scripts k6 a partir de 25 regiões de nuvem, sem driver JDBC e sem módulo SQL, então não consegue se conectar ao banco de dados. Para esse trabalho, escolha uma ferramenta de benchmark de banco de dados como a extensão do DuckDB, o DBT-3 ou o HammerDB em vez da LoadFocus, e use a LoadFocus para a camada web ou de API que fica na frente do banco, começando pelo template para os endpoints por trás das consultas pesadas.

FAQ

Qual é a diferença entre TPC-H e TPC-DS? Os dois são benchmarks de suporte à decisão do TPC. O TPC-H usa 8 tabelas e 22 consultas e informa o QphH@Size, enquanto o TPC-DS usa um esquema floco de neve com sete tabelas fato e 99 consultas e informa o QphDS@SF.

O que significa QphH@Size no TPC-H? É a métrica composta de consultas por hora: a média geométrica dos resultados do teste de potência e do teste de vazão em um tamanho de banco. O sufixo indica esse tamanho, por exemplo QphH@1000GB, e resultados em tamanhos diferentes não devem ser comparados.

A LoadFocus consegue rodar o TPC-H? Não. A LoadFocus roda planos de teste JMeter e scripts k6 voltados a endpoints web e de API e não tem conexão SQL, então use uma ferramenta de benchmark de banco de dados para o TPC-H e a LoadFocus para a camada de aplicação na frente do banco.

Leituras relacionadas

pgbench: benchmark e teste de carga do PostgreSQL

Sat, 31 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

O pgbench é o programa de benchmark que vem com o PostgreSQL: ele roda a mesma transação SQL sem parar em várias sessões simultâneas de banco de dados e informa as transações por segundo e a latência. Você cria as tabelas de teste com pgbench -i -s 50 mydb e depois roda algo como pgbench -c 10 -j 2 -T 300 mydb para dez clientes em duas threads durante cinco minutos. Ele mede só o banco de dados, então não diz nada sobre o que os usuários sentem através da aplicação que fica na frente.

Não rodamos o pgbench para este guia. Os fatos vêm da página do pgbench na documentação do PostgreSQL 18, a versão que o postgresql.org marca como atual, conferidos em 31 de outubro de 2026, e as avaliações são nossas.

Opção	O que faz
`-i` / `-s`	Criar as tabelas de teste / fator de escala (100.000 contas por unidade)
`-c`	Clientes, ou seja, sessões simultâneas de banco de dados (padrão 1)
`-j`	Threads de trabalho dentro do pgbench (padrão 1)
`-T` / `-t`	Duração em segundos, ou transações por cliente (padrão 10)
`-b` / `-f`	Um script embutido ou um arquivo seu, com um `@peso` opcional
`-P`	Relatório de progresso a cada N segundos
`-R` / `-L`	Taxa alvo em tps / limite de latência em ms
`-r` / `-l`	Latências por comando / uma linha de log por transação

O que o pgbench mede?

Ele roda um script de transação repetidas vezes num número fixo de sessões de banco de dados e informa a taxa média de transações e a latência. O script padrão se baseia livremente no benchmark bancário TPC-B.

Segundo a documentação do pgbench, o cenário padrão é inspirado no TPC-B sem ser de fato TPC-B, daí o nome: a saída o chama de TPC-B (sort of) (conferido em 31 de outubro de 2026).

Como preparar um banco de dados para o pgbench?

Rode pgbench -i contra um banco de dados existente, com -s para o fator de escala. O comando cria quatro tabelas e apaga qualquer tabela existente com o mesmo nome, então dê a ele um banco só seu.

Com fator 1, pgbench_branches tem uma linha, pgbench_tellers 10, pgbench_accounts 100.000 e pgbench_history nenhuma, e -s multiplica essas linhas: -s 100 gera 10.000.000 de linhas em pgbench_accounts. A documentação não informa o tamanho em disco, então meça depois de inicializar (conferido em 31 de outubro de 2026).

Quais scripts embutidos o pgbench traz?

Três: tpcb-like (o padrão), simple-update e select-only. Você escolhe um com -b ou com os atalhos -N e -S.

O padrão envia sete comandos por transação: BEGIN, um update e um select numa conta aleatória, updates em pgbench_tellers e pgbench_branches, um insert em pgbench_history e END. O simple-update tira os dois updates das tabelas pequenas, o que evita contenção nelas e, segundo a documentação, afasta o teste ainda mais do TPC-B. O select-only envia só o select.

Como escrever um script próprio para o pgbench?

Coloque seu SQL num arquivo, defina variáveis com \set e as funções aleatórias, e passe o arquivo com -f. Cada execução do arquivo conta como uma transação.

\set aid random(1, 100000 * :scale)
\set delta random(-5000, 5000)
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta
  WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
END;

Um peso depois de @ define com que frequência cada script é escolhido: -f update.sql@9 -b select-only@1 escolhe o arquivo em cerca de nove de cada dez vezes. A documentação também lista random_exponential, random_gaussian e random_zipfian, com as quais dá para concentrar o acesso em poucas linhas. O \sleep adiciona uma pausa, a versão de banco de dados do tempo de pensamento. Se você roda só os seus próprios arquivos, passe o fator de escala do banco com -s; senão :scale fica em 1 e o script acima só mexe nas primeiras 100.000 contas. Com tabelas próprias, deixe de fora o -i e adicione -n para o pgbench não rodar VACUUM nas tabelas padrão (conferido em 31 de outubro de 2026).

Quais opções transformam o pgbench num teste de carga?

A concorrência vem de -c e -j, a duração de -T e o formato da carga de -R. Sem -R, cada cliente inicia a próxima transação assim que a anterior termina.

Esse padrão é um modelo de carga fechado, explicado no nosso artigo sobre o modelo de carga aberto vs fechado. Com -R, o pgbench inicia as transações num cronograma com distribuição de Poisson que avança a partir do início do cliente, não importa o que aconteceu com as transações anteriores. A latência informada passa a contar a partir de cada início previsto e inclui o atraso em relação ao cronograma (schedule lag), cuja média e máximo aparecem à parte: é a correção que o nosso artigo sobre coordinated omission descreve. O número de clientes fica fixo, então se o atraso não para de crescer, o sistema não aguenta essa taxa com os clientes e threads escolhidos: reduza o -R ou adicione clientes.

O --latency-limit (-L) conta como atrasadas as transações que passam de um limite em milissegundos; com -R, o pgbench também pula as transações que já estão atrasadas demais em relação ao cronograma e as informa como puladas. O -M prepared usa prepared statements, que segundo a documentação rodam mais rápido que os outros modos (conferido em 31 de outubro de 2026).

Como ler a saída do pgbench?

O resumo mostra as configurações, as transações processadas e com falha, a latência média, o tempo de conexão inicial e os tps. O formato abaixo vem da documentação, sem os números:

transaction type: <builtin: TPC-B (sort of)>
number of transactions actually processed: ...
number of failed transactions: ... (...%)
latency average = ... ms
latency stddev = ... ms   (only with -P, -R or -L)
initial connection time = ... ms
tps = ... (without initial connection time)

As transações com falha são erros de serialização ou deadlocks, que o --max-tries pode repetir. Os outros erros de SQL abortam o cliente afetado e deixam o código de saída em 2. O resumo não traz percentis: para a latência de cauda, registre cada transação com -l, que grava a duração dela em microssegundos, e calcule você mesmo o p95 ou o p99.

Sem -P, -R ou -L, a latência média do resumo não é medida: o pgbench a deduz a partir da duração e do número de clientes, ou seja, a lei de Little aplicada ao contrário, com as falhas incluídas. Adicione -P quando a latência importar.

Como obter números confiáveis do pgbench?

Faça cada execução durar vários minutos, repita, mantenha o fator de escala pelo menos igual ao número de clientes e fique de olho no VACUUM. Se o próprio pgbench virar o gargalo, leve-o para outra máquina.

A primeira orientação da seção "Good Practices" da documentação avisa para não acreditar em nenhum teste que dure só alguns segundos, e acrescenta que números reproduzíveis podem levar horas (conferido em 31 de outubro de 2026). Com o script padrão, um fator de escala menor que o número de clientes mede principalmente a contenção dos updates, porque pgbench_branches tem só -s linhas e cada transação altera uma delas. Linhas mortas e o autovacuum mudam os resultados de uma execução para outra. Com muitas sessões, o pgbench pode saturar a própria máquina: rode-o numa máquina separada com baixa latência de rede, ou distribua várias instâncias por várias máquinas.

Quando o pgbench não é a ferramenta certa?

Quando a pergunta é sobre os usuários, sobre outro banco de dados ou sobre um mix OLTP padrão. O pgbench mede o PostgreSQL sozinho, sem o seu pool de conexões, ORM, cache ou camada HTTP.

Para ver o que os usuários sentem, coloque carga na camada HTTP ou de API que fica na frente. A LoadFocus, que publica este site, não roda o pgbench e não consegue se conectar diretamente ao PostgreSQL: ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem contra endpoints web e de API, e o template para os endpoints por trás das consultas pesadas é um ponto de partida.

Escolha o sysbench para MySQL: o repositório dele descreve uma ferramenta de benchmark programável e multithread com testes de banco de dados no estilo OLTP. Escolha o HammerDB para um mix no estilo TPC-C: a documentação descreve o TPROC-C, uma carga derivada do TPC-C, que ele roda no PostgreSQL e em outros bancos. Escolha o JMeter com o sampler JDBC Request para misturar SQL e HTTP num mesmo plano de teste nas suas próprias máquinas (tudo conferido em 31 de outubro de 2026).

FAQ

Para que serve a opção -s do pgbench? Ela define o fator de escala na inicialização. Cada unidade adiciona 100.000 linhas a pgbench_accounts, então -s 100 cria 10.000.000 de linhas. Com o script padrão, mantenha o valor pelo menos igual ao seu número de clientes.

Qual é a diferença entre -c e -j no pgbench? A opção -c define o número de clientes simulados, cada um uma sessão simultânea de banco de dados. A opção -j define quantas threads de trabalho do pgbench dividem esses clientes.

A LoadFocus consegue rodar o pgbench? Não. A LoadFocus roda planos de teste JMeter e scripts k6 e não tem conexão direta com o PostgreSQL, então com ela você coloca carga na camada web ou de API que fica na frente do banco de dados.

Leituras relacionadas

redis-benchmark: como usar e ler os resultados

Sat, 31 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

O redis-benchmark é o utilitário de benchmark que vem com o Redis: ele abre um número de conexões de cliente (50 por padrão), envia um número fixo de comandos (100.000 por padrão) e informa, para cada teste, as requisições por segundo e a latência. Rode redis-benchmark -q -n 100000 contra um servidor em execução, restrinja com -t aos comandos que interessam e leia o resultado como a velocidade de uma única instância do Redis sob comandos sintéticos. Sua aplicação acrescenta o próprio caminho de rede, a biblioteca cliente e o seu mix de comandos, então espere números diferentes.

Rodamos o teste em 31 de outubro de 2026 num notebook Apple M1 Max, com servidor e cliente Redis 7.2.6 na mesma máquina via loopback e sem persistência. Cada linha é uma execução de 100.000 requisições, com as requisições por segundo arredondadas para o milhar; o p50 aparece como a ferramenta imprimiu.

Execução	O que muda	Requisições por segundo	p50 (ms)
`-t set,get`	Nada: 50 clientes, valores de 3 bytes	SET 113.000, GET 118.000	0,367; 0,351
`-t set,get -P 16`	16 comandos por ida e volta	SET 1.010.000, GET 1.190.000	0,711; 0,583
`-t set,get -c 200`	200 clientes	SET 117.000, GET 123.000	1,135; 1,071
`-t set -d 1024`	Valores de 1.024 bytes	SET 114.000	0,367
`-t set -r 100000`	Chaves aleatórias entre 100.000	SET 116.000	0,359
`script load "..."`	Um comando próprio	106.000	0,415

Como rodar o redis-benchmark?

Aponte a ferramenta para um servidor em execução com -h e -p; sem opções, ela roda a bateria de testes padrão contra 127.0.0.1:6379. Use -t para escolher os testes e -q para ver uma linha por teste.

redis-benchmark -h 10.0.0.12 -p 6379 -c 50 -n 100000 \
  -t set,get -q

A página oficial de benchmark do Redis e a saída de --help da versão 7.2.6 listam, entre outras, estas opções (conferido em 31 de outubro de 2026):

-c conexões em paralelo (padrão 50) e -n total de requisições (padrão 100.000).
-d tamanho dos valores de SET e GET em bytes (padrão 3).
-P comandos por pipeline (padrão 1, sem pipelining).
-t uma lista de testes separados por vírgula; -q saída resumida; --csv saída em CSV.
-r chaves aleatórias num espaço de chaves desse tamanho. Sem essa opção, todos os comandos usam a mesma chave.
-k 1 mantém as conexões abertas (padrão) e -k 0 reconecta.
--threads liga o modo multithread e --cluster o modo cluster, em que -c precisa ser pelo menos igual ao número de nós.

Como ler a saída do redis-benchmark?

Com -q você recebe uma linha por teste: requisições por segundo e latência mediana. Sem -q, cada teste imprime suas configurações, uma distribuição da latência por percentil e um resumo com média, mínimo, p50, p95, p99 e máximo.

O cabeçalho também mostra as configurações save e appendonly do servidor, que dizem se a persistência fez parte do teste. Nossa execução completa de GET deu 119.617 requisições por segundo, média de 0,352 ms, p95 de 0,559 ms, p99 de 0,623 ms e máximo de 0,759 ms. Uma requisição que chama o Redis muitas vezes tem mais chance de pegar uma chamada lenta, então olhe também o p99; nosso artigo sobre latência de cauda explica por quê.

--csv imprime o resumo como uma linha por teste. Repita as execuções antes de confiar numa diferença pequena: duas execuções do mesmo teste SET nos deram cerca de 113.000 e 125.000 requisições por segundo.

Por que o pipelining muda tanto os números?

Sem -P, cada cliente espera uma resposta antes de enviar o próximo comando, e cada comando paga uma ida e volta completa. Com -P 16, cada cliente envia 16 de uma vez, e na nossa execução o SET subiu de cerca de 113.000 para 1.010.000 requisições por segundo e o GET de 118.000 para 1.190.000.

A página oficial considera o pipelining realista, já que muitas aplicações Redis o usam, e recomenda um tamanho de pipeline próximo da média que sua aplicação consegue usar de fato. Nossa latência mediana subiu ao mesmo tempo, para 0,711 e 0,583 ms.

O que acontece quando você adiciona clientes?

Com o gargalo já saturado, mais clientes só acrescentam espera. Num único notebook, ele pode ser o servidor ou o cliente de benchmark, que usa uma só thread.

Indo de 50 para 200 clientes, a vazão ficou quase estável (cerca de 117.000 requisições SET e 123.000 GET por segundo) enquanto a latência mediana quase triplicou, para 1,135 e 1,071 ms. É a lei de Little em ação. Cada cliente tem no máximo um comando em andamento, então -c fixa quantos estão no sistema, e se a vazão não pode crescer, o tempo que cada um passa ali precisa crescer. Na nossa execução completa de GET, 50 clientes ÷ 119.617 requisições por segundo dão 0,42 ms por volta de cliente, um pouco acima da média medida de 0,352 ms. Com 200 clientes, a mesma conta dá 1,63 ms.

Por isso a ferramenta também segue um modelo de carga fechado: quando o Redis trava, os clientes esperam, e os comandos que sua aplicação teria enviado nesse meio-tempo nunca aparecem. Nem a página oficial nem o --help trazem uma opção de taxa de requisições fixa, então leia os percentis com a coordinated omission em mente.

Como medir seu próprio comando ou um script Lua?

Escreva o comando depois das opções. A ferramenta passa a rodar só esse comando e ignora -t.

redis-benchmark -n 100000 -q \
  script load "redis.call('set','foo','bar')"
redis-benchmark -r 10000 -n 10000 \
  eval 'return redis.call("ping")' 0

A primeira linha é o exemplo da página oficial; no nosso notebook ela rodou a cerca de 106.000 requisições por segundo. SCRIPT LOAD só carrega o script, então use eval, como na segunda linha, tirada do --help, para medir a execução. Com -r, a ajuda diz que __rand_int__ num argumento vira um número aleatório de 12 dígitos nesse intervalo, e no modo cluster a chave precisa conter uma {tag} para chegar ao nó certo.

Por que sua aplicação vê outros números?

Sua aplicação mede todo o caminho até o Redis: rede, biblioteca cliente, serialização e o próprio mix de comandos. A página oficial lista armadilhas que vale conferir antes de comparar.

Um loop de comandos síncronos mede sobretudo a rede e a biblioteca cliente.
Com cliente e servidor na mesma máquina, a CPU limita o benchmark. Sockets de domínio Unix podem chegar a cerca de 50% mais vazão que o loopback TCP, no Linux por exemplo.
Strings de 4 KB a 100.000 requisições por segundo precisam de cerca de 3,2 Gbit/s, mais do que um link de 1 Gbit/s comporta.
Para comparar o Redis com um banco de dados transacional, ligue o AOF e escolha uma política de fsync adequada.
Notebooks variam a frequência da CPU, o que prejudica a repetibilidade.
INFO em intervalos regulares provavelmente não atrapalha uma execução, enquanto MONITOR deixa o Redis bem mais lento. O panorama de ferramentas de monitoramento do Redis da LoadFocus, que publica este site, cobre as métricas que valem acompanhar.

Esses números de notebook mostram a capacidade real do Redis?

Não. Eles mostram um notebook conversando consigo mesmo, sem rede, com valores de 3 bytes na maioria das execuções, sem persistência e com uma execução por linha.

A tabela mostra como cada opção mexe nos números. A capacidade depende do seu servidor, da sua rede, do tamanho dos seus valores e das suas configurações de persistência.

Quando o redis-benchmark é a ferramenta errada?

Quando você quer saber o que os usuários sentem. Ele envia comandos sintéticos só para o Redis, enquanto o tempo de resposta de uma página inclui também o código da aplicação e as outras chamadas que ela faz.

Para isso, aplique carga na aplicação ou na API que usa o Redis e acompanhe o Redis durante o teste. A LoadFocus, que publica este site, trabalha nessa camada: ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem contra sua aplicação web ou API. Ela não roda o redis-benchmark.

Para ter mais controle sobre o tráfego do Redis, o repositório do memtier_benchmark cita clientes multithread, uma proporção de leitura e escrita, padrões de chave aleatórios ou sequenciais, Redis Cluster e TLS (conferido em 31 de outubro de 2026).

FAQ

O redis-benchmark foi feito para o Redis parecer rápido? Não. A página oficial do Redis chama isso de um equívoco comum: por padrão, a ferramenta mantém no máximo uma consulta pendente por conexão, sem pipelining, e um cliente que usa pipelining consegue gerar mais vazão.

Como encher um banco Redis com o redis-benchmark? Rode só o teste SET com chaves aleatórias, como mostra a ajuda da ferramenta: -t set -n 1000000 -r 100000000 grava cerca de um milhão de chaves. Chaves aleatórias podem se repetir, então o total final fica um pouco abaixo.

A LoadFocus consegue rodar o redis-benchmark? Não. A LoadFocus não roda o redis-benchmark. Os planos de teste JMeter e os scripts k6 dela miram a aplicação web ou a API que fica na frente do Redis.

Leituras relacionadas

Como usar o sysbench: benchmarks de CPU, disco e MySQL

Sat, 31 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

O sysbench é uma ferramenta de benchmark open source e multithread, construída sobre LuaJIT, que traz testes de CPU, memória, E/S de arquivos, threads e mutex, além de scripts OLTP para MySQL e PostgreSQL. Os testes que precisam de dados seguem o mesmo ciclo: prepare cria os arquivos ou as tabelas de teste, run executa o benchmark por um tempo ou número de eventos definido, e cleanup apaga os dados; os testes de CPU e memória só precisam de run. Ele mede uma única máquina ou um único servidor de banco de dados, então não diz como a sua aplicação se comporta com tráfego real de usuários.

Não rodamos o sysbench para este guia. Os fatos vêm do README e do código-fonte no branch master do GitHub, conferidos em 31 de outubro de 2026, e as recomendações são nossas.

Tema	sysbench
Licença	GPLv2
Escrito em	C, com LuaJIT para os scripts
Última versão	1.0.20 (24 de abril de 2020)
Último commit	9 de março de 2025
Testes embutidos	`cpu`, `memory`, `fileio`, `threads`, `mutex`
Scripts de banco de dados	Oito scripts `oltp_`, `bulk_insert`, dois `select_random_`
Drivers de banco de dados	MySQL (padrão), PostgreSQL
Plataformas	Linux, macOS; Windows via WSL

O sysbench ainda é mantido?

Pouco. A última versão, 1.0.20, saiu em abril de 2020; desde então o branch master recebeu commits ocasionais, nenhum deles lançado numa versão, o mais recente em março de 2025.

A versão 1.0.20 tem data de 24 de abril de 2020. O histórico de commits mostra mudanças como uma distribuição uniforme por padrão para --rand-type (2020), um LuaJIT do upstream (2023) e suporte às bibliotecas cliente do MariaDB (2023), depois quatro commits de build em 9 de março de 2025 (conferido em 31 de outubro de 2026). Os repositórios de pacotes citados no README são atualizados a cada versão, então essas mudanças exigem um build a partir do código-fonte.

Como funciona uma execução do sysbench?

Você informa um teste e um comando: sysbench [options] [testname] [command]. O teste é um dos embutidos, um script Lua incluído ou o seu próprio script, e o comando costuma ser prepare, run, cleanup ou help.

Segundo o README, prepare cria os arquivos do fileio ou preenche o banco para os scripts OLTP, cleanup apaga esses dados e sysbench <testname> help lista as opções de um teste. Um teste de disco:

sysbench fileio --file-total-size=8G prepare
sysbench fileio --file-total-size=8G \
  --file-test-mode=rndrw --time=300 run
sysbench fileio --file-total-size=8G cleanup

O código do fileio lista os modos seqwr, seqrewr, seqrd, rndrd, rndwr e rndrw, com 2 GB de arquivos por padrão. Arquivos que cabem na memória podem ser servidos pelo cache de páginas, então use um total maior que a RAM quando quiser medir o disco.

Como medir CPU e memória com o sysbench?

Com sysbench cpu run e sysbench memory run. O teste de CPU informa eventos por segundo, em que um evento verifica se cada número até um limite é primo, e o teste de memória informa operações e MiB transferidos por segundo.

sysbench cpu --cpu-max-prime=20000 \
  --threads=4 --time=60 run

O teste de CPU usa --cpu-max-prime igual a 10000 por padrão, e o teste de memória aceita tamanho de bloco, tamanho total, operações de leitura ou escrita e acesso sequencial ou aleatório (conferido em 31 de outubro de 2026). Compare só execuções com configurações idênticas.

Como testar MySQL ou PostgreSQL com o sysbench?

Escolha um dos scripts OLTP incluídos, preencha as tabelas com prepare, rode transações a partir de várias threads com run e depois apague as tabelas com cleanup. O MySQL é o driver padrão; o PostgreSQL exige --db-driver=pgsql e um build com suporte a PostgreSQL.

sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 --report-interval=10 run

O script OLTP comum cria uma tabela de 10.000 linhas se você não passar --tables e --table-size. No oltp_read_write, cada transação roda 10 consultas por chave, quatro consultas por intervalo, dois updates e um delete seguido de um insert, entre BEGIN e COMMIT (conferido em 31 de outubro de 2026). Use mais dados que o buffer pool do servidor se quiser leituras de disco no resultado.

Quais opções do sysbench importam mais?

--threads e --time definem o tamanho e a duração de uma execução, --rate define uma taxa-alvo de eventos, e --report-interval, --percentile e --histogram decidem o que você vê.

--threads: threads de trabalho, 1 por padrão.
--time: segundos, 10 por padrão, 0 para sem limite. --events limita o número de eventos, e os dois limites valem, então combine com --time=0.
--warmup-time: roda primeiro sem estatísticas, para que caches frios não distorçam o resultado. Só no branch master: a versão 1.0.20 não tem essa opção.
--rate: média de eventos por segundo somando todas as threads; 0, o padrão, significa o mais rápido possível.
--report-interval: números por intervalo a cada N segundos, para mostrar travamentos.
--percentile: o percentil de latência exibido, 95 por padrão.
--histogram: um histograma de latência no fim, definido em sb_logger.c.

O sysbench usa um modelo de carga fechado ou aberto?

Fechado por padrão: um número fixo de threads dispara o próximo evento assim que o anterior termina, então um servidor lento recebe menos eventos. Com --rate, os eventos chegam no próprio ritmo, o que fica mais perto de um modelo de carga aberto.

Nosso artigo sobre o modelo de carga aberto vs fechado explica por que isso muda o que um benchmark mede. No modo padrão, um travamento também atrasa os eventos que teriam começado durante ele, e esses atrasos nunca chegam às latências: é a coordinated omission. O arquivo-fonte principal mostra que --rate põe os eventos numa fila em intervalos com distribuição exponencial, soma à latência de cada evento o tempo que ele esperou na fila e para com o erro "event queue is full" quando as threads não dão conta (conferido em 31 de outubro de 2026).

Como ler a saída do sysbench?

Comece pela vazão: eventos por segundo, ou transações e consultas por segundo nos scripts OLTP. Depois leia o bloco de latência em milissegundos: mínimo, média, máximo, o percentil escolhido (p95 por padrão) e a soma.

A versão 1.0.20 mostra, no lugar de "Throughput", um bloco "General statistics" com o tempo total e o número total de eventos. Os nomes dos campos vêm do código do relatório de banco de dados e do arquivo-fonte principal no master, aqui sem valores:

SQL statistics:
    queries performed: read, write, other, total
    transactions, queries (N per sec.)
    ignored errors, reconnects (N per sec.)
Throughput:
    events/s (eps), time elapsed, total number of events
Latency (ms):
    min, avg, max, 95th percentile, sum
Threads fairness:
    events, execution time (avg/stddev)

Um percentil 95 deixa de fora o evento mais lento de cada vinte. Use --percentile=99 ou acrescente --histogram quando a cauda importa; nosso guia de latência de cauda explica por quê.

Quando o sysbench é a ferramenta errada?

Quando a sua pergunta é sobre a sua aplicação. Uma pontuação de CPU mostra a rapidez com que uma máquina verifica números primos, e uma execução OLTP mede o servidor de banco de dados com as tabelas e consultas do sysbench, sem o seu schema, o seu pool de conexões ou o caminho de rede.

Escolha o pgbench para testes nativos de PostgreSQL: a documentação do PostgreSQL descreve um cenário padrão vagamente baseado no TPC-B, além de arquivos de script próprios (conferido em 31 de outubro de 2026).
Escolha o HammerDB para testes no estilo TPC-C: a documentação dele cobre a carga TPROC-C, derivada do TPC-C, para SQL Server, Db2, Oracle, PostgreSQL, MariaDB e MySQL (conferido em 31 de outubro de 2026).
Escolha o JMeter com o sampler JDBC Request para misturar SQL e HTTP num mesmo plano de teste; o guia de planos de teste de banco de dados diz que o .jar do driver vai na pasta lib do JMeter.

A LoadFocus, que publica este site, não roda o sysbench e não consegue se conectar sozinha a MySQL ou PostgreSQL. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem contra a camada web ou de API que fica na frente do banco. Uma combinação útil: uma execução do sysbench para dimensionar o servidor de banco de dados e depois um teste de carga da aplicação para ver se as requisições reais chegam a esse limite.

FAQ

O sysbench ainda é mantido? Pouco. A última versão é a 1.0.20, de 24 de abril de 2020. O branch master recebeu desde então commits ocasionais, nenhum deles numa versão, o mais recente em 9 de março de 2025.

O que significa o percentil 95 na saída do sysbench? É a latência, em milissegundos, dentro da qual 95% dos eventos terminaram. 95 é o valor padrão da opção --percentile, e você pode definir outro, como 99.

O sysbench consegue fazer benchmark do PostgreSQL? Sim. Os scripts OLTP incluídos rodam contra o PostgreSQL com --db-driver=pgsql quando o sysbench foi compilado com suporte a PostgreSQL.

A LoadFocus consegue rodar o sysbench? Não. A LoadFocus roda planos de teste JMeter e scripts k6 contra sites e APIs a partir de 25 regiões na nuvem, e não se conecta diretamente a MySQL ou PostgreSQL.

Leituras relacionadas

YCSB: cargas de trabalho A-F, execução e limites

Sat, 31 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

O YCSB, Yahoo! Cloud Serving Benchmark, é uma ferramenta open source escrita em Java que carrega registros sintéticos num banco de dados e depois executa sobre eles uma mistura fixa de leituras, atualizações, inserções e scans enquanto registra a vazão e a latência de cada operação. Suas seis cargas de trabalho principais (core workloads), de A a F, são misturas padronizadas, então o mesmo teste pode rodar contra Cassandra, MongoDB, Redis, HBase e dezenas de outros bancos por meio de bindings. Ele mede só o banco de dados, por isso não diz nada sobre as consultas reais da sua aplicação nem sobre a latência que seus usuários veem.

Não rodamos o YCSB para este artigo. Os fatos vêm do repositório no GitHub, da wiki e do código-fonte do projeto, conferidos em 31 de outubro de 2026, e as avaliações são nossas.

Carga de trabalho	Mistura de operações	Distribuição das chaves	Exemplo dado pela wiki
A: muitas atualizações	50% leituras, 50% atualizações	zipfian	Armazenamento de sessões que guarda ações recentes
B: quase só leitura	95% leituras, 5% atualizações	zipfian	Marcação de fotos
C: só leitura	100% leituras	zipfian	Cache de perfis de usuário
D: ler o mais recente	95% leituras, 5% inserções	latest	Atualizações de status de usuários
E: intervalos curtos	95% scans, 5% inserções	zipfian (scans de até 100 registros)	Threads de conversa
F: ler-modificar-gravar	50% leituras, 50% ler-modificar-gravar	zipfian	Banco de dados de usuários

As misturas vêm dos arquivos do diretório workloads e os exemplos da página Core Workloads (conferido em 31 de outubro de 2026). Cada arquivo vem com só 1.000 registros e 1.000 operações: o bastante para depurar uma instalação e pouco demais para um benchmark.

O que é o YCSB, e ele ainda é mantido?

É um gerador de carga com um conjunto de cargas de trabalho padronizadas para comparar bancos chave-valor e de "cloud serving", publicado como open source pelo Yahoo! em 2010 sob a licença Apache 2.0. A última versão é de outubro de 2019, e o código ainda recebe pequenos commits.

A página de publicações cita o artigo original, "Benchmarking Cloud Serving Systems with YCSB", de Cooper, Silberstein, Tam, Ramakrishnan e Sears (ACM SoCC 2010). A versão 0.17.0 tem data de 6 de outubro de 2019 e não existe tag mais nova, enquanto o histórico de commits mostra trabalho em 2026, como uma opção para seguir em frente quando uma inserção falha e uma mudança no binding do Cloud Spanner em 20 de outubro (conferido em 31 de outubro de 2026). Essas mudanças só chegam se você compilar a partir do código-fonte, o que exige o Maven 3.

Como rodar um benchmark com o YCSB?

Em duas fases que compartilham as mesmas propriedades: load insere recordcount registros e depois run executa operationcount operações com a mistura da carga de trabalho. Você informa o binding do seu banco e passa o arquivo da carga de trabalho com -P.

bin/ycsb load mongodb -s -P workloads/workloada \
  -p recordcount=1000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb
bin/ycsb run mongodb -s -P workloads/workloada \
  -p recordcount=1000000 -p operationcount=5000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb \
  -threads 32 -target 20000

A página Running a Workload traz os detalhes que mais pegam as pessoas (conferido em 31 de outubro de 2026). O cliente nunca cria tabelas, então antes você precisa mapear a usertable para o que o seu banco exige, como uma tabela no MySQL ou um keyspace no Cassandra. Arquivos -P posteriores sobrescrevem os anteriores, e -p sobrescreve todos. A fase run precisa do mesmo recordcount da carga, porque escolhe as chaves dentro de todo o conjunto de dados. -s mostra uma linha de status a cada 10 segundos. Como D e E inserem registros, a página Core Workloads recomenda carregar uma vez com o arquivo de A, rodar A, B, C, F e D, depois apagar os dados e carregar de novo para E.

O que -threads e -target controlam?

-threads define quantas threads de cliente enviam operações (uma por padrão), e -target limita o total de operações por segundo. Sem alvo, cada thread envia a próxima operação assim que a anterior volta, então um banco mais lento simplesmente recebe menos carga.

É um modelo de carga fechado, e nosso artigo sobre o modelo de carga aberto vs fechado explica o que ele esconde. O exemplo da wiki, 10 threads com alvo de 100 operações por segundo, só se sustenta enquanto a latência média fica abaixo de 100 ms; com threads de menos, a taxa alcançada fica abaixo do alvo. É a lei de Little em ação: threads divididas pela latência média limitam a vazão. Se você rodar vários alvos e anotar a latência de cada um, obtém a curva do nosso guia sobre vazão vs latência.

Como ler a saída do YCSB?

No fim de cada fase, o cliente imprime um bloco [OVERALL] com o tempo de execução e a vazão, depois um bloco por tipo de operação com a contagem, as latências média, mínima, máxima e por percentil, e uma contagem por código de retorno.

Estes nomes de campo vêm do código-fonte da 0.17.0; os valores são marcadores de posição:

[OVERALL], RunTime(ms), <total>
[OVERALL], Throughput(ops/sec), <rate>
[READ], Operations, <count>
[READ], AverageLatency(us), <value>
[READ], 95thPercentileLatency(us), <value>
[READ], 99thPercentileLatency(us), <value>
[READ], Return=OK, <count>

A saída de exemplo da wiki mostra milissegundos, mas a medição HdrHistogram padrão, tanto na 0.17.0 quanto no código atual, informa microssegundos, (us). A página Core Properties e a versão 0.17.0 definem os percentis padrão como 95 e 99, que você muda com hdrhistogram.percentiles; desde abril de 2025 o branch master acrescenta o 50, então um build a partir do código-fonte também mostra 50thPercentileLatency(us) (conferido em 31 de outubro de 2026). O README chama a atenção para o P99 e além, avisa que não se tira média de percentis e recomenda, com vários clientes, salvar arquivos de histograma HDR com hdrhistogram.fileoutput=true e juntá-los.

O YCSB leva em conta a coordinated omission?

Só se você pedir, e só com -target. Por padrão, cada latência é medida a partir do momento em que a operação é de fato enviada, então uma travada que atrasa as operações seguintes quase não aparece.

O código-fonte das medições tem uma propriedade measurement.interval que aceita op (padrão), intended ou both (conferido em 31 de outubro de 2026). Com um alvo, cada thread anota o início previsto de cada operação; intended mede a latência a partir desse ponto, e both acrescenta blocos Intended- como [Intended-READ] ao lado dos habituais. A wiki não menciona a propriedade, então confira o código da versão que você compilar. Nosso guia sobre coordinated omission explica por que o início previsto dá o número honesto.

Quais bancos de dados o YCSB consegue testar?

Qualquer um que tenha um binding. O arquivo de build do branch master lista 46 módulos de binding, entre eles Cassandra, MongoDB, Redis, HBase, DynamoDB, Cloud Spanner, RocksDB e um binding JDBC genérico.

A lista está no pom.xml, e cada diretório de binding tem o próprio README com as propriedades de conexão, como mongodb.url no binding do MongoDB (conferido em 31 de outubro de 2026). Segundo a página Running a Workload, uma única máquina cliente basta para clusters de umas 10 máquinas; acima disso, você sobe vários clientes, e a página Running a Workload in Parallel divide a carga entre eles com insertstart e insertcount.

Quando o YCSB não é a ferramenta certa?

Quando a sua pergunta é sobre a sua aplicação. A carga de trabalho principal grava registros sintéticos, 10 campos com comprimento de 100 cada por padrão, com operações simples por chave, então não consegue mostrar como suas próprias consultas, seus índices ou o código da sua API se comportam sob carga.

Para OLTP relacional, o pgbench roda no PostgreSQL um script inspirado no TPC-B e aceita scripts seus, e o sysbench traz benchmarks em Lua no estilo OLTP (ambos conferidos em 31 de outubro de 2026).
Para a latência que os usuários veem, coloque sob carga a camada HTTP ou de API que fica na frente do banco. A LoadFocus, que publica este site, roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem contra endpoints web e de API. A LoadFocus não roda o YCSB.

FAQ

Quais são as cargas de trabalho principais do YCSB? Seis misturas padronizadas: A tem 50% de leituras e 50% de atualizações, B tem 95% de leituras, C só leituras, D privilegia os registros inseridos mais recentemente, E faz scans curtos e F faz operações de leitura-modificação-gravação.

Qual a diferença entre ycsb load e ycsb run? A fase load insere o número de registros definido por recordcount. A fase run depois executa operationcount operações com a mistura da carga de trabalho sobre esses registros e informa a vazão e a latência.

O YCSB ainda é mantido? A última versão, 0.17.0, saiu em 6 de outubro de 2019. O repositório ainda recebe commits de vez em quando, o mais recente em 20 de outubro de 2026, então as correções novas exigem compilar a partir do código-fonte.

A LoadFocus consegue rodar benchmarks do YCSB? Não. A LoadFocus não roda o YCSB. Os planos de teste JMeter e os scripts k6 dela miram endpoints web e de API, ou seja, a camada que fica na frente do banco de dados.

Leituras relacionadas

Teste de carga com NBomber: análise do framework .NET

Wed, 21 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

O NBomber é um framework de teste de carga para .NET: você escreve cada teste como um cenário em C# ou F#, adiciona a um projeto comum e roda como qualquer outro programa. O teste de carga com NBomber combina com times que já desenvolvem em .NET e querem os testes de carga na mesma linguagem, no mesmo repositório e no mesmo executor de testes. O NBomber só é gratuito para uso pessoal e acadêmico; uma empresa precisa de uma licença paga, e esse fato decide mais avaliações do que qualquer recurso.

Não rodamos o NBomber para esta análise. Os fatos vêm da documentação, da página de preços, do repositório no GitHub e do pacote no NuGet do NBomber, conferidos em 21 de outubro de 2026, e as avaliações são nossas.

Tema	NBomber
Licença	Gratuito para uso pessoal e acadêmico; pago para organizações
Preço para uma empresa	Business US$ 1.500 por ano, Enterprise US$ 2.500 por ano
Versão atual	6.7.1 (16 de outubro de 2026)
Runtime	.NET Standard 2.1, ou seja, .NET Core 3.0 ou mais novo
Testes escritos como	Cenários em C# ou F#
Modelo de carga	Inject (taxa de chegada) ou cópias constantes
Critérios de aprovação	Thresholds durante a execução, asserts sobre as estatísticas finais
Escala	NBomber Cluster, licença Enterprise

Quem faz o NBomber, e ele é gratuito?

A NBomber LLC desenvolve o framework, com o código no GitHub. Ele é gratuito para uso pessoal, hobby e acadêmico, e a página de licença diz com todas as letras que o NBomber não é gratuito para organizações.

A página de licença conta benchmarks, tutoriais e conteúdo de análise como uso pessoal. Dentro de uma empresa você precisa de uma licença Business ou Enterprise, emitida por organização e não por desenvolvedor, sem limite de instâncias ou de execuções em paralelo. A página de preços traz US$ 1.500 por ano para Business e US$ 2.500 por ano para Enterprise, ambas com 30 dias de garantia de reembolso. A chave de licença vai para o executor com .WithLicense(...) ou um argumento --license, e o NBomber precisa de acesso à internet para validá-la, com validação offline disponível sob pedido por e-mail (conferido em 21 de outubro de 2026).

A versão mais recente é a v6.7.1, publicada em 16 de outubro de 2026, quatro dias depois da 6.7.0 (conferido em 21 de outubro de 2026).

Como funciona um cenário do NBomber?

Um cenário é um nome mais uma função assíncrona que o NBomber cronometra a cada chamada. Você anexa simulações de carga e thresholds, registra o cenário no NBomberRunner e roda o programa.

Este teste pula o warm-up, sobe a taxa de chegada para 50 novas cópias do cenário por segundo em dois minutos, mantém por dez minutos e termina com código de saída 1 se 1% ou mais das requisições tiverem falhado. Ele usa o plugin NBomber.Http para a requisição:

var http = Http.CreateDefaultClient();

var scenario = Scenario.Create("browse", async context =>
{
    var request = Http.CreateRequest("GET",
        "https://staging.example.com/products");
    return await Http.Send(http, request);
})
.WithoutWarmUp()
.WithLoadSimulations(
    Simulation.RampingInject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(2)),
    Simulation.Inject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(10)))
.WithThresholds(
    Threshold.Create(s => s.Fail.Request.Percent < 1));

var result = NBomberRunner
    .RegisterScenarios(scenario).Run();
return result.Thresholds.Any(t => t.IsFailed) ? 1 : 0;

A página do cliente HTTP recomenda Http.CreateDefaultClient() em vez de um simples new HttpClient() e diz que o plugin registra os códigos de status e os dados transferidos (conferido em 21 de outubro de 2026). Um threshold sozinho só registra a falha no relatório; é a última linha que transforma isso num código de saída que um pipeline consegue ler. Sem .WithoutWarmUp(), o NBomber roda antes um warm-up de 30 segundos com as simulações do próprio cenário, segundo a página de cenários (conferido em 21 de outubro de 2026). Como o cenário é C# comum, tudo o que uma biblioteca .NET consegue chamar pode ser colocado sob carga do mesmo jeito.

Que modelos de carga o NBomber oferece?

Os dois. As simulações inject iniciam novas cópias a uma taxa fixa, não importa o que as anteriores estejam fazendo, o que é um modelo de carga aberto; as simulações constant mantêm um número fixo de cópias rodando, o que é um modelo fechado.

A página de simulações de carga lista todas (conferido em 21 de outubro de 2026):

Abertas: Inject, RampingInject, InjectRandom e IterationsForInject.
Fechadas: KeepConstant, RampingConstant e IterationsForConstant.
Controle de tempo: Pause, que atrasa o início de um cenário ou o pausa por um tempo definido.

Nosso artigo sobre o modelo de carga aberto vs fechado explica qual combina com o seu tráfego. Um site público costuma se comportar como o modelo aberto; um grupo fixo de clientes internos, como o fechado.

Como funcionam os thresholds e os critérios de aprovação?

Os thresholds em tempo de execução checam as estatísticas em andamento, a cada 5 segundos por padrão, e aparecem no relatório HTML. Os asserts, escritos em xUnit ou NUnit, checam as estatísticas finais depois da execução, e um assert que falha encerra a execução com status de falha.

A página de thresholds mostra checagens de porcentagem de erros, códigos de status, percentis de latência (p50, p75, p95, p99 e máximo), requisições por segundo e bytes transferidos. Por padrão um threshold não para o teste; abortWhenErrorCount faz ele parar depois de um número definido de checagens que falharam (conferido em 21 de outubro de 2026). A página não informa um código de saída, por isso o exemplo acima devolve um a partir do resultado. Nosso guia de critérios de aprovação de um teste de carga ajuda a escolher os limites.

Quais protocolos o NBomber consegue testar?

Qualquer protocolo que uma biblioteca .NET fale, porque o NBomber só cronometra o código que você entrega. Há plugins prontos para HTTP, WebSockets, MQTT e AMQP, além de uma opção WebBrowser.

A página de visão geral descreve o framework como independente de protocolo, e a página de preços inclui esses plugins em todos os planos, inclusive no gratuito. Isso vale também para bancos de dados e filas de mensagens que você chama pelos próprios clientes .NET (conferido em 21 de outubro de 2026). Em troca, fora dos plugins você escreve e mantém o código do cliente.

Como escalar um teste do NBomber?

Com o NBomber Cluster: um Coordinator orquestra a execução e os Agents rodam os cenários, todos conversando por um broker de mensagens NATS. O Cluster faz parte da licença Enterprise.

A visão geral do cluster explica os papéis, e a página de licença diz que os desenvolvedores podem testá-lo localmente com um Local Dev Cluster antes de comprar; a página do Local Dev Cluster limita o Local Dev Cluster a 1 Coordinator e 2 Agents e para cada execução depois de um minuto (conferido em 21 de outubro de 2026). A integração com Kubernetes do NBomber Studio, também exclusiva do Enterprise, provisiona o NATS e os pods dos Agents para você. Sem o Cluster, um processo do NBomber roda numa só máquina; a página de requisitos de sistema sugere de 4 a 8 núcleos de CPU para carga alta.

A LoadFocus, que publica este site, não roda testes do NBomber. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem.

O que o NBomber faz bem, e onde estão os limites?

Ele é forte para times .NET: os testes são código C# ou F#, qualquer cliente .NET vira um teste de carga e os dois modelos de carga já vêm prontos. Os limites são a licença para empresas, um ecossistema de uma linguagem só e execuções distribuídas pagas.

Os testes ficam ao lado do código da aplicação, com a mesma IDE, os mesmos pacotes e as mesmas revisões.
Os thresholds já vêm embutidos, e os asserts rodam dentro dos testes xUnit ou NUnit que você já tem.
O uso comercial exige licença, mesmo para um único desenvolvedor.
Execuções distribuídas exigem o Enterprise e um broker NATS.
Quem não conhece .NET vai precisar aprender C# ou F# primeiro.

Quando escolher k6, Gatling ou JMeter em vez do NBomber?

Escolha outra ferramenta quando o seu time não programa em .NET ou quando o custo da licença não cabe.

Escolha o k6 quando quiser scripts em JavaScript e uma ferramenta open source sem custo de licença para uso na empresa: o repositório dele é AGPL-3.0 (conferido em 21 de outubro de 2026). A LoadFocus roda scripts k6 a partir de 25 regiões na nuvem, embora rode cenários arrival-rate com um número fixo de usuários. Escolha o Gatling para uma ferramenta baseada em código na JVM; nossa análise do Gatling cobre o tema. Escolha o JMeter quando os testadores preferem uma interface gráfica ou quando você precisa de samplers JDBC, JMS ou LDAP de fábrica. O panorama de ferramentas de teste de carga open source coloca todas lado a lado.

FAQ

O NBomber é gratuito para uso comercial? Não. O NBomber só é gratuito para uso pessoal e acadêmico. Uma empresa precisa de uma licença Business de US$ 1.500 por ano ou de uma licença Enterprise de US$ 2.500 por ano.

Quais versões do .NET o NBomber suporta? Ele mira o .NET Standard 2.1, então roda no .NET Core 3.0 e em todas as versões do .NET posteriores. A documentação recomenda o .NET 10.

A LoadFocus consegue rodar testes do NBomber? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para rodar o NBomber em mais de uma máquina, use o NBomber Cluster, que exige uma licença Enterprise.

Leituras relacionadas

Teste de carga com Tsung: análise da ferramenta Erlang

Wed, 21 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

O Tsung é uma ferramenta de teste de carga open source escrita em Erlang, que descreve cada teste num arquivo XML e consegue distribuir a carga entre muitas máquinas cliente. O teste de carga com Tsung ainda faz sentido para protocolos que poucas ferramentas cobrem, como XMPP, LDAP ou PostgreSQL no nível do protocolo, e para um número muito grande de usuários em hardware modesto. A última versão saiu em março de 2023, então para testes novos de HTTP ou de API a maioria dos times se sai melhor com k6, Gatling ou JMeter.

Não rodamos o Tsung para esta análise. Os fatos vêm da documentação e do repositório no GitHub do Tsung, conferidos em 21 de outubro de 2026, e as avaliações são nossas.

Tema	Tsung
Licença	GPL-2.0
Escrito em	Erlang (exige Erlang/OTP R16B03 ou mais novo)
Última versão	1.8.0 (2 de março de 2023)
Testes escritos como	Arquivos de configuração XML
Modelo de carga	Novos usuários por fase de chegada (aberto)
Protocolos	HTTP, WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT, TCP/UDP puros (alguns experimentais)
Escala	Máquinas cliente via SSH sem senha
Relatórios	Painel ao vivo na porta 8091, relatório HTML com `tsung_stats.pl`

Quem mantém o Tsung, e ele ainda está ativo?

A ProcessOne hospeda o projeto no GitHub sob GPL-2.0. Ele é mantido, mas com pouco movimento: a última versão, 1.8.0, é de março de 2023, e desde então chegam só pull requests mescladas de vez em quando.

O repositório mostra o commit mais recente em 2 de março de 2026, uma pull request que troca chamadas obsoletas, e a tag v1.8.0 tem data de 2 de março de 2023 (conferido em 21 de outubro de 2026). A documentação ainda traz o título 1.7.0, então confira o repositório quando um detalhe parecer desatualizado. Um projeto calmo também significa menos respostas quando algo dá errado.

Como funciona um teste do Tsung?

Um teste é um arquivo XML com quatro partes principais: as máquinas cliente, os servidores alvo, as fases de carga e as sessões de usuário. Cada novo usuário escolhe uma sessão pela probabilidade dela e executa as requisições em ordem.

Este trecho inicia cinco novos usuários por segundo durante dez minutos; cada um carrega uma lista de produtos, faz uma pausa de uns dois segundos e manda uma requisição POST para o carrinho:

<load>
  <arrivalphase phase="1" duration="10" unit="minute">
    <users arrivalrate="5" unit="second"/>
  </arrivalphase>
</load>
<sessions>
  <session name="browse" probability="100"
           type="ts_http">
    <request><http url="/products" method="GET"/></request>
    <thinktime value="2" random="true"/>
    <request><http url="/cart" method="POST"
                   contents="sku=A-100"/></request>
  </session>
</sessions>

A página de sessões diz que as probabilidades das sessões precisam somar 100 (desde a 1.5.0 também dá para usar pesos) e que um tempo de pensamento aleatório segue uma distribuição exponencial em torno do valor, a menos que você informe uma faixa com min e max (conferido em 21 de outubro de 2026). Para HTTP e PostgreSQL existe um gravador proxy que transforma uma sessão de navegador ou de cliente nesse XML.

Que modelo de carga o Tsung usa?

Um modelo de carga aberto. Cada fase de chegada inicia novos usuários num intervalo ou numa taxa fixos, não importa o que os usuários já em execução estejam fazendo, e uma fase termina quando o tempo dela acaba, mesmo que as sessões não tenham terminado.

A página de carga lista os controles: interarrival ou arrivalrate por fase, maxnumber para limitar os usuários que uma fase inicia, um duration na carga inteira para parar o teste num horário fixo, e wait_all_sessions_end para a fase seguinte esperar os usuários atuais terminarem (conferido em 21 de outubro de 2026). Nossos artigos sobre o modelo de carga aberto vs fechado e sobre o tempo de pensamento explicam como essas escolhas mudam o que um teste mede.

Quais protocolos o Tsung consegue testar?

Mais do que a maioria das ferramentas de teste de carga: HTTP (inclusive SOAP), WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT e TCP, UDP ou SSL puros. A documentação marca como experimentais os plugins de MySQL, WebSocket, AMQP e MQTT, com AMQP só na 0.9.1 e MQTT só na 3.1.

A página de recursos descreve cada plugin (conferido em 21 de outubro de 2026). Em XMPP e PostgreSQL o Tsung tem há muito tempo poucos concorrentes: ele fala o protocolo por conta própria, então você testa o servidor, não uma biblioteca cliente. Para apps em tempo real, nosso panorama de ferramentas de teste de carga WebSocket coloca o Tsung ao lado de opções mais novas.

Como distribuir um teste do Tsung entre várias máquinas?

Você lista as máquinas cliente no XML, e o controlador inicia a carga nelas via SSH sem senha, ou via rsh. Cada cliente pode receber um peso, um limite de usuários e um número de CPUs.

A página de clientes e servidor explica que o Tsung roda uma máquina virtual Erlang por CPU declarada com cpu em cada cliente (uma por padrão) e sobe uma nova quando uma VM chega a maxusers. Ele também pode pegar as máquinas cliente de um agendador de lotes como PBS, LSF ou OAR. A página de instalação pede Erlang/OTP R16B03 ou mais novo e, como opção, Perl 5 e gnuplot, ou Python e matplotlib, para os gráficos (conferido em 21 de outubro de 2026).

A LoadFocus, que publica este site, não roda arquivos do Tsung. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem.

Como ler os resultados do Tsung?

De duas formas: num painel ao vivo que o controlador serve na porta 8091 e num relatório HTML que o script tsung_stats.pl gera depois da execução.

A página de relatórios diz que o painel existe desde a 1.6.0, mostra o status atual, monta os gráficos enquanto o teste roda e para quando o teste termina, a menos que você inicie o Tsung com -k (conferido em 21 de outubro de 2026). O relatório cobre tempos de resposta e de conexão, transações, requisições por segundo e códigos de erro, e pode incluir dados de CPU, memória e rede dos servidores, coletados por agentes Erlang, SNMP ou munin. A documentação não descreve nenhum limite de aprovação, então um pipeline de CI precisa analisar os resultados por conta própria; nosso guia de critérios de aprovação de um teste de carga mostra o que conferir.

O que o Tsung faz bem, e onde estão os limites?

Ele é forte em variedade de protocolos, fases de chegada abertas e muitos usuários por máquina, que a documentação coloca na casa dos milhares por CPU. Os limites são um histórico de versões com pouco movimento, scripts só em XML e nenhuma checagem de aprovação embutida.

Testes de XMPP, LDAP e banco de dados no nível do protocolo, sem escrever código cliente.
Distribuição por SSH simples, sem broker nem serviço extra.
Monitoramento dos servidores no mesmo relatório.
Qualquer lógica além do XML exige Erlang, que poucos times escrevem.
O Erlang precisa estar instalado no controlador e em cada cliente.

Quando escolher k6, Gatling ou JMeter em vez do Tsung?

Escolha outra ferramenta quando você testa HTTP ou APIs e quer um projeto ativo, com scripts numa linguagem popular.

Escolha o k6 para scripts em JavaScript com thresholds dentro do próprio script e um projeto ativo (conferido em 21 de outubro de 2026). Escolha o Gatling para simulações em código na JVM; nossa análise do Gatling cobre o tema. Escolha o JMeter quando os testadores querem uma interface gráfica ou quando você precisa de samplers JDBC, JMS ou LDAP com um grande ecossistema de plugins. A LoadFocus roda JMeter e k6 a partir de 25 regiões na nuvem, e o panorama de ferramentas de teste de carga open source coloca essas ferramentas lado a lado.

FAQ

O Tsung ainda é mantido? Sim, mas com pouco movimento. A última versão, 1.8.0, saiu em 2 de março de 2023, e o repositório ainda recebe de vez em quando mudanças mescladas, a mais recente em março de 2026.

Quais protocolos o Tsung suporta? HTTP e SOAP, WebDAV, XMPP, PostgreSQL, LDAP e TCP, UDP ou SSL puros, além de MySQL, WebSocket, AMQP e MQTT, que a documentação marca como experimentais.

A LoadFocus consegue rodar testes do Tsung? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para distribuir um teste do Tsung entre várias máquinas, liste-as como clientes no arquivo XML.

Leituras relacionadas

Pontuação Apdex: o que é e como calcular

Mon, 19 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Uma pontuação Apdex é um número entre 0 e 1 que diz qual parte das requisições foi rápida o bastante para quem esperava por elas. Você escolhe um tempo-alvo T: respostas até T contam inteiras, respostas até quatro vezes T contam pela metade e as mais lentas contam zero. Um resultado de 1 significa que todas as requisições atingiram o alvo, e 0 que todas foram lentas demais.

Zona	Tempo de resposta	Peso na pontuação
Satisfeito (satisfied)	até T	1
Tolerável (tolerating)	acima de T, até 4T	0,5
Frustrado (frustrated)	acima de 4T	0

Os fatos abaixo vêm da documentação e do código-fonte das ferramentas, conferidos em 19 de outubro de 2026.

Como calcular uma pontuação Apdex?

Some as requisições satisfeitas com metade das toleráveis e divida pelo total. O resultado sempre fica entre 0 e 1.

Apdex(T) = (satisfied + tolerating / 2) / total

A documentação de Apdex da New Relic resolve um exemplo com T em 500 ms: de 200 requisições, 170 terminaram em até 500 ms, 20 levaram entre 500 ms e 2 segundos, e 10 falharam ou demoraram mais. Isso dá (170 + 20 / 2) / 200 = 0,90 (conferido em 19 de outubro de 2026).

Um segundo exemplo mostra por que a pontuação é útil num teste de carga. Digamos que uma execução envie 10.000 requisições com T em 300 ms: 8.200 terminam em 300 ms, 1.300 entre 300 ms e 1,2 segundo, e 500 demoram mais. O Apdex é (8.200 + 650) / 10.000 = 0,885. A mesma execução pode mostrar sem problema uma média de 280 ms, que parece boa sozinha e esconde as 500 requisições acima de um segundo.

De onde vem o Apdex?

Apdex, sigla de Application Performance Index, é um padrão aberto de um grupo de empresas chamado Apdex Alliance. Peter Sevcik, da NetForecast, fundou a Alliance em 2004.

O artigo da Wikipédia sobre Apdex cita o artigo de Sevcik de 2005 e traz a regra de 4T. O Apdex Users Group diz hoje que as regras dos limites T e F "se tornaram flexíveis" (conferido em 19 de outubro de 2026), e as ferramentas usam essa liberdade.

Como JMeter, Artillery e LoadFocus calculam a pontuação?

As três partem de T = 500 ms. Elas diferem em onde termina a zona tolerável e no que fazem com as requisições com falha, então a mesma execução pode dar três valores um pouco diferentes.

Ferramenta	T padrão	Tolerável até	Requisições com falha
Dashboard HTML do JMeter	500 ms	1.500 ms	contam como frustradas
Plugin `apdex` do Artillery	500 ms	4T (2.000 ms)	só respostas recebem nota
Página de resultados da LoadFocus	500 ms, fixo	4T (2.000 ms)	classificadas pelo tempo de resposta
New Relic APM	definido por aplicação	4T	erros de servidor são frustrados

JMeter. O relatório do dashboard tem uma tabela APDEX por transação. Os padrões são jmeter.reportgenerator.apdex_satisfied_threshold=500 e apdex_tolerated_threshold=1500, então a zona tolerável termina em 3T a menos que você mude, e apdex_per_transaction define limites diferentes por sampler. Em ApdexSummaryConsumer, uma amostra com falha entra no total e nunca nas satisfeitas ou toleráveis, então cada falha derruba a pontuação (conferido em 19 de outubro de 2026).

Artillery. O plugin apdex só funciona com o motor HTTP e publica os contadores apdex.satisfied, apdex.tolerated e apdex.frustrated. O código em artillery-plugin-apdex 1.24.0 classifica cada resposta pelo tempo total em relação a T e 4T e depois imprime a pontuação com um rótulo: excellent a partir de 0,94, good a partir de 0,85, fair a partir de 0,70, poor a partir de 0,49 e unacceptable abaixo disso. Uma requisição que nunca recebe resposta nunca é classificada (conferido em 19 de outubro de 2026). Nossa análise do Artillery trata da ferramenta em si.

A LoadFocus, que publica este site, mostra a pontuação Apdex na aba Insights do resultado de um teste de carga, ao lado de um histograma de tempos de resposta. T é fixo em 500 ms e a zona tolerável termina em 2.000 ms; não dá para mudar T. Cada amostra é classificada pelo tempo de resposta, com as partes satisfeita, tolerável e frustrada ao lado da pontuação.

Como escolher o limite T?

Escolha T pelo que os usuários daquela página ou daquele endpoint esperam, e defina por transação quando a ferramenta permitir. Um único T para a aplicação inteira mistura um endpoint de busca rápido e uma exportação de relatório lenta num número só.

Algumas regras práticas:

Comece de uma meta real. Se você já tem uma meta de latência como "95% das chamadas de checkout abaixo de 400 ms", T = 400 ms faz o Apdex e a meta contarem a mesma história.
Mantenha o mesmo T entre execuções. Um Apdex só se compara com outro medido no mesmo T. Escreva Apdex(0.4) ou "Apdex com T = 400 ms" para ninguém comparar limites diferentes.
Ajuste também a zona tolerável. O padrão do JMeter para em 3T e os outros em 4T. Antes de comparar um relatório do JMeter com outra ferramenta, coloque apdex_tolerated_threshold em quatro vezes T.
Não mexa em T para uma versão passar. Mudar T depois de uma execução ruim troca a régua, e a tendência que você acompanhava se perde.

O que é uma boa pontuação Apdex?

O plugin do Artillery chama de excellent 0,94 ou mais, de good 0,85 a 0,94 e de poor ou pior tudo abaixo de 0,70. Esses rótulos só significam algo se T foi escolhido com honestidade.

Um Apdex de 0,95 com T = 2 segundos pode descrever um serviço mais lento que 0,80 com T = 200 ms. Ao definir um critério para liberar uma versão, escreva o limite e a pontuação juntos ("Apdex(0.5) de pelo menos 0,9") e confira ao lado de um limite de percentil, porque os dois pegam problemas diferentes.

O que o Apdex esconde?

Ele espreme toda a distribuição de tempos de resposta em três faixas, então não diz quão lentas foram as requisições frustradas. Uma requisição de 2,1 segundos e outra de 30 segundos baixam a pontuação exatamente o mesmo tanto.

Por isso ele funciona melhor ao lado de outros números:

Percentis mostram quão lentas são as requisições lentas. Nosso guia sobre latência de cauda explica por que o percentil 99 importa assim que uma página chama vários serviços.
A taxa de erros pega falhas que sua ferramenta talvez não pontue. O Artillery nunca pontua requisições sem resposta e a New Relic conta erros de servidor como frustrados, então leia o número de erros à parte.
O tamanho da amostra importa: a New Relic avisa que abaixo de umas 100 requisições por minuto a pontuação fica instável.
O viés de medição também pesa. Um gerador de carga que espera as respostas lentas envia menos requisições nos períodos lentos, e o Apdex parece melhor que a realidade; veja coordinated omission.

Como usar o Apdex num teste de carga?

Use como resumo para quem não vai ler um histograma, e deixe a decisão de aprovar ou reprovar com limites explícitos.

Uma rotina que funciona:

Defina T por transação importante a partir da sua meta de latência.
Rode o teste e anote o Apdex nesse T, junto com os percentis 95 e 99 e a taxa de erros.
Compare o Apdex com a execução anterior no mesmo T. Uma queda de 0,93 para 0,86 é um sinal claro até para quem é de fora do time.
Faça o build falhar por limites de percentil e de erros, como descreve nosso guia de critérios de aprovação de um teste de carga, e reporte o Apdex ao lado.

FAQ

Uma pontuação Apdex mais alta é melhor? Sim. 1,0 significa que todas as requisições terminaram dentro de T, e 0 que todas passaram do limite tolerável ou contaram como frustradas.

Qual é o limite Apdex padrão no JMeter? O dashboard HTML usa 500 ms para satisfeito e 1.500 ms para tolerável. Mude com jmeter.reportgenerator.apdex_satisfied_threshold e apdex_tolerated_threshold.

O Apdex inclui os erros? Depende da ferramenta. O JMeter conta amostras com falha como frustradas e a New Relic faz o mesmo com erros de servidor, enquanto o plugin do Artillery só pontua requisições que receberam resposta.

Dá para comparar pontuações Apdex de duas ferramentas? Só quando T, o limite tolerável e o tratamento de erros coincidem. Caso contrário, compare os percentis e as taxas de erros que estão por trás.

Leituras relacionadas

Teste de carga com Artillery: análise da ferramenta Node.js

Mon, 19 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

O Artillery é uma ferramenta de teste de carga open source que roda em Node.js e descreve cada teste num arquivo YAML, TypeScript ou JavaScript. O teste de carga com Artillery combina com times que vivem no ecossistema JavaScript, que querem novos usuários chegando num ritmo definido ou que querem testes de navegador com Playwright na mesma ferramenta. Times que querem um binário único sem runtime ficam mais bem servidos com o k6, e times que precisam de muitos protocolos de fábrica, com o JMeter.

Não rodamos o Artillery para esta análise. Os fatos vêm da documentação, do repositório, do pacote no npm e da página de preços do Artillery, conferidos em 19 de outubro de 2026, e as avaliações são nossas.

Tópico	Artillery
Licença	MPL-2.0; alguns módulos do Azure sob BSL
Runtime	Node.js, LTS mais recente (o pacote pede 22.18.0 ou mais novo)
Versão atual	2.0.34 (14 de agosto de 2026)
Testes escritos em	YAML, TypeScript ou JavaScript
Modelo de carga	Novos usuários virtuais por segundo, em fases
Motores embutidos	HTTP, WebSocket, Socket.IO, Playwright
Checagens de aprovação	Plugin `ensure`, código de saída diferente de zero
Escala	`run-lambda`, `run-fargate`, `run-aci`
Relatórios hospedados	Artillery Cloud, opcional, com plano gratuito

Quem desenvolve o Artillery, e qual é a licença?

A Artillery Software Inc. mantém o projeto no GitHub. A maior parte do código está sob MPL-2.0, que permite uso comercial; alguns módulos específicos do Azure estão sob a Business Source License.

O README do repositório permite usar o Artillery no Azure para avaliação e prova de conceito, e exige licença comercial para uso comercial ou em produção ali. A versão mais recente é a 2.0.34, publicada no npm em 14 de agosto de 2026, e os metadados do pacote pedem Node.js 22.18.0 ou mais novo; o guia de instalação recomenda a LTS mais recente (conferido em 19 de outubro de 2026).

Como funciona um script de teste do Artillery?

Um script tem duas partes: config, que define o alvo, as fases de carga e os plugins, e scenarios, que lista o que cada usuário virtual faz. Você pode escrever em YAML ou exportar config e scenarios de um arquivo TypeScript ou JavaScript.

Este teste sobe de 5 para 50 novos usuários por segundo em dois minutos, mantém 50 por segundo por dez minutos e falha se o percentil 99 do tempo de resposta chegar a 800 ms:

config:
  target: https://staging.example.com
  phases:
    - duration: 120
      arrivalRate: 5
      rampTo: 50
      name: ramp
    - duration: 600
      arrivalRate: 50
      name: sustain
  plugins:
    ensure:
      thresholds:
        - http.response_time.p99: 800
scenarios:
  - name: browse and add to cart
    flow:
      - get:
          url: /products
      - think: 2
      - post:
          url: /cart
          json:
            sku: A-100

Segundo a referência de scripts de teste, os quatro tipos de fase são uma taxa de chegada constante, uma rampa linear com rampTo, um arrivalCount fixo distribuído num período e uma pause. O código próprio carregado por config.processor pode ser um módulo TypeScript localmente e no Fargate, mas não no Lambda (conferido em 19 de outubro de 2026).

Que modelo de carga o Artillery usa?

O Artillery inicia novos usuários virtuais no ritmo que você define, tenham os anteriores terminado ou não. É um modelo de carga aberto, que mantém as chegadas mesmo quando o sistema fica lento.

Cada novo usuário escolhe um cenário, roda e vai embora, então um sistema lento acumula usuários como o tráfego real faria. maxVusers limita o número de usuários simultâneos numa fase se você precisar proteger o gerador de carga. Nosso artigo sobre o modelo de carga aberto vs fechado explica a diferença, e a lei de Little mostra como a taxa de chegada e o tempo de resposta definem o número de usuários simultâneos.

Quais protocolos e navegadores ele testa?

HTTP é o padrão, e WebSocket, Socket.IO e Playwright vêm embutidos. gRPC e AWS Kinesis precisam de motores instalados à parte.

A página de motores descreve o modelo: cada cenário roda num motor, e você pode escrever o seu. No npm, o artillery-engine-grpc está na 0.0.9 e o artillery-engine-kinesis na 1.1.1, ambos sob MPL-2.0. O motor Playwright roda seu código Playwright em navegadores headless reais e publica Web Vitals como TTFB, FCP e LCP por página. A documentação avisa que um navegador separado por usuário, em vez de um contexto de navegador, exige muito mais CPU e memória (conferido em 19 de outubro de 2026). Nosso panorama de ferramentas de teste de carga WebSocket coloca o Artillery ao lado de outras opções para apps em tempo real.

Como ele se encaixa na CI?

O plugin ensure transforma métricas em checagens de aprovação, e uma checagem que falha faz o Artillery sair com código diferente de zero. Isso basta para qualquer sistema de CI reprovar o build.

A referência do ensure oferece dois tipos de checagem: thresholds, em que uma métrica precisa ficar abaixo de um valor, e conditions, que combinam métricas numa expressão como http.response_time.p95 < 250 and http.request_rate > 1000. Uma condição marcada com strict: false só avisa, sem reprovar. O plugin apdex acrescenta uma pontuação Apdex aos testes HTTP, com limite padrão de 500 ms (conferido em 19 de outubro de 2026); nosso artigo sobre a pontuação Apdex explica como ler esse número. Para um arquivo de workflow, veja nosso guia de teste de carga no GitHub Actions.

Como escalar um teste do Artillery?

Pela linha de comando, na sua própria conta de nuvem: run-lambda e run-fargate na AWS, run-aci no Azure Container Instances. O Artillery cria os recursos de que a execução precisa e remove os temporários depois.

O guia do Fargate lista os recursos e as permissões de IAM envolvidos. O guia do Lambda informa os limites: um teste não pode passar de 15 minutos, um teste em andamento não pode ser parado, e os hooks before e after rodam uma vez por worker. O guia do Azure exige o Artillery 2.0.19 ou mais novo e, fora de avaliação, uma assinatura (conferido em 19 de outubro de 2026).

A LoadFocus, que publica este site, não roda scripts do Artillery. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem, então para o Artillery os comandos acima são o caminho para escalar.

Quanto custa o Artillery Cloud?

O dashboard é opcional: os resultados só vão para ele quando você roda com --record e uma chave de API. Os planos vão de um nível gratuito a US$ 499 por mês.

A página de preços lista (conferido em 19 de outubro de 2026):

Free: 30 relatórios por mês, 1 mês de retenção, 2 membros, testes distribuídos com até 5 workers e 30 minutos.
Team, US$ 199 por mês: 1.000 relatórios, 6 meses, 8 membros, até 25 workers e 2 horas.
Business, US$ 499 por mês: 2.500 relatórios, 18 meses, sem limite de membros, workers ou duração.

SSO corporativo, logs de auditoria e SLAs de suporte começam em US$ 1.199 por mês, e o faturamento anual economiza 20%.

O que o Artillery faz bem, e onde estão os limites?

Ele é forte em carga por taxa de chegada, scripts curtos e legíveis e testes de navegador com Playwright. É mais fraco quando você precisa de um binário único, de muitos protocolos sem complementos ou de usar o Azure sem licença.

Como ferramenta Node.js, ele pode usar qualquer módulo do npm em funções próprias, ao custo de mais um runtime em cada máquina de teste. Limites que a própria documentação aponta:

Execuções no Lambda param aos 15 minutos e não podem ser canceladas.
Código próprio em TypeScript (config.processor) não roda no Lambda.
gRPC e Kinesis são motores separados.
Uso em produção no Azure exige licença comercial.

Quando escolher k6, JMeter ou Locust em vez do Artillery?

Escolha outra ferramenta quando o runtime, os protocolos ou a linguagem dela combinarem mais com o seu time.

Escolha o k6 quando quiser um binário Go sem Node.js para manter e thresholds no script. Nossa comparação k6 vs Artillery coloca os dois lado a lado. A LoadFocus roda scripts k6 a partir de 25 regiões na nuvem, mas executa cenários arrival-rate com um número fixo de usuários; para manter uma taxa de chegada, rode-os com o próprio k6.

Escolha o JMeter quando precisar de JDBC, JMS, LDAP ou FTP de fábrica, ou quando seus testadores montarem testes numa interface gráfica.

Escolha o Locust quando o seu time escrever Python; nossa análise do Locust trata dele. O panorama de ferramentas de teste de carga open source coloca todas lado a lado.

FAQ

O Artillery é gratuito para uso comercial? A CLI é quase toda MPL-2.0, que permite uso comercial. A exceção é o Azure: uso comercial ou em produção dos módulos do Azure exige licença comercial.

O Artillery roda testes de navegador? Sim. O motor Playwright embutido roda seu código Playwright em navegadores headless e publica Web Vitals de cada página.

A LoadFocus roda scripts do Artillery? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para escalar um teste do Artillery, use run-lambda, run-fargate ou run-aci.

Leituras relacionadas

Azure Load Testing: análise do serviço da Microsoft

Mon, 19 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

O Azure Load Testing é o serviço gerenciado da Microsoft para rodar testes JMeter e Locust em grande escala a partir do Azure, cobrado por hora de usuário virtual. Ele se encaixa bem quando o sistema testado roda no Azure, porque consegue puxar métricas de servidor do Azure Monitor e alcançar endpoints privados dentro de uma rede virtual. Times que escrevem scripts k6, não têm assinatura do Azure ou testam de fora das regiões do Azure vão achar outros serviços mais simples.

Não rodamos o Azure Load Testing para esta análise. Os fatos vêm da documentação e da página de preços da Microsoft, conferidas em 19 de outubro de 2026, e as avaliações são nossas.

Tópico	Azure Load Testing
Tipo	Serviço gerenciado no hub Azure App Testing
Frameworks de teste	Só Apache JMeter e Locust
Opção sem código	Teste rápido por URL, até cinco requisições HTTP
Escala por execução	Até 400 instâncias de engine
Teste mais longo	24 horas
Origem da carga	A região do recurso, ou até 5 regiões
Endpoints privados	Sim, por injeção em rede virtual
Preço	US$ 0,15 por hora de usuário virtual, US$ 0,06 após 10.000
Retenção	6 meses; métricas de cliente 365 dias

O que é o Azure Load Testing?

É um serviço totalmente gerenciado que roda seu teste de carga nas engines de teste da Microsoft, então você nunca monta nem atualiza geradores de carga. Você cria um recurso de teste de carga numa região do Azure, adiciona testes a ele e dispara execuções pelo portal, pela Azure CLI ou por um pipeline.

A página de visão geral diz que a aplicação testada pode estar em qualquer lugar: no Azure, on-premises ou em outra nuvem. A Microsoft agora lista o serviço dentro do hub Azure App Testing, ao lado do Playwright Workspaces; o início rápido de Locust cria o recurso a partir desse hub (conferido em 19 de outubro de 2026).

Quais tipos de teste e ferramentas ele aceita?

Três caminhos: um teste rápido por URL, um script JMeter enviado ou um script Locust enviado. A documentação diz claramente que nenhum outro framework de teste é suportado.

O teste rápido aceita até cinco requisições HTTP e uma meta de usuários virtuais ou de requisições por segundo. Cada engine aguenta até 250 usuários virtuais, então 400 usuários rodam em duas engines com 200 cada.

Com JMeter, você pode usar plugins do jmeter-plugins.org ou enviar os seus, e a visão geral afirma que funciona qualquer protocolo que o JMeter suporta, como uma conexão com banco de dados ou uma fila de mensagens. Com Locust, você pode adicionar plugins do Locust e outras bibliotecas Python. A própria documentação do Locust aponta o serviço como sua opção hospedada, e nossa análise do Locust trata da ferramenta em si. Scripts k6, Gatling e Artillery não rodam aqui (conferido em 19 de outubro de 2026).

Como funcionam engines, usuários virtuais e limites?

Você escala um teste adicionando instâncias de engine. No JMeter, a carga total é o número de usuários do plano de teste multiplicado pelo número de engines; no Locust, você define o total de usuários e escolhe quantas engines os geram.

A página de conceitos traz as duas fórmulas, e a página de limites do serviço define os tetos por região e assinatura (conferido em 19 de outubro de 2026):

Instâncias de engine por execução: de 1 a 400 por padrão conforme a oferta, no máximo 400.
Instâncias de engine simultâneas: de 5 a 400 por padrão, até 1.000 sob pedido.
Duração do teste: de 3 a 24 horas por padrão, no máximo 24 horas.
Critérios de falha: até 50 por teste.
Retenção: métricas de servidor 90 dias, métricas de cliente 365 dias, resultados e logs 6 meses.

Subir um limite padrão exige um chamado ao suporte; nada passa dos máximos indicados.

Ele testa endpoints privados e gera carga de várias regiões?

Sim para as duas coisas, com uma ressalva: elas não se combinam. Carga de várias regiões só funciona contra endpoints públicos.

Por padrão, as engines rodam na região do seu recurso de teste de carga. O guia de várias regiões deixa escolher até 5 regiões por teste e dividir a carga entre elas, e com isso muda o teste para tráfego público. Para serviços sem endpoint público, a injeção em rede virtual coloca as engines dentro da rede onde está a aplicação (conferido em 19 de outubro de 2026).

O que mostram os resultados e as métricas de servidor?

O dashboard mostra ao vivo, durante a execução, as métricas do lado do cliente, como usuários virtuais, tempo de resposta e requisições por segundo. Para apps hospedados no Azure, ele soma métricas do lado do servidor do Azure Monitor, do Application Insights e do Container Insights na mesma linha do tempo.

Essa combinação é a maior vantagem do serviço: você vê o banco de dados ou o contêiner que satura no momento em que os tempos de resposta sobem, sem montar um dashboard separado. O guia de métricas de servidor descreve os passos. Execuções anteriores ficam comparáveis lado a lado, e dá para baixar os resultados para outras ferramentas.

Como funcionam os critérios de aprovação e a CI?

Você define critérios de falha sobre métricas de cliente ou de servidor, e a execução é marcada como falha assim que algum deles é violado. Pipelines no Azure DevOps, no GitHub Actions ou em qualquer ferramenta de CI que consiga chamar a Azure CLI podem iniciar um teste e decidir com base nesse resultado.

Segundo o guia de critérios de falha, um critério é um agregado de uma métrica de cliente, como tempo médio de resposta ou porcentagem de erros, comparado com um limite, seja para o teste inteiro ou para uma requisição nomeada. Métricas de servidor exigem que a identidade gerenciada do recurso possa lê-las. A parada automática encerra uma execução quando a taxa de erros passa de um limite, para que uma URL errada não continue custando. O guia de CI/CD cobre GitHub Actions e Azure Pipelines (conferido em 19 de outubro de 2026). Nosso guia de critérios de aprovação de um teste de carga explica como escolher os limites.

Quanto custa o Azure Load Testing?

Você paga por hora de usuário virtual (VUH): US$ 0,15 por VUH nas primeiras 10.000 e US$ 0,06 por VUH depois disso, igual em todas as regiões da página de preços. Desde 1º de março de 2026 há também uma cobrança mínima por execução.

A página de preços define uma VUH como usuários virtuais vezes minutos, dividido por 60, contado a cada 10 segundos; 1.000 usuários por 30 minutos dão 500 VUH, ou US$ 75 no preço da primeira faixa. O mínimo é de 10 usuários virtuais por engine durante toda a execução, com pelo menos 10 minutos. Uma execução de 3 horas com 5 usuários numa engine é cobrada, portanto, como 30 VUH, e não 15 (conferido em 19 de outubro de 2026).

Quando escolher outra coisa?

Escolha outra opção quando seus scripts, sua nuvem ou seu orçamento apontarem para outro lado.

Nosso panorama de ferramentas de teste de carga open source cobre as ferramentas que você pode rodar por conta própria.

Escolha a LoadFocus, que publica este site, quando quiser rodar planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem sem assinatura do Azure. Ela não roda Locust e executa cenários arrival-rate do k6 com um número fixo de usuários.

Escolha o Grafana Cloud k6 ou o k6-operator quando seus testes forem escritos para o k6, que o Azure Load Testing não roda (conferido em 19 de outubro de 2026).

Escolha o Locust na sua própria infraestrutura quando você já tiver Kubernetes ou máquinas livres: o modo distribuído dele é gratuito, e você paga só o hardware.

FAQ

O Azure Load Testing suporta k6? Não. Ele roda testes Apache JMeter e Locust, além de testes rápidos por URL que ele mesmo transforma em script. Scripts k6 precisam de outro serviço ou da sua própria infraestrutura.

Posso usar o Azure Load Testing com uma aplicação que não está no Azure? Sim. As engines de teste podem mirar qualquer endpoint público. Métricas de servidor só são coletadas para recursos do Azure, então em outra hospedagem você lê as métricas de servidor no seu próprio monitoramento.

Existe um plano gratuito? A página de preços mostra só preços por hora para teste de carga, com um mínimo por execução. Contas novas do Azure ganham um crédito de US$ 200 para os primeiros 30 dias, segundo a mesma página.

Leituras relacionadas

Latência de cauda: o que é e como medir

Mon, 19 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Latência de cauda é o tempo de resposta das poucas requisições mais lentas, normalmente informado como percentil 99 ou 99,9. Ela importa porque uma ação do usuário costuma esperar por muitas requisições, então um atraso que atinge 1 requisição em cada 100 pode chegar à maioria dos seus usuários. Um teste de carga que mostra só a média ou a mediana não revela isso.

Chamadas ao backend por página	Parte das páginas com pelo menos uma chamada lenta (1 em 100)
1	1,0%
5	4,9%
10	9,6%
20	18,2%
50	39,5%
100	63,4%

A tabela supõe que cada chamada é lenta com 1% de chance, de forma independente das outras: a parte é 1 - 0.99^n.

O que conta como cauda?

A cauda é a parte da distribuição de tempos de resposta acima de um percentil alto, quase sempre p99 e p99,9. A mediana descreve uma requisição típica, e a cauda descreve as requisições de que as pessoas reclamam.

Um percentil é um corte: p99 = 800 ms quer dizer que 99% das requisições levaram 800 ms ou menos e 1% levou mais. Num histograma de tempos de resposta, a cauda fica à direita desse corte, muitas vezes como um trecho longo e fino longe do pico principal. Nosso guia de vazão vs latência explica como as ferramentas de teste de carga medem latência e percentis.

Por que a latência de cauda importa tanto?

Porque as requisições se multiplicam. Uma página ou chamada de API que se espalha por muitos serviços só termina quando o mais lento responde, e assim a cauda de cada serviço vira a experiência típica do todo.

A referência é "The Tail at Scale", de Jeffrey Dean e Luiz André Barroso, publicado na Communications of the ACM em 2013 (PDF do artigo, conferido em 19 de outubro de 2026). O exemplo deles: um servidor que costuma responder em 10 ms mas leva um segundo no percentil 99. Se uma requisição toca um servidor desses, 1 em cada 100 requisições de usuário é lenta. Se ela precisa juntar respostas de 100 deles em paralelo, 63% das requisições de usuário levam mais de um segundo. Mesmo com só 1 chamada lenta em 10.000, um serviço com 2.000 servidores vê quase 1 em cada 5 requisições acima de um segundo.

Eles também relatam medições de um serviço real do Google: o percentil 99 de uma única requisição folha era de 10 ms, mas chegava a 140 ms até todas as requisições folha terminarem, e esperar pelos 5% mais lentos respondia por metade disso.

O que causa a latência de cauda?

Na maior parte, interferência de outro trabalho na máquina ou na rede. A mesma requisição é rápida quase sempre e lenta quando outra coisa está acontecendo.

Dean e Barroso listam os suspeitos de sempre:

Recursos compartilhados: outro trabalho na mesma máquina disputando núcleos de CPU, caches do processador, banda de memória ou de rede.
Daemons em segundo plano que acordam e pegam uma fatia da máquina.
Tarefas de manutenção como compactação de logs ou coleta de lixo em ambientes gerenciados.
Filas em servidores e switches de rede, que amplificam todas as outras fontes.
Limites de energia e temperatura que freiam uma CPU depois de um pico de trabalho.

Em testes de carga, a mesma lista aparece como pausas de GC em serviços JVM ou Node.js, pool de conexões esgotado, uma consulta lenta ao banco que só algumas requisições disparam, caches frios depois de um deploy e novas tentativas após um timeout. Uma cauda que cresce com a carga aponta para filas; uma cauda presente mesmo com pouca carga aponta para algo periódico, como GC ou um job agendado.

Como medir a latência de cauda num teste de carga?

Colete amostras suficientes, peça à ferramenta os percentis certos e nunca tire média de percentis entre máquinas ou janelas de tempo.

Amostras suficientes. O p99 é decidido pelo 1% mais lento das requisições, então uma execução com 500 requisições apoia o p99 em 5 delas. Para um p99 estável você precisa de milhares de requisições por transação, e de dezenas de milhares para o p99,9. Testes de fumaça curtos servem para achar erros e pouco para julgar a cauda.

Os percentis certos. Os padrões muitas vezes param antes da cauda. No k6, summaryTrendStats é por padrão avg,min,med,max,p(90),p(95), então o p99 só aparece se você incluir (referência de opções do k6, conferida em 19 de outubro de 2026):

k6 run --summary-trend-stats="med,p(95),p(99),p(99.9),max" \
  script.js

O Aggregate Report do JMeter mostra as linhas de 90%, 95% e 99%, e as propriedades aggregate_rpt_pct1 a aggregate_rpt_pct3 mudam quais percentis aparecem (conferido em 19 de outubro de 2026).

Nada de percentis em média. O p99 de uma execução inteira não é a média dos p99 de cada minuto nem a dos p99 de cada gerador de carga. Junte as amostras brutas ou um histograma e calcule o percentil uma vez só. O artigo sobre coordinated omission trata do HdrHistogram, a ferramenta usual para isso, e de uma segunda armadilha: um gerador de carga que espera as respostas lentas envia menos requisições enquanto o sistema está lento, e esconde justamente a cauda que você procura.

A LoadFocus, que publica este site, mostra em cada execução os blocos P95 e P99, um histograma de tempos de resposta montado a partir das amostras individuais e as requisições mais lentas, então uma cauda longa à direita do pico aparece de relance.

Como definir um limite de aprovação para a cauda?

Coloque um limite no p99 de cada transação importante, ao lado de um limite de p95 e de um limite de taxa de erros. Baseie o limite no que os usuários daquela transação precisam e deixe a execução durar o bastante para o p99 ficar estável.

Um conjunto sensato para uma API de checkout poderia ser: p95 abaixo de 400 ms, p99 abaixo de 1.200 ms e erros abaixo de 0,5%. No k6, são thresholds em http_req_duration como p(99)<1200, e um threshold violado faz o k6 sair com código diferente de zero (thresholds do k6, conferido em 19 de outubro de 2026). A LoadFocus tem um campo Max P99 response time ao lado de Max P95 para testes cloud, JMeter e k6, e cada execução recebe então PASS ou FAIL. Nosso guia de critérios de aprovação de um teste de carga cobre o resto do conjunto.

Se você também reporta uma pontuação Apdex, lembre que ela joga toda requisição acima de quatro vezes T na mesma faixa, então não distingue uma cauda de 2 segundos de uma de 30. O p99 distingue.

Como reduzir a latência de cauda?

Elimine as fontes de variação onde der e desenhe os chamadores para que uma chamada lenta não segure a resposta inteira.

Correções comuns, mais ou menos da mais barata à mais trabalhosa:

Ajuste o GC e o tamanho dos pools para que pausas e a espera por uma conexão livre continuem curtas sob carga.
Deixe folga. As filas crescem de repente perto da saturação, então capacidade sobrando encurta a cauda; o guia de vazão vs latência mostra como achar o joelho.
Defina timeouts e limite as novas tentativas para que uma chamada travada falhe rápido em vez de acumular tudo atrás dela.
Use requisições de cobertura (hedged requests) em leituras idempotentes: envie uma segunda cópia para outra réplica se a primeira não responder a tempo. Dean e Barroso descrevem enviar a cópia só depois da latência esperada do percentil 95, o que limita a carga extra a cerca de 5%. Num dos testes deles, uma cópia enviada após 10 ms derrubou o percentil 99,9 de 1.800 ms para 74 ms com apenas 2% a mais de requisições.
Reduza o fan-out. Menos chamadas ao backend por página significa menos chances de cair na cauda, como mostra a tabela do início.

Depois de cada mudança, rode o mesmo teste com o mesmo perfil de carga e compare p99 e p99,9 entre as execuções.

FAQ

Latência de cauda é a mesma coisa que p99? O p99 é a forma mais comum de informá-la, e a cauda é toda a ponta lenta da distribuição. Acompanhe também o p99,9 e o máximo quando a execução tiver requisições suficientes.

Por que meu p99 é tão maior que a minha média? Porque poucas requisições lentas quase não mexem na média e definem o p99 por inteiro. Uma diferença grande é normal; uma diferença que cresce com a carga costuma indicar filas.

Quantas requisições preciso para medir o p99? No mínimo alguns milhares por transação, para que o p99 se apoie em dezenas de requisições lentas. Para o p99,9, planeje dezenas de milhares.

Leituras relacionadas

Teste de carga gRPC: ferramentas, configuração e métricas

Fri, 16 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Um teste de carga gRPC precisa de uma ferramenta que fale HTTP/2 e Protocol Buffers: k6 e ghz fazem isso de fábrica, o JMeter precisa de um plugin, o suporte a gRPC do Gatling é limitado na edição gratuita e no Locust você mesmo precisa integrar um cliente gRPC. Conte os resultados pelo status gRPC, não pelo status HTTP, porque chamadas com falha continuam chegando como HTTP 200, e confira se a carga chega a todos os backends.

Nenhum teste gRPC foi executado para este artigo. Os fatos sobre ferramentas vêm da documentação e dos repositórios de cada projeto, conferidos em 16 de outubro de 2026; os fatos sobre a LoadFocus vêm do código dela.

Ferramenta	Suporte a gRPC	Lê a API de	Controle da taxa
k6	Embutido (`k6/net/grpc`), chamadas unárias e streams	Arquivos `.proto` ou reflexão do servidor	Executores arrival-rate
ghz	Ferramenta de linha de comando dedicada a gRPC	`.proto`, protoset ou reflexão do servidor	`--rps` e agendas de carga
JMeter	Plugin de terceiros (jmeter-grpc-request)	Uma pasta de arquivos `.proto`	Thread Groups e timers
Gatling	Componente gRPC separado; edição gratuita limitada a 5 usuários, 5 minutos	Código gerado a partir dos `.proto` com protoc	Perfis de injeção
Locust	Sem cliente embutido; envolva um e reporte as chamadas	Seu cliente gRPC em Python	Tempos de espera, `constant_throughput`

Por que o gRPC precisa de um teste de carga diferente do REST?

O gRPC roda sobre HTTP/2, envia Protocol Buffers binários em vez de JSON, coloca o resultado da chamada em um trailer em vez do status HTTP e multiplexa muitas chamadas em uma única conexão. Cada um desses pontos muda como você escreve o teste ou lê os resultados.

O artigo sobre balanceamento de carga no gRPC lista as características do HTTP/2 que importam aqui: um protocolo binário, muitas requisições multiplexadas em uma conexão e compressão de cabeçalhos, com mensagens Protobuf fortemente tipadas por cima (conferido em 16 de outubro de 2026). Uma ferramenta que só envia JSON sobre HTTP/1.1 não consegue chamar um método gRPC, então confira primeiro o suporte ao protocolo.

Qual ferramenta você deve usar?

Use o k6 se quiser cenários, checks e thresholds escritos em código; use o ghz para um benchmark rápido de um método pela linha de comando. Recorra ao JMeter, ao Gatling ou ao Locust quando o seu time já faz todo o resto com eles.

k6. O módulo k6/net/grpc carrega definições Protobuf, conecta, faz chamadas unárias com invoke e abre streams. Ele reporta grpc_req_duration e a contagem de mensagens dos streams nas suas métricas.
ghz. Uma ferramenta de benchmark de linha de comando só para gRPC. As opções incluem --rps, --concurrency, --total e --duration, e se você não passar nem --proto nem --protoset ele tenta a reflexão do servidor. A versão mais recente é v0.121.0 (conferido em 16 de outubro de 2026).
JMeter. O núcleo do JMeter não tem sampler gRPC; o plugin jmeter-grpc-request acrescenta um que lê uma pasta de arquivos .proto, sem geração de código (tag mais recente v1.2.6, conferido em 16 de outubro de 2026).
Gatling. O README do Gatling coloca gRPC, MQTT e GraphQL sob a Gatling Enterprise Component License, limitados na Community Edition a 5 usuários simultâneos e testes de 5 minutos (conferido em 16 de outubro de 2026). O guia de configuração de gRPC gera código a partir dos seus arquivos .proto com protoc.
Locust. A documentação sobre testar outros sistemas inclui um exemplo de gRPC: você envolve um cliente gRPC para que cada chamada seja reportada ao Locust, e constant_throughput limita uma tarefa a um número máximo de execuções por segundo.

Escolha o ghz em vez do k6 quando só precisa saber como um método se comporta a uma taxa dada e não quer escrever script. Escolha o Locust em vez disso quando o seu time escreve em Python e o teste precisa de uma lógica que fica mais fácil lá.

Como escrever um teste de carga gRPC no k6?

Carregue o arquivo .proto no código de inicialização e, em cada iteração, conecte, chame o método e confira o status gRPC. A estrutura segue o exemplo da própria documentação do k6.

import grpc from 'k6/net/grpc';
import { check } from 'k6';

const client = new grpc.Client();
client.load(['protos'], 'hello.proto');

export const options = { vus: 20, duration: '1m' };

export default () => {
  client.connect('grpc.example.com:443');
  const res = client.invoke('hello.Greeter/SayHello', {
    name: 'load test',
  });
  check(res, {
    'status is OK': (r) => r && r.status === grpc.StatusOK,
  });
  client.close();
};

A página do invoke usa a mesma sequência de carregar, conectar, chamar, conferir e fechar. O connect usa TLS a menos que você passe plaintext: true, e com reflect: true ele pede a API ao servidor em vez de ler um arquivo .proto (parâmetros de conexão). Para manter uma taxa de requisições em vez de um número de usuários, rode a função em um cenário arrival-rate.

Como fazer um benchmark rápido com o ghz?

Informe ao ghz o método, um corpo de requisição e uma taxa ou uma concorrência, e ele mostra um histograma de latência, percentis e uma contagem por código de status. Serve para uma primeira olhada em um método.

ghz --insecure --proto ./hello.proto \
  --call hello.Greeter.SayHello \
  -d '{"name":"load test"}' \
  --rps 200 -c 50 -z 1m \
  localhost:50051

--rps define a taxa alvo, dividida entre os workers, -c define quantos workers existem e -z a duração. Tire o --proto para deixar o ghz usar a reflexão do servidor, se o servidor a tiver ativada. A página de saída do ghz mostra um relatório de exemplo.

O que medir em um teste de carga gRPC?

Meça os percentis de latência das chamadas, a vazão e a contagem de cada código de status gRPC. Uma taxa de sucesso no nível HTTP pode marcar 100% enquanto chamadas falham, porque o resultado viaja no trailer grpc-status.

A especificação do gRPC sobre HTTP/2 fixa o status HTTP em :status 200 e leva o resultado da chamada em trailers, como grpc-status e grpc-message. A lista de códigos de status traz os que mais importam sob carga:

DEADLINE_EXCEEDED (4): o prazo expirou antes de a chamada terminar.
RESOURCE_EXHAUSTED (8): uma cota ou um recurso se esgotou.
INTERNAL (13): um invariante interno foi violado, um código reservado para erros graves.
UNAVAILABLE (14): costuma ser passageiro; repetir com backoff pode resolver, mas nem sempre é seguro em chamadas não idempotentes.

Conte cada um por degrau de carga. Os erros de prazo podem subir enquanto as chamadas bem-sucedidas ainda parecem rápidas, porque as lentas são cortadas no prazo em vez de serem registradas como lentas. Nosso guia de critérios de aprovação de um teste de carga mostra como transformar essas contagens em limites de aprovação.

Por que toda a carga cai em um único servidor?

Porque o gRPC multiplexa muitas chamadas em uma conexão de longa duração, um balanceador que trabalha por conexão manda todas as chamadas dela para o mesmo backend. Um gerador de carga com poucas conexões pode então saturar um servidor enquanto os outros ficam parados.

O artigo sobre balanceamento de carga no gRPC explica o mecanismo. Um balanceador no nível de transporte (L3/L4) encerra a conexão TCP e abre outra para um backend escolhido, copiando os frames HTTP/2 e gRPC entre as duas; um balanceador no nível de aplicação (L7) interpreta o HTTP/2 e pode distribuir os streams de uma mesma conexão de cliente entre vários backends. Se os seus clientes de produção passam por um balanceador L7 ou balanceiam do lado do cliente, teste pelo mesmo caminho e acompanhe a CPU e a contagem de requisições de cada backend durante a execução.

Dá para rodar testes de carga gRPC na LoadFocus?

Não de um jeito que os relatórios dela mostrem. A LoadFocus roda a versão padrão do k6 v0.57.0, que inclui o módulo gRPC, mas o agente k6 dela só envia aos resultados as amostras de requisições HTTP, então chamadas gRPC gerariam carga sem aparecer nos gráficos nem nas contagens de erros.

Há mais dois limites. O upload de arquivos do k6 aceita arquivos .js, .ts, .csv, .txt, .json, .env e .properties, não arquivos .proto, então um script teria de se conectar com reflect: true. E o caminho pelo JMeter está fechado: os agentes JMeter da LoadFocus trazem o JMeter 5.6.2 com plugins pré-instalados que não incluem um sampler gRPC, e o upload do JMeter não aceita arquivos JAR de plugin. Para gRPC, rode o k6 ou o ghz nas suas próprias máquinas e use os scripts k6 na LoadFocus para a parte HTTP do mesmo sistema, onde ela gera carga a partir de 25 regiões.

FAQ

Dá para fazer teste de carga de chamadas gRPC em streaming? Sim, com k6 e ghz. O módulo gRPC do k6 tem uma classe Stream com write, end e handlers de eventos, e o ghz tem opções para intervalos e durações de streaming. Meça as mensagens enviadas e recebidas além da latência das chamadas.

É preciso o arquivo .proto para fazer teste de carga de um serviço gRPC? Não se o servidor tiver a reflexão ativada. O k6 pode se conectar com reflect: true, e o ghz recorre à reflexão quando você não passa nem --proto nem --protoset. Sem reflexão, você precisa do arquivo .proto ou de um protoset compilado.

Por que meus erros gRPC não aparecem como requisições com falha? Porque o status HTTP de uma chamada gRPC é 200 mesmo quando a chamada falha. O resultado fica no trailer grpc-status, então confira esse valor no seu script e conte cada código separadamente.

Leituras relacionadas

Vazão vs latência: como se relacionam sob carga

Fri, 16 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

A vazão (throughput) é a quantidade de trabalho que um sistema conclui por unidade de tempo, por exemplo requisições por segundo. A latência é o tempo que uma unidade de trabalho leva, por exemplo 120 milissegundos por requisição. Com pouca carga, uma quase não afeta a outra; quando a carga se aproxima da capacidade do sistema, a vazão para de subir e a latência começa a crescer, e encontrar esse ponto é justamente o objetivo de um teste de carga.

O exemplo abaixo é aritmética, sem nenhum teste por trás. As definições das ferramentas vêm da documentação de cada projeto, conferida em 16 de outubro de 2026.

	Vazão	Latência	Largura de banda
Pergunta que responde	Quanto é concluído por segundo?	Quanto tempo leva uma unidade?	Quanto o link poderia carregar?
Unidade comum	requisições ou transações por segundo	milissegundos	megabits por segundo
No k6	`http_reqs` (contagem e taxa)	`http_req_duration`	não é alvo do teste
No JMeter	Throughput	Elapsed time (e uma "Latency" à parte)	não é alvo do teste

Qual é a diferença entre vazão e latência?

A vazão conta o trabalho concluído ao longo do tempo; a latência mede o tempo que uma unidade de trabalho leva. Um sistema pode ter latência baixa e vazão baixa, ou vazão alta e latência alta, então você precisa dos dois números para descrevê-lo.

O glossário do JMeter calcula a vazão como o número de requisições dividido pelo tempo total, do início da primeira amostra ao fim da última, incluindo os intervalos entre amostras, porque ela deve representar a carga sobre o servidor (conferido em 16 de outubro de 2026). Isso faz da vazão uma propriedade da execução inteira, enquanto a latência pertence a cada requisição e é melhor lida como uma distribuição: mediana, p95, p99.

Largura de banda é a mesma coisa que vazão?

Não. A largura de banda é a quantidade máxima de dados que um link de rede poderia carregar; a vazão é o que de fato passa. Em um teste de carga, vazão costuma significar requisições concluídas, e a largura de banda só importa quando cargas grandes de dados enchem o link antes de a aplicação esgotar a capacidade.

A página de comparação da AWS resume a visão de rede: latência é o atraso na comunicação de rede, vazão é o volume médio de dados que realmente passa em um período e largura de banda é o máximo teórico (conferido em 16 de outubro de 2026). Boa parte do que se encontra na internet usa esse sentido de rede. Testes de carga usam as mesmas palavras para requisições em vez de pacotes, e por isso vale dizer qual dos dois um relatório quer dizer.

O que "latência" significa em uma ferramenta de teste de carga?

Depende da ferramenta. No JMeter, Latency é o tempo até a primeira parte da resposta, e o tempo de resposta completo se chama Elapsed time. No k6, http_req_duration cobre envio, espera e recebimento, e o tempo até o primeiro byte é uma métrica separada.

O glossário do JMeter mede o Elapsed time de logo antes de enviar a requisição até logo depois de receber a última resposta, e a Latency até logo depois de receber a primeira. A referência de métricas do k6 define http_req_duration como http_req_sending + http_req_waiting + http_req_receiving, sem a resolução de DNS e o estabelecimento da conexão, e chama http_req_waiting de tempo até o primeiro byte (ambos conferidos em 16 de outubro de 2026). Então a Latency do JMeter equivale ao http_req_waiting do k6, não ao http_req_duration. Compare uma "latência" do JMeter com uma "duration" do k6 e o número do JMeter vai parecer melhor sem ser.

Como a vazão e a latência mudam quando a carga cresce?

No início, mais carga significa mais vazão, e a latência fica mais ou menos estável. Quando o sistema chega à sua capacidade, a vazão para de crescer e cada usuário a mais só acrescenta espera, então a latência sobe junto com a carga.

Um exemplo, só aritmética. Um serviço atende no máximo 200 requisições por segundo e responde em 0,1 segundo quando não está ocupado. Cada usuário virtual envia uma requisição e depois faz uma pausa de 1 segundo. Com um número fixo de usuários, a forma da lei de Little para o modelo fechado liga as grandezas: usuários = requisições por segundo × (latência + tempo de pensamento), como nosso artigo sobre a lei de Little mostra passo a passo.

Usuários virtuais	Vazão (requisições/s)	Latência (s)
50	45	0,1
150	136	0,1
220	200	0,1
300	200	0,5
400	200	1,0
600	200	2,0

Até 220 usuários, a vazão cresce no mesmo ritmo que eles. Depois ela fica presa em 200, e a latência precisa absorver o resto: 300 usuários precisam de 300 ÷ 200 = 1,5 segundo por volta, o que deixa 0,5 segundo de latência. Sistemas reais costumam se curvar de forma mais gradual, porque filas começam a se formar antes do teto exato. Com um teste de taxa de chegada o cenário é mais duro: se as requisições chegam a mais de 200 por segundo, o acúmulo cresce enquanto durar o excesso, que é a diferença que o artigo sobre o modelo de carga aberto vs fechado explica.

Como encontrar o joelho nos seus próprios resultados?

Aumente a carga em degraus, mantenha cada degrau o bastante para estabilizar e anote a vazão e um percentil de latência de cada um. O joelho é o primeiro degrau em que a vazão para de acompanhar a carga enquanto a latência começa a crescer.

Alguns cuidados deixam essa leitura confiável:

Mantenha cada degrau por alguns minutos, para medir a vazão em um trecho estável e não em uma rampa.
Leia um percentil, não só a média; a média pode continuar calma enquanto a pequena porcentagem de requisições mais lentas fica bem mais lenta.
Confira os erros em cada degrau. Falhas rápidas contam como requisições concluídas com tempos curtos, então um sistema com falhas pode mostrar vazão subindo e latência caindo.
Observe o gerador de carga. Se a CPU dele estiver saturada, o teto que você encontrou pode ser o dele.

O gráfico de tempo de resposta por usuários virtuais da LoadFocus mostra o tempo de resposta médio e máximo em função dos usuários virtuais ativos, um ponto por nível alcançado, e é ali que o joelho aparece em um teste em degraus.

Dá para aumentar a vazão sem aumentar a latência?

Às vezes. Acrescentar capacidade move o teto, então a latência fica plana por mais tempo. Agrupar trabalho (batching) costuma fazer a troca contrária: aumenta a vazão fazendo cada requisição esperar.

O algoritmo de Nagle do TCP é o exemplo clássico dessa troca. A RFC 896 segura novos segmentos enquanto houver dados enviados na conexão ainda sem confirmação, de modo que a rede carrega menos pacotes e mais cheios, e cada escrita pequena pode esperar (conferido em 16 de outubro de 2026). Agrupar requisições e usar buffers de escrita funciona do mesmo jeito: mais trabalho por segundo, mais tempo por item. Quando mudar algo assim, repita o teste em degraus e compare as duas curvas, não um número só.

Qual das duas entra nos seus critérios de aprovação?

As duas, ligadas. Uma meta de latência diz pouco sem a vazão em que foi medida, e uma meta de vazão diz pouco se a latência dobrou para alcançá-la. Escreva as duas como um par, por exemplo p95 abaixo de 300 milissegundos a 200 requisições por segundo com menos de 1% de erros.

Nosso guia de critérios de aprovação de um teste de carga mostra como escrever e automatizar esse par. Se a sua ferramenta espera as respostas lentas antes de enviar a próxima requisição, os números de latência dela podem subestimar o problema; o artigo sobre coordinated omission explica como isso acontece e como evitar. O verbete do glossário da LoadFocus sobre latência explica de onde vem a latência e por que os percentis importam.

FAQ

Latência baixa significa vazão alta? Não necessariamente. Um sistema pode responder rápido a cada requisição mas atender poucas ao mesmo tempo, ou atender muitas ao mesmo tempo enquanto cada uma espera. Você só sabe as duas coisas depois de medir as duas sob a mesma carga, de preferência em vários níveis de carga.

Qual é a diferença entre latência e tempo de resposta? No uso do dia a dia, costumam significar a mesma coisa. No JMeter, Latency é o tempo até a primeira parte da resposta e Elapsed time é o tempo de resposta completo, então confira qual um relatório mostra antes de comparar ferramentas.

Por que a vazão para de aumentar em um teste de carga? Algo chegou ao limite: CPU, um banco de dados, um pool de conexões, um limite de requisições (rate limit) ou o próprio gerador de carga. A partir daí, os usuários a mais só entram na fila, o que aparece como latência subindo com a vazão estável.

Leituras relacionadas

Gatling vs Locust: simulações na JVM ou locustfiles Python?

Tue, 13 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

Gatling e Locust são duas ferramentas open source gratuitas que guardam os testes de carga como código no seu repositório. Escolha o Gatling se o seu time trabalha na JVM ou se quer perfis de injeção abertos e fechados, assertions e um relatório HTML em um só pacote. Escolha o Locust se o seu time escreve Python, gosta de uma interface web para iniciar e acompanhar uma execução e precisa do modo distribuído sem uma edição comercial.

Os dados desta comparação Gatling vs Locust vêm da documentação e do repositório de cada projeto, conferidos em 13 de outubro de 2026.

	Gatling	Locust
Licença	Apache 2.0; gRPC, MQTT e GraphQL sob uma licença de componente separada (repositório)	MIT (repositório)
Ambiente de execução	JVM, OpenJDK LTS 11 a 25 (versão 3.16.0)	Python 3.11 ou superior (versão 2.46.7)
Código de teste	Java, Kotlin, Scala, JavaScript ou TypeScript	Python
Protocolos embutidos	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP e HTTPS; outros por meio de um cliente Python
Modelo de carga	Perfis de injeção abertos ou fechados	Um pool de usuários, ou seja, um modelo fechado
Critérios de aprovação	Assertions, avaliadas depois da execução	Código de saída 1 quando requisições falham, ou o seu próprio listener
Relatórios	Relatório HTML depois de cada execução	Gráficos ao vivo na interface web, arquivos CSV, relatório HTML
Escala	Gatling Enterprise	Modo master e workers embutido, operador do Kubernetes

Qual é a diferença entre Gatling e Locust?

O Gatling executa simulações na JVM e o Locust executa programas Python comuns. O Gatling já traz um modelo de carga e um relatório, e no Locust você escreve a lógica do teste por conta própria.

O README do Gatling descreve um motor não bloqueante construído sobre o Netty e um SDK em cinco linguagens: Java, Kotlin e Scala rodam com Maven, Gradle ou sbt, e JavaScript e TypeScript com um SDK separado. Sua página de instalação pede um OpenJDK LTS de 64 bits da versão 11 à 25 e, para o SDK de JavaScript, Node.js 24 ou superior.

O README do Locust o apresenta como uma forma de escrever testes de carga escaláveis em Python puro, e os metadados do pacote exigem Python 3.11 ou superior. A página What is Locust diz que ele é baseado em eventos com gevent, de modo que um único processo consegue lidar com muitos milhares de usuários simultâneos (conferido em 13 de outubro de 2026).

Como escrever o mesmo teste em cada ferramenta?

No Gatling você encadeia requisições em um cenário e dá a ele um perfil de injeção. No Locust você escreve uma classe de usuário com tarefas e um tempo de espera entre elas.

Cinquenta usuários simultâneos que listam usuários e depois esperam de um a três segundos, por cinco minutos. No SDK Java do Gatling (imports omitidos):

public class ApiSimulation extends Simulation {
  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1, 3);

  {
    setUp(users.injectClosed(
        constantConcurrentUsers(50).during(300)))
      .protocols(api);
  }
}

O mesmo teste no Locust:

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def list_users(self):
        self.client.get("/api/users")

A referência de injeção do Gatling lista constantConcurrentUsers entre os passos do modelo fechado. O Locust recebe o número de usuários e a duração como flags (conferido em 13 de outubro de 2026):

locust -f locustfile.py --headless -u 50 -r 5 -t 5m \
  --host https://staging.example.com

Como Gatling e Locust modelam a carga?

O Gatling oferece modelos abertos e fechados, conforme o método que você chama. O Locust executa um pool de usuários, o que equivale a um modelo fechado.

A página de modelos de carga do Gatling define sistemas fechados como aqueles que limitam os usuários simultâneos e sistemas abertos como aqueles em que os usuários continuam chegando mesmo que a aplicação responda devagar. Ela acrescenta que a maioria dos sites é aberta. injectOpen recebe taxas de chegada e injectClosed recebe metas de concorrência.

O guia do locustfile diz que o tempo de espera só pode limitar a vazão e não inicia novos usuários para atingir uma taxa-alvo. Se uma volta demora mais do que a espera permite, a taxa fica abaixo da meta (conferido em 13 de outubro de 2026). Nosso guia sobre o modelo de carga aberto vs fechado explica por que isso importa.

Como rodar um teste maior do que uma máquina consegue gerar?

O Locust traz o modo distribuído embutido. A edição open source do Gatling gera carga a partir de uma única máquina, e execuções distribuídas exigem o Gatling Enterprise.

O Locust inicia um processo com --master e quantos processos --worker você quiser. Segundo a documentação de carga distribuída, um processo Python não usa mais de um núcleo, então roda-se um worker por núcleo, e --processes inicia vários em uma máquina. Um operador do Kubernetes gerencia execuções distribuídas dentro de um cluster.

O FAQ do Gatling diz que a Community Edition não suporta testes distribuídos, e o README descreve o Enterprise como rodando em geradores de carga gerenciados ou em infraestrutura privada (conferido em 13 de outubro de 2026).

Há uma saída para os dois casos. A LoadFocus, que publica este site, não roda simulações do Gatling nem testes do Locust. Se você prefere não rodar nenhum dos dois em grande escala, ela executa scripts k6 e planos de teste JMeter a partir de 25 regiões na nuvem. O validador de k6 dela avisa que cenários de taxa de chegada rodam ali com um número fixo de usuários e, por isso, não mantêm uma taxa de requisições. Migrar de qualquer uma das duas ferramentas significa reescrever o teste.

Como decidem se um teste passou, e que relatórios você recebe?

O Gatling avalia as assertions depois da execução e escreve um relatório HTML todas as vezes. O Locust termina com o código 1 se alguma requisição falhou, e outras verificações você acrescenta como listener.

As assertions do Gatling são avaliadas depois da simulação, e uma única assertion que falha faz a simulação falhar. O relatório HTML traz percentis do tempo de resposta, usuários iniciados por segundo, usuários simultâneos e requisições por segundo.

De acordo com a documentação headless do Locust, a execução termina com o código 1 se alguma amostra falhou, e um exemplo de listener faz a execução falhar pela taxa de falhas, pelo tempo de resposta médio ou pelo percentil 95. A referência de configuração cita --csv para arquivos de estatísticas e --html para um relatório (conferido em 13 de outubro de 2026).

Quais protocolos cada ferramenta consegue testar?

O Gatling traz mais protocolos, com limites nos mais novos. O Locust traz HTTP e HTTPS e espera um cliente Python para o resto.

O README do Gatling lista HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events e JMS sob Apache 2.0, sem limites. gRPC, MQTT e GraphQL ficam sob a Gatling Enterprise Component License, e testes com eles são limitados a 5 usuários simultâneos e 5 minutos na Community Edition.

A página sobre outros sistemas do Locust mostra como envolver uma biblioteca de protocolo e reportar cada chamada, com exemplos de gRPC e MQTT. A biblioteca precisa funcionar com o gevent, que não consegue aplicar patch em E/S feita em código C compilado, e o locust-plugins acrescenta usuários para Kafka, Selenium e Playwright (conferido em 13 de outubro de 2026).

Qual você deve escolher?

Escolha pela linguagem e pela forma de carregar o sistema. O Gatling combina com times JVM e testes em modelo aberto, e o Locust com times Python e testes com lógica própria.

Escolha o Gatling em vez do Locust se o seu time vive na JVM e quer testes em Java, Kotlin ou Scala construídos com Maven, Gradle ou sbt, se você precisa de um modelo aberto, como uma taxa de chegada fixa, se precisa de JMS ou Server-Sent Events, ou se quer assertions e um relatório sem código extra.

Escolha o Locust em vez do Gatling se o seu time escreve Python e quer que os testes reutilizem um cliente Python interno, se quer uma interface web para iniciar uma execução e mudar a carga enquanto ela roda, se precisa do modo distribuído na ferramenta gratuita, ou se o sistema recebe principalmente usuários que esperam e o seu protocolo tem uma biblioteca Python compatível com o gevent.

Para um construtor de testes com interface gráfica, olhe o JMeter, e para um único binário sem JVM nem Python, olhe o k6.

FAQ

O Gatling é mais rápido que o Locust? Não medimos isso por conta própria, então não vamos apontar um vencedor. A comparação justa é rodar o mesmo cenário com as duas ferramentas no seu próprio hardware.

O Locust consegue rodar simulações do Gatling? Não segundo a documentação do Locust, que descreve os testes apenas como código Python. Uma simulação do Gatling precisa ser reescrita como locustfile, e o inverso também vale.

A LoadFocus consegue rodar testes do Gatling ou do Locust? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para distribuir uma simulação do Gatling entre várias máquinas, use o Gatling Enterprise, e para o Locust use o modo master e workers ou o operador do Kubernetes.

Leituras relacionadas

JMeter vs Postman: qual ferramenta para teste de carga?

Tue, 13 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

O Postman é um cliente de API feito para verificações funcionais, coleções e trabalho em equipe, que ganhou depois um modo de teste de desempenho. O Apache JMeter é um gerador de carga desde o início. Use o Postman quando quiser reaproveitar a coleção que você já tem para um teste de carga rápido ou um smoke test na CI. Use o JMeter quando o teste de carga é o trabalho principal: muitos protocolos, grandes números de usuários, relatórios detalhados e geração de carga distribuída.

Os fatos sobre o Postman vêm da documentação e da página de preços dele, e os do JMeter vêm do site do próprio projeto, todos verificados em 13 de outubro de 2026.

	Postman	Apache JMeter
Finalidade principal	Cliente de API, testes funcionais e de coleções, com modo de desempenho	Testes de carga e de desempenho
Definição do teste	Uma coleção de requisições com scripts e asserções `pm.test()`	Um plano de teste montado numa GUI e salvo como arquivo `.jmx`
Usuários virtuais	Cada um executa a coleção em loop; as execuções locais são limitadas pela sua máquina	Uma thread Java por usuário num Thread Group
Perfis de carga	Fixed, Ramp up, Spike e Peak	Thread Groups com período de rampa
De onde vem a carga	Sua máquina ou um runner de CI, ou a nuvem do Postman em planos pagos	Sua máquina, ou servidores JMeter remotos que você mantém
Custo da carga	Execuções locais em todos os planos; execuções na nuvem a US$ 0,04 por hora de usuário virtual	Gratuito, licença Apache 2.0
Aprovado ou reprovado na CI	`postman performance run` com `--pass-if`	Modo CLI (`jmeter -n`)

O que o teste de desempenho do Postman faz?

Ele executa as requisições de uma coleção com vários usuários virtuais em paralelo, por um número definido de minutos. Cada usuário repete as requisições em ordem, e seus scripts e asserções atuais rodam sob carga.

Segundo a documentação de testes de desempenho, a coleção dos seus testes funcionais também é o seu teste de carga, sem script nem linguagem separados para manter (verificado em 13 de outubro de 2026). Você escolhe uma duração e um número de usuários virtuais, depois um perfil Fixed, Ramp up, Spike ou Peak, como descreve a página de configuração.

Quais são os limites do Postman para teste de carga?

O principal limite é de onde vem a carga. Uma execução local fica limitada pela máquina que a executa, e o que passar disso exige um plano pago.

Para execuções locais, a documentação do Postman diz que o número de usuários virtuais depende dos recursos do sistema e da coleção usada, que scripts de pre-request e post-response reduzem quantos usuários dá para simular e que a execução para se a máquina passar do limite de recursos. Ela sugere um primeiro teste com 10 a 20 usuários virtuais (verificado em 13 de outubro de 2026). Acima disso, o próprio gerador de carga pode distorcer suas medidas, e por isso o Postman também mostra os picos de CPU e memória da máquina de teste.

Os dados são o próximo limite. Segundo a mesma página de configuração, arquivos de dados CSV e JSON funcionam só em execuções locais, enquanto datasets funcionam em execuções locais e na nuvem.

Quanto custa fazer teste de carga com o Postman?

As execuções de desempenho locais estão incluídas em todos os planos. As execuções na nuvem são para planos pagos e cobradas por uso, em horas de usuário virtual.

A página de preços do Postman lista testes de desempenho locais ilimitados e testes de desempenho na nuvem a US$ 0,04 por hora de usuário virtual (verificado em 13 de outubro de 2026). Nessa tarifa listada, 500 usuários virtuais por uma hora são 500 horas de usuário virtual, ou US$ 20, além da mensalidade do plano. Endereços IP estáticos para alcançar alvos atrás de um firewall são um recurso do Enterprise. Não levantamos os preços dos planos em si: veja a página para os valores atuais por usuário.

Quais protocolos dá para testar?

O JMeter tem uma lista longa e documentada. Para o Postman, não encontramos uma lista de protocolos aceitos nas execuções de desempenho, então não afirmamos nada sobre isso.

A página inicial do JMeter cita HTTP e HTTPS, SOAP e REST, FTP, bancos de dados via JDBC, LDAP, mensageria JMS, e-mail SMTP, POP3 e IMAP, comandos nativos e scripts de shell, TCP e objetos Java (verificado em 13 de outubro de 2026). O Postman lida no aplicativo com outros tipos de requisição, como GraphQL, gRPC e WebSocket, mas isso não diz quais rodam sob carga. Teste um antes de depender dele.

Como escalar além de uma máquina?

O Postman escala pela nuvem dele, o JMeter por servidores que você mesmo mantém. O primeiro é mais fácil de começar, o segundo dá controle.

Num plano pago, as execuções na nuvem do Postman dividem a carga entre workers gerenciados, e uma única máquina deixa de limitar o teste. O modo de teste remoto do JMeter deixa um cliente controlar muitos servidores JMeter. Cada nó precisa da mesma versão do JMeter, de um keystore para RMI sobre SSL, a menos que você o desative, e de uma cópia própria dos arquivos de dados (verificado em 13 de outubro de 2026).

Existe um terceiro caminho para planos de teste JMeter. A LoadFocus, que publica este site, roda planos de teste JMeter existentes a partir de 25 regiões na nuvem. Você envia o arquivo .jmx e define usuários virtuais, duração e rampa, sem servidores remotos para configurar. A LoadFocus roda apenas JMeter e k6, então não roda uma coleção do Postman.

Qual ferramenta escolher?

Escolha o Postman em vez do JMeter para verificações funcionais e de contrato, para uma equipe que compartilha coleções num workspace e para uma execução rápida de fumaça de uma API que você já testa. Escolha o JMeter quando o teste de carga é o objetivo principal, ou quando você precisa de vários protocolos, muitos usuários ou testes que ficam no seu próprio repositório.

O Postman serve para uma verificação curta na CI: postman performance run termina com código de saída diferente de zero quando um limite como o percentil 95 não é atingido, e isso faz o build falhar. O JMeter é melhor para carga em bancos de dados ou mensageria, para testes de longa duração e para o painel HTML com tabelas APDEX e de percentis que a documentação dele descreve.

Muitas equipes usam os dois: o Postman para montar e verificar as checagens da API, o JMeter para dar volume real aos fluxos críticos.

FAQ

O Postman pode substituir o JMeter em teste de carga? Para verificações pequenas de APIs HTTP, sim, porque a coleção que você já tem é o teste. Com alta concorrência, outros protocolos ou execuções longas, os limites documentados das execuções locais e o preço por uso das execuções na nuvem fazem do JMeter a base mais segura.

O Postman consegue rodar um arquivo .jmx do JMeter? Não encontramos na documentação nada que importe um plano de teste JMeter. Os testes de desempenho do Postman são feitos a partir de coleções, então um arquivo .jmx teria de ser refeito.

O JMeter é gratuito? Sim. A versão atual na página de download é a 5.6.3, que exige Java 8 ou mais recente (verificado em 13 de outubro de 2026). Você paga pelas máquinas que geram a carga, ou por um serviço na nuvem que rode seus planos.

k6 vs Locust: scripts JavaScript ou usuários Python?

Tue, 13 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

k6 e Locust são duas ferramentas de código aberto que mantêm um teste de carga como código no seu repositório, e qualquer uma delas testa bem uma API HTTP sob carga. Escolha o Locust se sua equipe escreve Python e quer a lógica do teste em Python puro. Escolha o k6 se você escreve JavaScript, quer thresholds de aprovação embutidos ou precisa de um teste que mantenha uma taxa de chegada.

Os fatos desta comparação entre k6 e Locust vêm da documentação e do repositório de cada projeto, conferidos em 13 de outubro de 2026.

	k6	Locust
Licença	AGPL-3.0 (repositório)	MIT (repositório)
Execução	Um binário Go com um motor JavaScript embutido (versão v2.3.0)	Python 3.11 ou mais recente (versão 2.46.7)
Scripts de teste	JavaScript, ou TypeScript sem os tipos	Classes Python em um locustfile
Protocolos embutidos	HTTP/1.1, HTTP/2, WebSockets, gRPC	HTTP e HTTPS
Modelo de carga	Seis executors, dois deles arrival-rate (modelo aberto)	Um grupo de usuários que esperam cada um um tempo (modelo fechado)
Aprovação ou falha	Thresholds, que podem interromper uma execução mais cedo	Código de saída 1 se requisições falharem; outros limites via listener
Testes de navegador	Módulo de navegador embutido	Usuários de navegador pelo projeto separado locust-plugins
Escala	k6-operator no Kubernetes, ou Grafana Cloud k6	Master e workers, um operador Kubernetes ou Azure Load Testing

Qual é a diferença entre k6 e Locust?

A principal diferença é a linguagem em que você escreve os testes. O k6 executa JavaScript dentro de um programa Go compilado, enquanto o Locust executa seu código Python e usa o gevent para muitos usuários simultâneos.

O k6 é instalado como pacote ou binário independente, sem outro ambiente de execução. Ele também executa arquivos .ts, mas seu suporte a TypeScript remove os tipos sem verificá-los. O Locust é instalado com pip install locust, e a página What is Locust diz que os testes são Python comum, que você mantém em controle de versão como qualquer outro código (conferido em 13 de outubro de 2026).

Como escrever o mesmo teste em cada ferramenta?

Ambas expressam o teste como um programa curto. Aqui vai um teste com 50 usuários por cinco minutos, que falha se o percentil 95 passar de 500 ms ou se mais de 1% das requisições falharem.

No k6 os objetivos fazem parte do script, como thresholds:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  vus: 50,
  duration: "5m",
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
  sleep(1);
}

No Locust o usuário é uma classe, e os mesmos objetivos vão em um listener, seguindo o padrão da documentação do modo headless:

import logging
from locust import HttpUser, between, events, task


class ApiUser(HttpUser):
    wait_time = between(1, 2)

    @task
    def list_users(self):
        self.client.get("/api/users")


@events.quitting.add_listener
def _(environment, **kw):
    stats = environment.stats.total
    if stats.fail_ratio > 0.01:
        environment.process_exit_code = 1
    elif stats.get_response_time_percentile(0.95) > 500:
        environment.process_exit_code = 1

Eles são executados com k6 run script.js e locust -f locustfile.py --headless -u 50 -r 10 -t 5m --host https://staging.example.com (conferido em 13 de outubro de 2026).

Como k6 e Locust modelam a carga?

O k6 aceita os dois modelos de carga, enquanto o Locust descreve a carga como um número fixo de usuários. No k6 você escolhe o modelo pelo executor, e no Locust pelo número de usuários e pelo tempo de espera.

O k6 tem seis executors. Quatro são fechados: um usuário virtual só começa a próxima iteração quando a anterior termina. Os dois executors arrival-rate seguem o modelo aberto, em que as iterações começam independentemente de quanto as anteriores demoram. O guia do locustfile diz que o tempo de espera só pode limitar a vazão e não pode iniciar novos usuários para atingir uma taxa-alvo (conferido em 13 de outubro de 2026).

Se o seu objetivo é "300 requisições chegam a cada segundo, não importa o tempo de resposta", o k6 consegue expressar isso diretamente. Nosso guia sobre o modelo de carga aberto e fechado explica quando cada um se encaixa.

Como k6 e Locust decidem se um teste passou?

O k6 tem critérios de aprovação como recurso central, e o Locust deixa a maior parte para o seu código. Um threshold do k6 violado encerra a execução com código de saída diferente de zero, e abortOnFail interrompe o teste no instante em que ele falha.

O Locust encerra com código 1 se alguma requisição falhou. Para limites sobre a taxa de falhas, a média ou o percentil 95, a documentação mostra um listener como o de cima, que define o código de saída por conta própria (conferido em 13 de outubro de 2026). Nosso guia sobre critérios de aprovação em testes de carga ajuda a escolher os limites.

Quais protocolos cada ferramenta cobre?

O k6 traz quatro protocolos e um módulo de navegador; o Locust traz HTTP e HTTPS e deixa você envolver qualquer cliente Python para o resto.

O k6 lista HTTP/1.1, HTTP/2, WebSockets e gRPC como protocolos embutidos, com outros por extensões xk6, e um módulo de navegador que controla um navegador baseado em Chromium. A página do Locust sobre outros sistemas diz que ele só traz suporte embutido a HTTP/HTTPS, mas pode ser estendido para testar quase qualquer sistema, envolvendo uma biblioteca de protocolo e relatando cada chamada como uma requisição. A biblioteca precisa cooperar com o gevent (conferido em 13 de outubro de 2026).

Como rodar um teste maior do que uma máquina consegue gerar?

O Locust escala com um master e workers, e o k6 com um operador Kubernetes ou um serviço hospedado. Os dois conseguem dividir um teste entre muitas máquinas.

A documentação do modo distribuído do Locust diz que um processo faz mais de mil requisições por segundo em um plano de teste simples, então testes maiores usam um worker por núcleo de processador em quantas máquinas forem necessárias. O k6-operator divide um teste entre várias instâncias do k6 em um cluster Kubernetes, e o Grafana Cloud k6 é o caminho hospedado (conferido em 13 de outubro de 2026).

Há um terceiro caminho para scripts k6. A LoadFocus, que publica este site, executa scripts k6 a partir de 25 regiões na nuvem, com usuários e duração vindos das configurações do teste. O validador de scripts avisa que cenários arrival-rate rodam lá com um número fixo de usuários, então um script de modelo aberto não mantém sua taxa de chegada na LoadFocus. A LoadFocus não executa Locust: ela executa apenas scripts k6 e planos de teste JMeter.

Que relatórios você recebe?

O k6 imprime um resumo ao fim do teste e pode exportar um relatório HTML do seu painel web. O Locust mostra gráficos ao vivo na interface web e grava arquivos sob demanda.

O resumo de fim de teste do k6 vai para o terminal, e seu painel web exporta um relatório HTML autônomo quando você define K6_WEB_DASHBOARD_EXPORT. O Locust serve uma interface web na porta 8089 com gráficos ao vivo, e sua referência de configuração lista as saídas --csv, --html e --json (conferido em 13 de outubro de 2026).

Qual você deve escolher?

O Locust combina com equipes Python, e o k6 com equipes que querem thresholds embutidos e um modelo de carga aberto. Protocolos e escala decidem a maioria dos outros casos.

Escolha o Locust em vez do k6 se sua equipe escreve Python e quer laços, ramificações, dados gerados e seu próprio cliente de API em Python puro, se você quer reaproveitar bibliotecas Python para um protocolo, ou se quer uma interface web com gráficos ao vivo para explorar um sistema. Escolha o k6 em vez do Locust se sua equipe escreve JavaScript ou TypeScript, se thresholds devem reprovar um build de CI e parar cedo uma execução ruim, se você precisa de uma taxa de chegada constante, ou se quer gRPC e testes de navegador na mesma ferramenta.

Para uma visão mais ampla, veja nossa análise de teste de carga com Locust.

FAQ

O Locust é mais rápido que o k6? Não medimos isso nós mesmos, então não apontamos um vencedor. O teste justo é o mesmo cenário nas duas ferramentas, no seu próprio hardware.

O Locust consegue executar scripts k6? Não segundo a documentação do Locust, que descreve testes como código Python em um locustfile. Um script k6 é JavaScript, então precisa ser reescrito como uma classe de usuário Python, e os thresholds viram um listener.

A LoadFocus consegue executar testes Locust? Não. A LoadFocus executa scripts k6 e planos de teste JMeter. Para escalar um teste Locust, use o modo master e workers, o operador Kubernetes ou o Azure Load Testing.

Leituras relacionadas

Coordinated omission: o que é e como evitar

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

A coordinated omission é um erro de medição: um gerador de carga espera cada resposta lenta antes de enviar a próxima requisição, então envia menos justamente quando o sistema está lento e registra poucos dos piores momentos. Os percentis que você lê depois parecem melhores do que aquilo que os usuários viveram. Você evita o erro enviando as requisições num cronograma que ignora os tempos de resposta e medindo cada requisição a partir do momento em que ela deveria ter saído.

Os fatos sobre as ferramentas vêm da documentação ou do repositório de cada projeto, conferidos em 9 de outubro de 2026.

Ferramenta	O que oferece	O que conferir
wrk2	Uma taxa constante (`-R`), latência medida desde o envio previsto	`--u_latency` mostra também a visão sem correção
HdrHistogram	Dois métodos que preenchem as amostras que faltam	Aplicar só um deles, nunca os dois
k6	Os executors de taxa de chegada	O contador `dropped_iterations`
Gatling	Passos de `injectOpen` como `constantUsersPerSec`	Os passos ficam dentro de `injectOpen`
Locust	`constant_throughput` dá o ritmo de cada usuário	A taxa atingida em relação à meta
JMeter	Open Model Thread Group (5.5 ou posterior, experimental)	Um Thread Group comum é um pool fechado

O que é coordinated omission?

É o erro que aparece quando o lado que mede para de coletar amostras porque o sistema está lento, de modo que as amostras que faltam são justamente as lentas. Perder amostras ao acaso quase não mexe num percentil; perdê-las no compasso de uma lentidão distorce todos eles.

O nome vem de Gil Tene, cuja mensagem de 2013 numa lista de discussão traça essa mesma linha. Ele é o autor original do HdrHistogram, o wrk2 está na conta dele no GitHub, e a documentação dos dois projetos explica o efeito (conferido em 9 de outubro de 2026). A documentação do k6 usa o termo para um modelo de carga fechado que freia a própria carga, uma causa frequente. Nosso artigo sobre o modelo de carga aberto vs fechado trata dessa escolha; este fica com a medição.

Como um teste de carga acaba escondendo as respostas lentas?

Um gerador em loop fechado só envia a próxima requisição numa conexão depois que a resposta anterior chega. Se uma resposta leva um segundo, essa conexão não envia nada por um segundo, e as requisições que ela teria enviado nunca recebem um tempo de resposta.

O README do wrk2 diz isso sobre o modelo do wrk, que mede cada requisição do primeiro byte enviado até a resposta completa: como uma conexão só envia depois de uma resposta, o gerador se coordena com o servidor e deixa de medir nos períodos de alta latência (conferido em 9 de outubro de 2026).

O README do HdrHistogram propõe um experimento mental. Um sistema amostrado a cada 10 ms responde em 1 ms por 100 segundos e depois trava por 100 segundos, o que gera uma única amostra de 100 segundos. O histograma bruto põe cerca de 99,99% dos resultados em 1 ms ou menos; corrigido pelas amostras bloqueadas, só cerca da metade fica ali.

Como saber se os seus resultados têm coordinated omission?

Compare a taxa enviada com a planejada. Se a taxa de requisições caiu enquanto os tempos de resposta subiam, o gerador recuou e o período lento ficou sub-representado.

A carga foi definida em usuários ou conexões, sem taxa. Qualquer loop fechado pode causar o erro.
A taxa de requisições cai onde os tempos de resposta sobem. Uma queda na taxa durante um pico significa que houve requisições que nunca saíram.
O máximo é muito maior que o percentil 99. Algumas amostras enormes entre milhares de rápidas são o exemplo acima em miniatura. Leia toda a distribuição dos tempos de resposta, lembrando que ela só conta requisições enviadas.
Faltou CPU ao gerador de carga. A LoadFocus documenta que um motor perto de 100% de CPU não consegue enviar na taxa configurada, e os resultados mostram um aviso de saturação do gerador de carga quando algum motor atingiu ou passou de 80% de CPU no pico.

Como o wrk2 evita a coordinated omission?

Ele envia a uma taxa constante e mede cada requisição a partir do momento em que o plano dizia que ela deveria sair. Uma requisição que sai atrasada porque a conexão estava ocupada carrega a espera.

O wrk2 acrescenta ao wrk um argumento de taxa (-R, requisições por segundo no total) e registra as latências num HdrHistogram. --u_latency acrescenta ao relatório o histograma sem correção, marcado como CO, como no exemplo do próprio README:

wrk -t2 -c100 -d30s -R2000 --u_latency http://127.0.0.1:80/index.html

No segundo exemplo do README, uma pausa de 1,4 segundo no servidor durante um teste de 30 segundos deixou o percentil 99 corrigido 200 vezes maior que o sem correção. O README também chama o projeto de experimental e avisa que testes com menos de 10 a 20 segundos podem não ser úteis (conferido em 9 de outubro de 2026). Nossa análise de ferramentas de benchmark HTTP compara o wrk2 com hey, oha e outras.

Como o HdrHistogram corrige as latências registradas?

Se você sabe o intervalo em que as requisições deveriam sair, ele acrescenta as amostras que uma resposta longa bloqueou. A correção pode ser feita durante a gravação ou depois, numa cópia.

recordValueWithExpectedInterval registra um valor e, quando ele passa do intervalo, acrescenta valores que descem em passos desse intervalo. copyCorrectedForCoordinatedOmission devolve uma cópia corrigida de um histograma pronto. O JavaDoc descreve os dois métodos como mutuamente exclusivos (conferido em 9 de outubro de 2026).

// intervalo planejado: 10 ms, valores em microssegundos
Histogram h = new Histogram(3);
h.recordValueWithExpectedInterval(latencyUs, 10_000);

// ou, depois do teste, num histograma bruto:
Histogram fixed = raw.copyCorrectedForCoordinatedOmission(10_000);

A correção só é tão boa quanto o intervalo que você passa. Ela serve, portanto, para um gerador que deveria enviar num ritmo constante.

Como k6, Gatling, Locust e JMeter lidam com isso?

k6, Gatling e JMeter podem iniciar trabalho num cronograma que não espera respostas. O Locust dá o ritmo de cada usuário, mas não consegue iniciar usuários extras para manter uma taxa.

k6. Nos executors de taxa de chegada, as iterações começam independentemente da resposta do sistema enquanto houver um usuário virtual livre. Quando não há, o k6 pula a iteração e a conta em dropped_iterations, o que, já perto do fim de um teste, pode indicar que o sistema está se degradando (conferido em 9 de outubro de 2026). Uma iteração descartada não tem tempo de resposta, então leia esse contador ao lado dos percentis. Na LoadFocus, os cenários de taxa de chegada dos scripts k6 rodam com um número fixo de usuários, ou seja, como modelo fechado. Rode o k6 por conta própria quando a taxa de chegada for o objetivo do teste.

Gatling. Passos como constantUsersPerSec dentro de injectOpen iniciam novos usuários virtuais a uma taxa fixa, tenham os anteriores terminado ou não (conferido em 9 de outubro de 2026).

Locust. constant_throughput ajusta a espera de cada usuário para que ele execute uma tarefa no máximo um certo número de vezes por segundo. A documentação diz que o tempo de espera só consegue limitar a taxa e não inicia novos usuários, e a referência da API acrescenta que uma tarefa que passa do intervalo não é seguida de espera. Uma resposta lenta atrasa esse usuário mesmo assim (conferido em 9 de outubro de 2026).

JMeter. Um Thread Group é um pool de threads que repetem o plano em loop, ou seja, um loop fechado. O JMeter 5.5 trouxe o Open Model Thread Group, experimental, que segue um cronograma como rate(1/sec) random_arrivals(2 min) e, segundo as notas de versão, cria threads conforme a necessidade (conferido em 9 de outubro de 2026).

Um modelo de carga aberto elimina a coordinated omission?

Ele elimina a causa principal, um gerador que espera antes de enviar. Ficam duas brechas: um gerador sem usuários ou CPU suficientes ainda fica para trás no cronograma, e cada usuário de uma jornada com várias etapas continua esperando as próprias respostas.

A primeira aparece como iterações descartadas ou como um motor saturado; nos dois casos, repita o teste com mais folga. A segunda vem com a maioria dos testes HTTP: o README do wrk2 observa que enviar sem esperar só funciona com protocolos não bloqueantes ou com uma requisição por conexão, e por isso o wrk2 corrige a medição do tempo.

FAQ

Quem deu nome à coordinated omission? Gil Tene, o autor original do HdrHistogram, cujo fork wrk2 do wrk foi pensado para evitá-la. A mensagem dele de 2013 na lista de discussão mechanical-sympathy a descreve como um problema que ele chama por esse nome.

Coordinated omission é a mesma coisa que um modelo de carga fechado? Os dois estão ligados. Um modelo fechado é uma causa frequente, porque cada usuário virtual espera a resposta antes de enviar de novo, e o README do wrk2 também encontra o efeito em código de monitoramento.

É preciso corrigir todo histograma de latência? Só quando você conhece o intervalo em que as requisições estavam planejadas, porque o HdrHistogram precisa dele para preencher as amostras que faltam. Aplique a um conjunto de dados um dos dois métodos de correção, nunca os dois.

Leituras relacionadas

Teste de carga com Gatling: análise da ferramenta JVM

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

O Gatling é uma ferramenta gratuita de teste de carga sob licença Apache 2.0, em que cada teste é uma simulação escrita como código, executada na JVM e seguida de um relatório HTML. O teste de carga com Gatling combina com equipes de desenvolvimento que querem os testes no repositório, modelos de carga abertos ou fechados e asserções que façam o build falhar. Quem quer um editor gráfico de testes ou muitos protocolos fica mais bem servido pelo JMeter, e quem quer um único binário sem JVM, pelo k6.

Não rodamos o Gatling para esta análise. Os fatos vêm da documentação, do repositório e das páginas de versões do Gatling, conferidos em 9 de outubro de 2026, e as avaliações são nossas.

Tema	Gatling
Licença	Apache 2.0, exceto os plugins de gRPC, MQTT e GraphQL
Ambiente	JVM, OpenJDK LTS de 64 bits do 11 ao 25
Versão atual	3.16.0 (29 de setembro de 2026)
Testes escritos em	Java, Kotlin, Scala, JavaScript, TypeScript
Protocolos embutidos	HTTP/1.1, HTTP/2, WebSocket, SSE, JMS
Resultados	Relatório HTML estático por execução
Build e CI	Plugins para Maven, Gradle, sbt e npm
Escala	Gatling Enterprise (comercial)

Quem desenvolve o Gatling, e ele ainda é mantido?

A Gatling Corp, uma empresa francesa, desenvolve o Gatling e detém seus direitos autorais. O projeto é mantido ativamente, com três versões para a JVM até agora em 2026.

A página de licenças atribui os direitos autorais à Gatling Corp. O Maven Central lista a 3.15.0 em fevereiro, a 3.15.1 em maio e a 3.16.0 em 29 de setembro de 2026, e o SDK de JavaScript chegou à 3.16.1 em 6 de outubro. As notas da versão 3.16 trazem GraphQL e filas compartilhadas entre usuários virtuais. O README apresenta o repositório como a Community Edition, de uso livre inclusive comercial (conferido em 9 de outubro de 2026).

Do que você precisa para rodar o Gatling?

De uma JVM de 64 bits para Java, Kotlin ou Scala, ou de Node.js para JavaScript e TypeScript. Nos dois casos, a simulação em si roda numa JVM.

A página de instalação suporta as versões LTS do OpenJDK do 11 ao 25 e exclui JVMs de 32 bits e o OpenJ9. A CLI de JavaScript exige Node.js 24 ou mais recente e baixa um pacote de execução do Gatling e, segundo o README do gatling-js, o GraalVM (conferido em 9 de outubro de 2026).

Como uma simulação do Gatling é estruturada?

Uma simulação define cenários, dá a cada um um perfil de injeção e anexa uma configuração de protocolo, tudo registrado numa única chamada a setUp.

Na referência de simulações, um cenário encadeia requisições com pausas, laços e condições. Esta simulação em Java guarda o id de um produto vindo de uma busca, pausa de um a três segundos e abre o produto, enquanto as chegadas sobem para 20 usuários por segundo e se mantêm por dez minutos:

public class ShopSimulation extends Simulation {

  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder shoppers = scenario("Shoppers")
      .exec(http("search").get("/api/products?q=lamp")
          .check(jsonPath("$[0].id").saveAs("id")))
      .pause(1, 3)
      .exec(http("product").get("/api/products/#{id}"));

  {
    setUp(shoppers.injectOpen(
        rampUsersPerSec(1).to(20).during(120),
        constantUsersPerSec(20).during(600)))
      .protocols(api)
      .assertions(
          global().responseTime().percentile(95.0).lt(800));
  }
}

Os imports foram omitidos, e #{id} lê o valor guardado pela Expression Language do Gatling. Gatling vs k6 mostra uma simulação em JavaScript.

Você deve injetar usuários no modelo aberto ou fechado?

Aberto, para a maioria dos sites e APIs, onde novos usuários continuam chegando por mais lento que o sistema fique. O fechado serve para sistemas que limitam a concorrência, como uma fila de venda de ingressos.

A referência de injeção divide a API: injectOpen recebe taxas de chegada como rampUsersPerSec, e injectClosed, metas de concorrência como constantConcurrentUsers. A página sobre modelos de carga diz que a maioria dos sites se comporta como sistema aberto e que um perfil não pode misturar os dois (conferido em 9 de outubro de 2026). Nosso guia sobre o modelo de carga aberto vs fechado explica como escolher.

Como funcionam os checks, as asserções e o relatório?

Os checks verificam cada resposta e podem guardar valores dela, enquanto as asserções julgam a execução inteira quando ela termina. Depois, cada execução gera um relatório HTML.

Sem um check de status explícito, o Gatling verifica se cada resposta HTTP é 2XX ou 304. As asserções avaliam tempos de resposta, número de requisições ou requisições por segundo, no total ou por requisição, e uma única asserção com falha faz a simulação falhar. O relatório HTML mostra faixas de tempo de resposta e percentis, usuários iniciados por segundo, usuários simultâneos e requisições por segundo; seus percentis ao longo do tempo contam só as requisições bem-sucedidas (conferido em 9 de outubro de 2026).

Como o Gatling se encaixa no build e na CI?

Pelo plugin para Maven, Gradle, sbt ou npm, que roda em qualquer sistema de CI. Uma asserção com falha faz o build falhar.

O plugin do Maven liga gatling:test à fase integration-test, então mvn verify o executa, e com CI=true ele deixa de perguntar qual simulação rodar (a execução então falha se o projeto tiver mais de uma simulação e nenhuma for indicada). O plugin do Gradle usa gatlingRun, e o plugin do sbt aceita só simulações em Scala. As integrações de CI prontas do Gatling, como a sua GitHub Action, disparam execuções no Gatling Enterprise (conferido em 9 de outubro de 2026). Nosso guia de GitHub Actions cobre o lado do workflow.

Quais protocolos o Gatling suporta?

HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events e JMS vêm sem limites. gRPC, MQTT e GraphQL são plugins à parte, limitados a 5 usuários e 5 minutos fora do Gatling Enterprise.

O README coloca os cinco primeiros sob Apache 2.0. As páginas de configuração de gRPC, MQTT e GraphQL põem cada plugin sob a Gatling Enterprise Component License: sem limites no Gatling Enterprise, enquanto um teste com a Community Edition para em 5 usuários ou 5 minutos. Essa licença concede uso gratuito por até um ano, apenas para testar internamente as suas próprias aplicações web; ela termina assim que um limite é atingido, e a Gatling Corp pode mudar esses limites. O GraphQL exige a 3.16.0 ou mais recente. As notas da versão e o README dizem que o SDK de JavaScript ainda não tem suporte a ele, embora a página de configuração já mostre um pacote npm, então confira antes de planejar um teste de GraphQL em JavaScript (conferido em 9 de outubro de 2026). Nosso guia sobre teste de carga em uma API GraphQL contorna o limite com requisições HTTP comuns.

O que o Gatling Enterprise acrescenta?

O Gatling Enterprise é a edição comercial sobre o mesmo motor. Ele gera carga a partir de infraestrutura gerenciada ou privada, coisa que a edição gratuita não faz.

Segundo o README, o Enterprise roda os testes em geradores de carga gerenciados ou nas suas próprias contas de AWS, Azure, GCP ou Kubernetes, e acrescenta painéis ao vivo, tendências, equipes com SSO e integrações de CI/CD. O FAQ diz que a Community Edition não suporta testes distribuídos e que as simulações passam para o Enterprise sem alterações (conferido em 9 de outubro de 2026).

A LoadFocus, que publica este site, não roda simulações do Gatling. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões de nuvem, então para o Gatling o caminho para mais máquinas é o Gatling Enterprise.

O que o Gatling faz bem, e onde estão seus limites?

Ele se destaca em testes como código revisável, em modelos de carga e em relatórios sem configuração. É mais fraco em protocolos além da web e de mensageria, e em escalar de graça além de uma máquina.

O README destaca o motor: não bloqueante, construído sobre o Netty, com cada usuário virtual sendo uma mensagem leve. Limites que a própria documentação aponta (conferido em 9 de outubro de 2026):

O Gatling não é um navegador: segundo a página do protocolo HTTP, ele não executa JavaScript.
O SDK de JavaScript não tem JMS e não pode usar bibliotecas npm que precisem de binários nativos ou de APIs próprias do Node.js.
O cache HTTP vem ligado por padrão, o que pode reduzir a contagem de requisições.
O formato do simulation.log não é documentado e pode mudar a qualquer momento.

Quando escolher k6, JMeter ou Locust em vez do Gatling?

Escolha outra ferramenta quando a linguagem, os protocolos ou o caminho gratuito para escalar dela combinarem melhor com a sua equipe.

Nossa visão geral de ferramentas de teste de carga open source coloca o Gatling ao lado de outras cinco.

Escolha o k6 se você quer na CI um único binário sem JVM, thresholds capazes de parar cedo uma execução com falha ou gRPC entre os seus protocolos embutidos (conferido em 9 de outubro de 2026). Gatling vs k6 compara os dois.

Escolha o JMeter se os seus testadores montam testes numa interface gráfica, ou se você precisa de JDBC, LDAP ou FTP no núcleo (conferido em 9 de outubro de 2026). A LoadFocus roda planos de teste JMeter existentes a partir de 25 regiões de nuvem, e Gatling vs JMeter se aprofunda.

Escolha o Locust se a sua equipe escreve Python e quer um modo distribuído na ferramenta gratuita (conferido em 9 de outubro de 2026). Nossa análise do Locust trata dele.

FAQ

O Gatling é gratuito para uso comercial? Sim. A Community Edition está sob Apache 2.0. Os plugins de gRPC, MQTT e GraphQL têm licença própria e param em 5 usuários e 5 minutos fora do Gatling Enterprise.

É preciso ter Java para usar o Gatling? Para Java, Kotlin ou Scala, sim: um OpenJDK LTS de 64 bits do 11 ao 25. O SDK de JavaScript precisa do Node.js 24 ou mais recente, e a CLI dele baixa sozinha o ambiente JVM.

A LoadFocus consegue rodar testes do Gatling? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para distribuir uma simulação do Gatling por várias máquinas, use o Gatling Enterprise.

Leituras relacionadas

Gatling vs JMeter: testes como código ou plano na GUI?

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

Gatling e Apache JMeter são ferramentas de teste de carga gratuitas e open source que rodam na JVM, e a escolha depende principalmente de como o seu time quer construir os testes. Escolha o Gatling se você quer testes como código em Java, Kotlin, Scala, JavaScript ou TypeScript, perfis de injeção abertos e um relatório HTML depois de cada execução. Escolha o JMeter se você precisa de protocolos como JDBC, LDAP, FTP ou e-mail sem instalar nada a mais, prefere montar os testes em uma interface gráfica ou já tem planos de teste .jmx.

Os dados desta comparação Gatling vs JMeter vêm da documentação e do repositório de cada projeto, conferidos em 9 de outubro de 2026.

	Gatling	Apache JMeter
Licença	Apache 2.0; gRPC, MQTT e GraphQL sob uma licença de componentes separada (repositório)	Apache 2.0 (repositório)
Ambiente de execução	JVM, OpenJDK LTS 11 a 25 (versão 3.16.0)	JVM, Java 8 ou mais recente (versão 5.6.3)
Testes escritos como	Código em Java, Kotlin, Scala, JavaScript ou TypeScript	Planos de teste montados em uma interface gráfica e salvos em XML (`.jmx`)
Protocolos nativos	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, e-mail, TCP, comandos de shell, objetos Java
Gravador	Proxy HTTP ou conversor de arquivos HAR	HTTP(S) Test Script Recorder (proxy)
Modelo de carga	Perfis de injeção abertos ou fechados	Thread Groups; um Open Model Thread Group experimental
Escala	Uma máquina; execuções distribuídas exigem o Gatling Enterprise	Modo remoto nativo, um cliente controlando vários servidores
CI e execução sem interface	Plugins para Maven, Gradle, sbt e npm; uma assertion com falha derruba a execução	Modo CLI (`jmeter -n`); plugins de terceiros para Maven, Gradle e Jenkins
Relatórios	Relatório HTML depois de cada execução	Dashboard HTML; resultados ao vivo por um Backend Listener

Qual é a diferença entre Gatling e JMeter?

No Gatling, um teste é um programa dentro de um projeto de build. No JMeter, um teste é uma árvore de elementos que você monta em uma interface gráfica de desktop e salva como arquivo XML, e daí vem a maior parte das outras diferenças.

O README do Gatling chama os testes de simulações e os guarda no seu repositório como código da aplicação, executados por um plugin de Maven, Gradle, sbt ou npm. O SDK de JavaScript e TypeScript é instalado pelo npm e baixa o próprio ambiente GraalVM.

Um plano do JMeter tem um Thread Group para os usuários, samplers para as requisições e assertions e listeners para os resultados. O JMeter 5.6.3, versão atual na página de download, exige Java 8 ou mais recente. O README do branch de desenvolvimento do JMeter já exige Java 17 (conferido em 10 de outubro de 2026). Por baixo, o JMeter roda cada usuário virtual como uma thread Java, enquanto o README do Gatling descreve os usuários virtuais como mensagens leves em um motor não bloqueante construído sobre o Netty.

Como escrever um teste em cada ferramenta?

No Gatling, você escreve uma classe de simulação que define um cenário, um perfil de injeção e assertions. No JMeter, você adiciona um Thread Group e samplers na interface gráfica, salva o plano e depois roda esse arquivo pela linha de comando.

Uma simulação em Java baseada no tutorial da primeira simulação do Gatling: novos usuários chegam primeiro a um por segundo, sobem para dez por segundo em um minuto e ficam nesse ritmo por cinco minutos. A execução falha se o percentil 95 passar de 500 ms ou se mais de 1% das requisições falharem:

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

public class ApiSimulation extends Simulation {

  HttpProtocolBuilder httpProtocol =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1);

  {
    setUp(users.injectOpen(
            rampUsersPerSec(1).to(10).during(60),
            constantUsersPerSec(10).during(300)))
        .protocols(httpProtocol)
        .assertions(
            global().responseTime().percentile(95.0).lt(500),
            global().failedRequests().percent().lt(1.0));
  }
}

Rode com ./mvnw gatling:test; uma simulação em JavaScript ou TypeScript roda com npx gatling run.

No JMeter, o mesmo teste é um Thread Group com um sampler HTTP Request, e uma Duration Assertion pode marcar como falha cada resposta lenta. O guia de primeiros passos monta o plano no modo GUI e roda no modo CLI, e -e -o acrescenta o relatório HTML:

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

As duas ferramentas conseguem gravar um primeiro rascunho a partir do navegador. O Recorder do Gatling funciona como proxy HTTP ou converte um arquivo HAR em simulação, e o HTTP(S) Test Script Recorder do JMeter captura o tráfego do navegador em um plano (conferido em 9 de outubro de 2026). A documentação do Gatling já trata esse Recorder como legado, e o mais novo Gatling Studio exige uma conta do Enterprise para fazer login (conferido em 10 de outubro de 2026).

Quais protocolos cada ferramenta consegue testar?

O JMeter cobre mais protocolos de fábrica. O Gatling traz os principais protocolos web mais JMS e deixa quase todo o resto para componentes separados ou plugins da comunidade.

O README do JMeter lista todos os protocolos da tabela acima, e-mail incluído. JDBC e JMS precisam dos JARs de driver do seu banco de dados ou do seu provedor JMS, e o Plugins Manager instala plugins da comunidade pela própria interface gráfica.

Segundo o README do Gatling, gRPC, MQTT e GraphQL são componentes separados sob a Gatling Enterprise Component License e, sem o Enterprise, ficam limitados a cinco usuários simultâneos e a testes de cinco minutos. Kafka, AMQP, SFTP, FTP e JDBC vêm de plugins de terceiros para o Gatling 3.13 que o Gatling não mantém (conferido em 9 de outubro de 2026).

Como o Gatling e o JMeter modelam a carga?

O Gatling faz você escolher entre um modelo aberto e um fechado no próprio script. O Thread Group clássico do JMeter é um grupo fechado de usuários, e carga baseada em chegadas exige o Open Model Thread Group, mais recente.

No Gatling, injectOpen recebe taxas de chegada como constantUsersPerSec e rampUsersPerSec, e injectClosed recebe metas de concorrência como constantConcurrentUsers. O JMeter 5.5 trouxe o Open Model Thread Group, que a referência ainda marca como experimental (conferido em 9 de outubro de 2026). Nosso guia sobre o modelo de carga aberto vs fechado explica por que essa escolha importa.

Como distribuir um teste entre várias máquinas?

O JMeter tem um modo distribuído nativo. A edição open source do Gatling gera carga a partir de uma máquina, e a documentação exige uma conta do Gatling Enterprise para execuções distribuídas.

O modo de teste remoto do JMeter deixa um cliente controlar qualquer número de servidores. Cada servidor roda o plano inteiro, então 1.000 threads em seis servidores viram 6.000 threads. Todos os nós devem rodar a mesma versão do JMeter e do Java, o RMI precisa de um keystore a menos que o SSL esteja desativado, e os arquivos de dados precisam ser copiados para cada servidor.

Existe um terceiro caminho para planos de teste do JMeter. A LoadFocus, que publica este site, roda planos de teste JMeter existentes sem alterações a partir de 25 regiões de nuvem, sem servidores remotos para configurar. A LoadFocus não roda simulações do Gatling.

Como eles se encaixam na CI, e quais relatórios você recebe?

Os dois rodam sem interface. As assertions do Gatling podem derrubar o build diretamente, enquanto as do JMeter marcam amostras individuais e a integração com CI vem de bibliotecas de terceiros.

As assertions do Gatling são verificadas depois da execução, e uma única assertion com falha derruba a simulação e a tarefa de build. O relatório HTML mostra percentis do tempo de resposta, usuários iniciados por segundo, usuários simultâneos e requisições por segundo ao longo do tempo.

O modo CLI do JMeter não tem critérios de aprovação, então uma meta não atingida só derruba o build pelas bibliotecas para Maven, Gradle e Jenkins que o README dele lista, ou por uma checagem própria. O dashboard do JMeter traz uma tabela APDEX, uma tabela de estatísticas com três percentis configuráveis e resumos de erros, e um Backend Listener envia resultados ao vivo para InfluxDB ou Graphite.

Qual escolher?

Escolha o Gatling quando o seu time escreve Java, Kotlin, Scala ou TypeScript e quer revisar os testes de carga como o resto do código. Escolha o JMeter em vez do Gatling quando você precisa de protocolos além da web, quando seus testers preferem uma interface gráfica ou quando você já tem planos .jmx.

O Gatling combina com times que descrevem o tráfego como taxas de chegada e querem regras de aprovação ou falha ao lado do cenário, com um relatório legível sem configuração extra.

O JMeter é a melhor escolha para testar JDBC, LDAP, FTP ou e-mail, para testers que refinam visualmente um fluxo gravado e para execuções distribuídas nos seus próprios servidores sem licença comercial. Uma empresa que já usa o JMeter também mantém seus planos, plugins e conhecimento.

FAQ

O Gatling é mais rápido que o JMeter? Não medimos isso nós mesmos, então não vamos apontar um vencedor. O teste justo é o mesmo cenário nas duas ferramentas, no seu próprio hardware.

O Gatling consegue rodar arquivos .jmx do JMeter? Não diretamente. O Gatling roda simulações escritas com os SDKs dele, então um plano do JMeter precisa ser reescrito. O README do Gatling cita extensões de IA que convertem planos de teste do JMeter, e elas exigem um token de API do Gatling Enterprise.

A LoadFocus consegue rodar testes do Gatling? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para distribuir uma simulação do Gatling entre várias máquinas, use o Gatling Enterprise.

Leituras relacionadas

Gatling vs k6: simulações na JVM ou um único binário Go?

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

Gatling e k6 são ferramentas open source que guardam os testes de carga como código no seu repositório, e qualquer uma das duas testa bem uma API HTTP sob carga. Escolha o Gatling se o seu time trabalha em Java, Kotlin ou Scala, ou quer um relatório HTML depois de cada execução sem configurar nada. Escolha o k6 se você quer um único binário Go sem JVM, gRPC e testes de navegador prontos para uso, e thresholds capazes de parar cedo uma execução que está falhando.

Os dados desta comparação Gatling vs k6 vêm da documentação e do repositório de cada projeto, conferidos em 9 de outubro de 2026.

	Gatling	k6
Licença	Apache 2.0; gRPC, MQTT e GraphQL sob uma licença de componentes separada (repositório)	AGPL-3.0 (repositório)
Ambiente de execução	JVM; o SDK Java exige OpenJDK LTS 11 a 25 (versão 3.16.0)	Um binário Go com um motor JavaScript embutido (versão v2.3.0)
Scripts de teste	Java, Kotlin, Scala, JavaScript ou TypeScript	JavaScript, ou TypeScript sem checagem de tipos
Protocolos principais	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP/1.1, HTTP/2, WebSockets, gRPC
Modelo de carga	Perfis de injeção abertos ou fechados	Seis executors, dois deles por taxa de chegada (modelo aberto)
Critérios de aprovação	Assertions, verificadas depois da execução	Thresholds, que também podem interromper uma execução
Relatórios	Relatório HTML depois de cada execução	Resumo no fim do teste; dashboard web com exportação HTML
Testes de navegador	Nada embutido; o Recorder transforma o tráfego do navegador em código	Módulo de navegador embutido (controla um navegador baseado em Chromium)
Escala	Gatling Enterprise	k6-operator no Kubernetes, ou Grafana Cloud k6

Qual é a diferença entre Gatling e k6?

A maior diferença é o ambiente de execução. O Gatling roda na JVM e você escreve os testes com um dos SDKs dele, enquanto o k6 é um único programa compilado em Go que executa JavaScript.

O README do Gatling cita um SDK Java para Java, Kotlin e Scala, executado por um plugin de Maven, Gradle ou sbt. O SDK de JavaScript e TypeScript é instalado pelo npm, e a ferramenta de linha de comando dele baixa o GraalVM, então até uma simulação em JavaScript roda em uma JVM.

O k6 é instalado como pacote ou binário independente, sem nenhum outro ambiente de execução. Ele também roda arquivos .ts diretamente, e o suporte a TypeScript remove os tipos sem checá-los (conferido em 9 de outubro de 2026).

Como escrever o mesmo teste em cada ferramenta?

As duas ferramentas conseguem expressar o mesmo teste em JavaScript. O Gatling chama o teste de simulação e descreve a carga com um perfil de injeção, e o k6 chama de script e descreve a carga com um cenário e o executor dele.

Este é um teste em que dez novos usuários chegam a cada segundo durante cinco minutos, e a execução falha se o percentil 95 passar de 500 ms ou se mais de 1% das requisições falharem. No SDK de JavaScript do Gatling, baseado no tutorial da primeira simulação:

import {
  constantUsersPerSec, global, scenario, simulation,
} from "@gatling.io/core";
import { http } from "@gatling.io/http";

export default simulation((setUp) => {
  const api = http.baseUrl("https://staging.example.com");

  const users = scenario("API users")
    .exec(http("list users").get("/api/users"));

  setUp(users.injectOpen(constantUsersPerSec(10).during(300)))
    .protocols(api)
    .assertions(
      global().responseTime().percentile(95).lt(500),
      global().failedRequests().percent().lt(1),
    );
});

O mesmo teste no k6, com o executor constant-arrival-rate:

import http from "k6/http";

export const options = {
  scenarios: {
    api_users: {
      executor: "constant-arrival-rate",
      rate: 10,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 50,
    },
  },
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
}

Rode os dois com npx gatling run e k6 run script.js.

Como o Gatling e o k6 modelam a carga?

Os dois suportam modelos de carga abertos e fechados. No Gatling, a escolha vem do método de injeção que você chama, e no k6 vem do executor que você configura.

No Gatling, injectOpen recebe taxas de chegada como constantUsersPerSec, e injectClosed recebe metas de concorrência como constantConcurrentUsers. O k6 tem seis executors: os dois por taxa de chegada seguem o modelo aberto, e os outros quatro seguem o fechado, em que um usuário virtual só começa a próxima iteração quando a anterior termina.

Um cenário do k6 por taxa de chegada inicia as iterações a partir de um pool de usuários virtuais pré-alocados, e quando esse pool se esgota, o k6 pula iterações e as conta como iterações descartadas (conferido em 9 de outubro de 2026). Nosso guia sobre o modelo de carga aberto vs fechado explica quando usar cada um.

Como o Gatling e o k6 decidem se um teste passou?

Os dois transformam metas de desempenho em um resultado de aprovação ou reprovação que um pipeline de CI consegue usar. O Gatling verifica as metas quando a execução termina, e o k6 também consegue parar uma execução assim que uma meta é descumprida.

As assertions do Gatling são avaliadas depois da simulação, e uma única assertion com falha derruba a simulação e o build. Os thresholds do k6 encerram uma execução com falha com um código de saída diferente de zero, e um threshold com abortOnFail para o teste no momento em que falha (conferido em 9 de outubro de 2026).

Quais protocolos e testes de navegador cada ferramenta cobre?

As duas cobrem HTTP e WebSockets sem instalar nada a mais. O Gatling acrescenta Server-Sent Events e JMS, e o k6 acrescenta gRPC e sessões reais de navegador.

Segundo o README do Gatling, gRPC, MQTT e GraphQL são componentes separados sob a Gatling Enterprise Component License, limitados sem o Enterprise a cinco usuários simultâneos e a testes de cinco minutos. O k6 lista HTTP/1.1, HTTP/2, WebSockets e gRPC como protocolos nativos, e soma outros com extensões xk6 como Kafka e Redis.

Para testes de navegador, o k6 tem um módulo de navegador que controla um navegador baseado em Chromium e coleta métricas de frontend. A documentação do Gatling não descreve nenhum motor de navegador: o Recorder do Gatling transforma uma sessão de navegador ou um arquivo HAR em uma simulação no nível HTTP (conferido em 9 de outubro de 2026).

Como rodar um teste maior do que uma máquina consegue gerar?

A edição open source do Gatling gera carga a partir de uma única máquina, e execuções distribuídas exigem o Gatling Enterprise. O k6 consegue espalhar um teste por um cluster Kubernetes com o k6-operator, que é open source, ou rodá-lo no Grafana Cloud k6.

O guia de instalação do Gatling pede uma conta Enterprise para execuções distribuídas, que usam geradores de carga gerenciados ou locais privados na sua própria conta AWS, Azure, GCP ou Kubernetes. O k6-operator divide um teste entre várias instâncias do k6 em um cluster (conferido em 9 de outubro de 2026).

Existe um terceiro caminho para scripts k6. A LoadFocus, que publica este site, roda scripts k6 na própria infraestrutura de nuvem a partir de 25 regiões, com os usuários e a duração definidos nas configurações do teste. O validador de scripts da plataforma avisa que cenários por taxa de chegada rodam lá com um número fixo de usuários, então um script de modelo aberto como o de cima não mantém a taxa de chegada na LoadFocus. A LoadFocus não roda simulações do Gatling, então para o Gatling o caminho para mais máquinas é o Gatling Enterprise.

Que relatórios você recebe?

O Gatling gera um relatório HTML depois de cada execução sem configurar nada. O k6 mostra um resumo no terminal e consegue produzir um relatório HTML a partir do dashboard web embutido.

O relatório HTML do Gatling traz gráficos dos percentis do tempo de resposta, dos usuários iniciados por segundo e das requisições por segundo ao longo do teste. O k6 mostra um resumo no fim do teste, e o dashboard web dele exibe gráficos ao vivo e exporta um relatório HTML autocontido quando você define K6_WEB_DASHBOARD_EXPORT.

Qual escolher?

O Gatling combina com times que trabalham na JVM, e o k6 com times que querem um único binário e JavaScript. Protocolos, testes de navegador e escala decidem a maior parte dos outros casos.

Escolha o Gatling em vez do k6 quando o seu time trabalha na JVM e quer testes em Java, Kotlin ou Scala montados com Maven, Gradle ou sbt junto do código da aplicação, quando você precisa de JMS ou Server-Sent Events, ou quando quer um relatório HTML depois de cada execução sem configurar nada.

Escolha o k6 em vez do Gatling quando você quer um único binário na CI sem JVM para instalar, quando os seus testes precisam de gRPC ou de sessões reais de navegador, quando os thresholds devem parar cedo uma execução que está falhando, ou quando você pretende escalar no Kubernetes com um operator open source.

FAQ

O Gatling é mais rápido que o k6? Não medimos isso por conta própria, então não vamos apontar um vencedor. A comparação justa é rodar o mesmo cenário com as duas ferramentas no seu próprio hardware.

O Gatling consegue rodar scripts do k6? Não segundo a documentação do Gatling, que não descreve nenhuma forma de rodar scripts do k6. Os dois SDKs usam APIs diferentes e os conversores do Gatling cobrem JMeter e LoadRunner, então um script do k6 precisa ser reescrito como simulação do Gatling, mesmo com o SDK de JavaScript.

A LoadFocus consegue rodar testes do Gatling? Não. A LoadFocus roda scripts k6 e planos de teste JMeter. Para distribuir uma simulação do Gatling entre várias máquinas, use o Gatling Enterprise.

Leituras relacionadas

Teste de carga de API GraphQL: guia prático

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Para fazer um teste de carga de API GraphQL, escreva um script com as operações que seus clientes realmente enviam, dê a cada uma um nome próprio na ferramenta de teste e misture-as nas proporções que você vê em produção, com variáveis variadas. Verifique em cada corpo de resposta se existe um array errors, porque um servidor GraphQL costuma responder HTTP 200 mesmo quando parte da operação falhou. Depois aumente a carga e avalie cada operação pelos próprios percentis.

Fontes: graphql.org, o rascunho da especificação GraphQL over HTTP e a documentação de cada ferramenta, tudo conferido em 9 de outubro de 2026.

Ferramenta	Nomear cada operação com	Reprovar uma resposta com `errors`	Alimentar variáveis a partir de
k6	`tags: { name: "..." }`	Um `check()` no corpo já parseado	`SharedArray`
JMeter	O nome do sampler	JSON Assertion em `$.errors`, invertida	CSV Data Set Config
Gatling	`http("...")` ou o plugin de GraphQL	`jsonPath("$.errors").notExists()`	Feeders
Artillery	Um `name` na requisição	`notHasProperty: "errors"`	`config.payload`

Por que uma API GraphQL precisa de um teste de carga diferente?

Porque todas as operações vão para uma única URL, e o trabalho por trás depende da consulta e das variáveis. Um relatório agrupado por URL coloca uma leitura barata e uma busca cara no mesmo balaio.

O guia Serving over HTTP do graphql.org diz que um servidor GraphQL opera em um único endpoint, normalmente /graphql. As operações chegam ali por POST, com um corpo JSON que traz query, um operationName opcional e variables.

Como obter resultados por operação?

Dê a cada requisição o nome da sua operação GraphQL e faça a ferramenta agrupar as estatísticas por esse nome. Cada ferramenta tem a própria configuração para isso (conferido em 9 de outubro de 2026).

k6: o guia de tags e grupos orienta a definir tags.name para dar um nome significativo à requisição, e os thresholds podem mirar uma única tag, como http_req_duration{name:GetProduct}.
JMeter: o Aggregate Report cria uma linha para cada requisição com nome diferente. Desde o JMeter 5.4, o sampler GraphQL HTTP Request tem campos para Query, Variables e Operation Name.
Gatling: o nome da requisição é a chave das estatísticas, e o plugin de GraphQL nomeia as requisições pela operação, por exemplo query GetUser.
Artillery: o plugin metrics-by-endpoint reporta por URL e acrescenta à entrada o name da requisição, de modo que operações nomeadas aparecem separadas; useOnlyRequestNames: true remove a URL e mantém só o nome.

Quais operações o teste deve enviar?

As que a produção recebe, nas mesmas proporções. Tire a contagem de cada operação dos logs do servidor ou do seu monitoramento de GraphQL e transforme-a em uma mistura ponderada de leituras e mutações.

Use os documentos que seus clientes enviam, com a profundidade real, e não uma consulta simplificada. Alimente as variáveis a partir de um arquivo de dados, para que o servidor busque muitos registros diferentes em vez de devolver um único resultado do cache. Mantenha realista também o número de operações distintas: a nota técnica da Apollo sobre teste de carga de GraphQL, um documento do próprio fornecedor, explica que cada operação nova é analisada e validada antes de rodar, e desaconselha gerar muito mais operações únicas do que os clientes reais enviam.

Mutações alteram dados, então rode-as onde os dados possam ser restaurados. O guia passo a passo de teste de carga cobre metas e rampa de subida.

Por que uma resposta HTTP 200 ainda pode ser uma falha?

Porque o GraphQL reporta erros dentro do corpo da resposta. Uma requisição pode voltar com status 200, um array errors e dados parciais, e uma verificação de status deixa passar.

A página Response do graphql.org explica que, quando um resolver falha, a execução continua e a resposta traz data junto com errors. O guia de HTTP acrescenta que essa resposta deve receber mesmo assim um status 2xx, já que o HTTP não tem código para sucesso parcial, e que alguns servidores antigos respondem 2xx até para erros de validação. O rascunho GraphQL over HTTP propõe um status próprio, o 294, para sucesso parcial com o tipo de mídia mais novo application/graphql-response+json.

Em um teste de carga isso atrapalha duas vezes. Os erros não entram na conta, e requisições que falham rápido, como operações recusadas por um limite de profundidade, puxam os tempos de resposta para baixo.

Como verificar o array errors em cada ferramenta?

Faça o parse do corpo JSON e reprove a requisição quando houver errors. Cada ferramenta tem um jeito embutido de fazer isso.

No k6, um check no corpo parseado resolve, e um threshold na métrica checks faz a execução falhar, porque checks sozinhos não mudam o código de saída do k6:

import http from "k6/http";
import { check, sleep } from "k6";
import { SharedArray } from "k6/data";

const URL = "https://staging.example.com/graphql";
const ids = new SharedArray("ids", () =>
  JSON.parse(open("./product-ids.json")));
const QUERY = `query GetProduct($id: ID!) {
  product(id: $id) { id name price }
}`;

export const options = {
  vus: 20,
  duration: "5m",
  thresholds: {
    checks: ["rate>0.99"],
    "http_req_duration{name:GetProduct}": ["p(95)<400"],
  },
};

function parse(res) {
  try { return res.json(); } catch (e) { return null; }
}

export default function () {
  const id = ids[Math.floor(Math.random() * ids.length)];
  const payload = JSON.stringify({
    query: QUERY,
    operationName: "GetProduct",
    variables: { id: id },
  });
  const res = http.post(URL, payload, {
    headers: { "Content-Type": "application/json" },
    tags: { name: "GetProduct" },
  });
  const body = parse(res);
  check(res, {
    "status is 2xx": (r) => r.status >= 200 && r.status < 300,
    "no GraphQL errors": () => body !== null && !body.errors,
  });
  sleep(1);
}

O SharedArray carrega os IDs uma única vez para todos os usuários virtuais. O try impede que um corpo que não seja JSON, como a página de erro de um proxy, interrompa a iteração.

No JMeter, adicione uma JSON Assertion com o caminho $.errors e marque "Invert assertion", para que a amostra falhe quando o caminho existir. Um JSON Extractor copia IDs para variáveis usadas na próxima operação.

No Gatling, acrescente .check(jsonPath("$.errors").notExists()), os dois da referência de checks. O plugin de GraphQL verifica o status e os erros por padrão, mas a página de configuração dele limita as execuções na Community Edition a 5 usuários e 5 minutos (conferido em 9 de outubro de 2026). Para testes maiores sem o Gatling Enterprise, use requisições HTTP comuns com esse check.

No Artillery, o plugin expect oferece notHasProperty: "errors", e reportFailuresAsErrors: true leva as expectativas que falharam para o relatório. Um capture com um caminho json passa um valor para a próxima requisição.

O que observar além dos tempos de resposta?

Cache, consultas persistidas e carga do banco de dados por requisição. Qualquer um deles pode deixar um teste mais rápido ou mais lento que a produção por motivos que nada têm a ver com capacidade.

O guia de desempenho do graphql.org observa que consultas enviadas por GET podem usar cache HTTP e CDN, e que consultas persistidas permitem ao cliente enviar um hash em vez do documento completo. Se seus clientes fazem isso, o teste deve fazer também. Se não fazem, um teste que repete uma consulta com as mesmas variáveis mede um cache que o tráfego real não acerta. A nota técnica da Apollo acrescenta que o Apollo Server, o Gateway e o GraphOS Router ativam por padrão as consultas persistidas automáticas.

O mesmo guia descreve o problema N+1: uma lista cujo resolver carrega cada item separadamente transforma uma requisição em muitas consultas ao banco, algo que costuma ser resolvido agrupando-as com uma ferramenta como o DataLoader. Acompanhe as consultas ao banco por segundo ao lado das requisições por segundo; se elas sobem muito mais rápido conforme a carga cresce, desconfie de um resolver. Limites de profundidade, de complexidade e de taxa também podem disparar durante um teste.

De onde deve vir a carga?

De uma única máquina enquanto você monta o script e faz um smoke test, e depois da nuvem, quando precisar de mais carga ou de tráfego vindo de várias regiões.

A LoadFocus roda scripts k6 a partir de 25 regiões de nuvem. Lá, o número de usuários e a duração vêm das configurações do teste, e não das options do script, e cenários com taxa de chegada rodam com um número fixo de usuários em vez de uma taxa fixa de requisições, a diferença explicada no artigo sobre modelo de carga aberto e fechado. A LoadFocus também publica um modelo para endpoints GraphQL com consultas complexas (em inglês).

FAQ

Um teste de carga de GraphQL deve enviar consultas por GET ou por POST? Do jeito que seus clientes enviam. O graphql.org só permite GET para operações do tipo query, e mutações precisam usar POST. Se a produção envia consultas persistidas por GET através de uma CDN, teste esse caminho também.

O mesmo script serve para testar a carga de subscriptions GraphQL? Normalmente não. O graphql.org explica que subscriptions são de longa duração e costumam usar WebSockets ou server-sent events, então precisam de um cenário próprio em uma ferramenta que suporte esse transporte.

Uma resposta parcial deve contar como requisição com falha? Na maioria dos testes, sim, porque o cliente recebeu um erro em parte do que pediu. Se alguns erros são esperados, como resultados não encontrados para registros apagados, verifique esses códigos de erro específicos e reprove o resto.

Leituras relacionadas

Ferramentas de benchmark HTTP: wrk, hey, oha, ab e mais

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

As ferramentas de benchmark HTTP de linha de comando que a maioria dos times usa são wrk, wrk2, hey, oha, ab (Apache Bench), bombardier, autocannon e h2load. Use wrk2 quando precisar de uma taxa de requisições constante e de latências de cauda confiáveis, hey ou oha para uma checagem rápida que também fale HTTP/2, h2load quando o próprio HTTP/2 ou HTTP/3 estiver em teste, e autocannon se o seu time trabalha com Node.js.

Não colocamos essas ferramentas umas contra as outras, então aqui não há números de velocidade nem veredito sobre a mais "rápida". Os dados vêm do repositório, do manual ou da página de versões de cada projeto (conferidos em 9 de outubro de 2026); as dicas de quando escolher cada uma são a nossa avaliação.

Ferramenta	Escrita em	Licença	Controle de taxa	HTTP/2	Última versão
wrk	C, scripts LuaJIT	Modified Apache 2.0	Nenhum	Não documentado	Tag 4.2.0, fev. 2021
wrk2	C	Apache 2.0	Taxa fixa (`-R`)	Não documentado	Nenhuma, último commit set. 2019
hey	Go	Apache 2.0	Limite por worker (`-q`)	Sim	v0.1.5, jan. 2026
oha	Rust	MIT	Limite global (`-q`)	Sim, e HTTP/3	v1.16.0, ago. 2026
ab	C (Apache httpd)	Apache 2.0	Nenhum	Não	httpd 2.4.69, out. 2026
bombardier	Go	MIT	Limite (`-r`)	Sim	v2.0.2, mar. 2025
autocannon	Node.js	MIT	Limite (`-R`)	Não	v8.0.0, out. 2024
h2load	C++ (nghttp2)	MIT	Por cliente (`--rps`)	Sim, e HTTP/3	nghttp2 v1.70.0, jul. 2026
Vegeta	Go	MIT	Taxa fixa (`-rate`)	Sim	v12.13.0, out. 2025

Por que importa se a ferramenta fixa a taxa?

Uma ferramenta que mantém um número fixo de conexões envia menos assim que o servidor fica lento, e os números de latência dela deixam de fora o tempo que as requisições passaram esperando. Uma ferramenta de taxa fixa continua enviando no ritmo planejado, e a lentidão aparece nos percentis.

A maioria das ferramentas desta lista roda um número definido de conexões ou workers (-c), e cada um espera uma resposta antes de enviar mais. O README do wrk2 chama esse ponto cego de Coordinated Omission e cronometra cada requisição a partir do momento em que ela deveria ter sido enviada. O Vegeta também mantém uma taxa constante; veja o nosso panorama de ferramentas de teste de carga open source. oha e autocannon conseguem corrigir a latência desse mesmo efeito quando você define uma taxa, enquanto hey e bombardier documentam suas opções de taxa apenas como limites.

O wrk ainda vale a pena?

Sim, para ver rapidamente quanta carga uma única máquina consegue mandar para um endpoint, lendo os números com a ressalva acima. A tag mais recente é de fevereiro de 2021.

O wrk é escrito em C e mantém um número fixo de conexões abertas distribuídas em várias threads. Scripts LuaJIT opcionais podem montar requisições, processar respostas e gerar relatórios próprios, e o make compila a ferramenta junto com o LuaJIT e o OpenSSL que vêm no pacote. Ele mostra a latência média, o desvio padrão e o máximo; --latency acrescenta os percentis 50, 75, 90 e 99.

Escolha o wrk2 no lugar dele quando precisar de uma taxa de requisições fixa ou de latências de cauda confiáveis durante uma lentidão.

Quando você precisa do wrk2 em vez do wrk?

Quando a pergunta é como a latência se comporta a uma determinada taxa de requisições. O wrk2 mantém essa taxa constante e registra cada latência em um HdrHistogram.

O wrk2 acrescenta ao wrk um argumento de vazão (-R, em requisições por segundo). --latency mostra o espectro completo de percentis e --u_latency acrescenta os números sem correção para comparar. O README avisa que execuções com menos de 10 a 20 segundos podem não trazer informação útil por causa de um período de calibração de 10 segundos, e descreve o projeto como experimental. Não há versões publicadas, e o Makefile gera um binário que também se chama wrk, então mantenha os dois separados.

Escolha oha ou autocannon no lugar dele quando quiser um ajuste de taxa com correção de latência em um projeto que ainda é mantido.

hey e oha são intercambiáveis?

Para checagens rápidas, em boa parte: os dois rodam um grupo de workers por um número de requisições ou por um tempo, e os dois falam HTTP/2. A diferença está em como limitam a taxa e no que você vê durante a execução.

O hey é um pequeno programa em Go com binários prontos para Linux, macOS e Windows e uma fórmula do Homebrew. -q limita as requisições por segundo de cada worker, -h2 ativa o HTTP/2, e o resumo traz um histograma de tempo de resposta e uma distribuição de latência, ou CSV com -o csv.

O oha é escrito em Rust, foi inspirado no hey e mostra uma interface ao vivo no terminal. O -q dele define uma taxa global, --latency-correction corrige a Coordinated Omission e --http-version aceita 1.1, 2 e, em uma compilação experimental, 3. Ele é instalado com cargo, Homebrew, winget ou pacman e pode gravar JSON ou CSV.

Escolha o hey no lugar dele quando um limite por worker combinar com o seu jeito de pensar a carga; escolha o oha para HTTP/3, JSON ou correção de latência.

Ainda vale usar o ab?

Para uma checagem rápida em uma máquina onde ele já está instalado, sim. O ab vem com o Apache HTTP Server, e o próprio manual lista limitações conhecidas.

O ab recebe um número de requisições (-n) e um nível de concorrência (-c), não tem opção de taxa nem de HTTP/2 e só usa KeepAlive com -k. A saída termina com a porcentagem de requisições atendidas dentro de um tempo, e ele pode gravar essas porcentagens em CSV (-e) ou cada medição em um arquivo para o gnuplot (-g). A seção de bugs do manual diz que o ab não implementa o HTTP/1.x por completo e avisa que o parsing pesado de strings pode fazer você medir o desempenho do próprio ab.

Escolha hey ou oha no lugar dele quando precisar de HTTP/2, de um limite de taxa ou de keep-alive por padrão.

Para que servem o bombardier e o autocannon?

O bombardier é uma ferramenta em Go com HTTP/2 opcional e limite de taxa. O autocannon combina com times de Node.js, porque também roda como biblioteca dentro de um script Node.

O bombardier usa por padrão o cliente fasthttp e passa para o cliente net/http do Go com --http1 ou --http2. -r define um limite de taxa, -l mostra os percentis 50, 75, 90 e 99, e -o json deixa o resultado pronto para ser lido por outras ferramentas.

O autocannon se descreve como uma ferramenta HTTP/1.1 com pipelining e HTTPS e é instalado com npm i autocannon -g. -R limita a taxa global e -r a de cada conexão, e quando qualquer um dos dois está definido a latência é corrigida da Coordinated Omission. A tabela dele mostra os percentis 2,5, 50, 97,5 e 99, -l mostra todos e -j grava JSON.

Escolha o autocannon em vez do bombardier quando seus benchmarks morarem em uma suíte de testes Node.js, e o bombardier quando precisar de HTTP/2.

Qual ferramenta foi feita para HTTP/2 e HTTP/3?

O h2load. Ele vem do projeto nghttp2, prefere HTTP/2 e consegue forçar HTTP/1.1 ou, quando compilado com suporte, HTTP/3.

O h2load é compilado junto com o nghttp2 passando --enable-app para o ./configure. Além do número de clientes (-c), ele define os streams simultâneos por cliente (-m) para colocar a multiplexação sob carga, e --rps define as requisições por segundo de cada cliente. O manual traz mínimo, máximo, média, mediana, p95 e p99 para o tempo de requisição, o tempo de conexão e o tempo até o primeiro byte. O suporte a HTTP/3 aparece como experimental.

Escolha o oha no lugar dele quando quiser HTTP/2 com menos opções e uma visão ao vivo.

Quando passar de um benchmark para um teste de carga de verdade?

Quando a pergunta envolve jornadas de usuário, mais carga do que uma máquina consegue gerar ou tráfego vindo de onde os seus usuários estão.

Todas essas ferramentas disparam requisições simples a partir de uma única máquina, e o guia do h2load lembra que o próprio cliente pode virar o gargalo. Passe para uma ferramenta de teste de carga quando precisar de login, jornadas com várias etapas ou tempo de pensamento, quando o tráfego tiver de vir de várias regiões ou quando um teste precisar passar ou falhar na CI. O nosso guia Como fazer um teste de carga mostra isso passo a passo, e k6 vs Artillery compara duas ferramentas baseadas em scripts.

A LoadFocus, que publica este site, roda testes de carga para sites e APIs a partir de 25 regiões na nuvem, com JMeter, k6 ou testes sem código. Se o seu benchmark é uma requisição que você já manda com curl, o conversor de cURL para k6 gratuito dela transforma esse comando em um script k6 no próprio navegador.

FAQ

Qual é a diferença entre wrk e wrk2? O wrk2 é um fork do wrk que envia requisições a uma taxa constante definida com -R e cronometra cada requisição a partir do momento em que ela deveria ter sido enviada. O wrk mantém ocupado um número fixo de conexões e não tem ajuste de taxa.

Quais ferramentas de benchmark HTTP suportam HTTP/2? Segundo a documentação delas, hey, oha, bombardier, h2load e Vegeta. wrk e wrk2 não documentam o suporte, o autocannon se descreve como ferramenta HTTP/1.1 e o ab não tem opção de HTTP/2.

Leituras relacionadas

Lei de Little em teste de carga: dimensionar e conferir

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

A lei de Little em teste de carga diz que o número médio de usuários ou requisições dentro de um sistema é igual ao ritmo com que eles passam por ele multiplicado pelo tempo médio que cada um fica lá: L = λW. Com um número fixo de usuários virtuais, isso vira usuários = voltas por segundo × (tempo de resposta + tempo de pensamento), o que mostra antes de uma execução se o plano consegue atingir a taxa alvo e, depois, se os resultados fecham. Ela trabalha com médias sobre um trecho estável do teste, então não diz nada sobre percentis.

Os exemplos abaixo são aritmética, sem nenhum teste por trás. Os fatos sobre ferramentas vêm da documentação de cada projeto, conferida em 9 de outubro de 2026.

Termo	Definição de Little	Usuários virtuais fixos (modelo fechado)	Taxa de chegada (modelo aberto)
L	Número médio de itens no sistema	Usuários virtuais, esperando ou em pausa	Iterações em andamento
λ	Taxa média de chegada	Voltas concluídas por segundo	A taxa que você define
W	Tempo médio dentro do sistema	Tempo de resposta + tempo de pensamento por volta	Duração de uma iteração

O que diz a lei de Little?

No longo prazo, o número médio de itens em um sistema de filas é igual à sua taxa média de chegada multiplicada pelo tempo médio que cada um passa nele. Conhecendo duas das três grandezas, você calcula a terceira.

John D. C. Little publicou a prova em 1961 na Operations Research com o título A Proof for the Queuing Formula: L = λW. Na revisão que publicou pelos 50 anos da lei, de 2011, ele escreve que ela vale sob condições notavelmente gerais: para uma única fila ou uma rede inteira, para uma subclasse de itens ou para todos, e qualquer que seja a ordem de atendimento. O mesmo artigo leva os termos para um servidor: requisições em processamento, requisições por segundo e tempo de resposta médio.

O que significam L, λ e W em um teste de carga?

Depende de onde você traça a fronteira do sistema. Ao redor do servidor, L são as requisições em andamento e W é o tempo de resposta; ao redor da volta completa de um usuário virtual, L são todos os usuários virtuais e W é o tempo de resposta mais o tempo de pensamento.

Em um teste com modelo fechado, cada usuário está sempre em algum ponto da sua volta: esperando uma resposta ou fazendo uma pausa entre dois passos. Com a fronteira ao redor da volta, todos contam como "dentro", λ é o ritmo com que as voltas terminam e W é a duração média de uma volta, incluindo o tempo de pensamento que o script adiciona:

usuários = voltas por segundo × (resposta + pensamento)

Ao redor do servidor, a mesma lei dá as requisições em andamento: requisições por segundo × tempo de resposta médio, o número que seus pools de conexão e threads de trabalho precisam comportar. Mantenha os três valores na mesma fronteira e no mesmo trecho de tempo; misturá-los dá resultados plausíveis e errados.

Como dimensionar um teste com modelo fechado usando a lei de Little?

Converta a taxa de requisições alvo em voltas por segundo e multiplique pela duração esperada de uma volta: o resultado é o número de usuários virtuais de que o plano precisa. Use o tempo de resposta que você espera com a carga alvo, que costuma ser maior do que o visto com poucos usuários.

Um exemplo, só aritmética. A meta é 100 requisições por segundo, cada volta envia 4 requisições que devem levar 0,5 segundo cada, e o script faz 3 pausas de 2 segundos em média:

voltas por segundo  = 100 requisições/s ÷ 4 requisições = 25
duração por volta   = 4 × 0,5 s + 3 × 2 s               = 8 s
usuários virtuais   = 25 voltas/s × 8 s                 = 200

Trate 200 como o mínimo. Se as respostas levarem 1 segundo com essa carga, uma volta dura 10 segundos e a mesma meta precisa de 250 usuários.

Por que os mesmos usuários enviam menos requisições quando o sistema fica lento?

O número de usuários é fixo, então quando uma volta fica mais longa, as voltas por segundo precisam cair. A carga cai justamente quando o sistema começa a sofrer.

Mantenha os 200 usuários e faça cada requisição levar 2 segundos. Uma volta passa a durar 4 × 2 + 6 = 14 segundos, e 200 ÷ 14 dá cerca de 14,3 voltas, ou cerca de 57 requisições por segundo. O teste continua mostrando 200 usuários enquanto roda a pouco mais da metade da taxa planejada. O artigo sobre o modelo de carga aberto vs fechado explica por que isso esconde a saturação; a lei de Little prevê o tamanho da queda.

Ela também mostra como é um limite de capacidade. Quando a taxa de requisições não consegue mais subir, cada usuário extra só acrescenta espera: com um teto de 25 voltas por segundo, 300 usuários significam 12 segundos por volta e 400 usuários, 16. O gráfico de tempo de resposta vs usuários virtuais da LoadFocus mostra o tempo de resposta médio e máximo em função do número de usuários virtuais ativos, um ponto por nível alcançado, e é ali que essa subida constante aparece.

Como conferir um teste terminado com a lei de Little?

Pegue a taxa de requisições e o tempo de resposta médios de um trecho em que o número de usuários ficou estável, reconstrua a partir deles o número de usuários e compare com o que você configurou. Uma diferença grande significa que parte do tempo está escapando dos seus números.

Outro exemplo aritmético. Uma execução mantém 200 usuários e registra 80 requisições por segundo com média de 0,6 segundo, com as mesmas 4 requisições e 6 segundos de pausas por volta. São 20 voltas por segundo de 4 × 0,6 + 6 = 8,4 segundos cada, o suficiente para 168 usuários. Os outros 32 significam que cada volta durou na verdade 10 segundos, então cerca de 1,6 segundo por volta fica sem explicação. Onde procurar:

O estabelecimento de conexões. No k6, http_req_duration deixa de fora a resolução DNS e a conexão (referência de métricas, conferida em 9 de outubro de 2026).
O gerador de carga. Um gerador sobrecarregado atrasa o script entre requisições.
O tempo de pensamento. Pausas aleatórias podem durar em média mais do que o plano prevê.
A janela. Se ela pega parte de uma rampa, havia em média menos usuários ativos.

O k6 também mede a volta diretamente: vus conta os usuários virtuais ativos e iteration_duration a duração de uma iteração completa, então os usuários ativos devem ficar perto de iterações por segundo × duração média de uma iteração.

E os testes por taxa de chegada?

A lei vale com a fronteira ao redor de cada iteração: as iterações em andamento são iguais à taxa de chegada vezes a duração de uma iteração. Esse é o número de usuários virtuais que a ferramenta precisa manter prontos.

O guia do k6 sobre alocação de VUs para executores arrival-rate estima esse número como a duração mediana de uma iteração × a taxa, mais uma constante para a variação (conferido em 9 de outubro de 2026). É a lei de Little com a mediana no lugar da média; algumas iterações lentas puxam a média para cima da mediana, por isso a margem importa.

A LoadFocus roda scripts k6 na própria nuvem, e lá os cenários de taxa de chegada rodam com um número fixo de usuários; o validador de scripts avisa isso quando você adiciona um script assim. Dimensione esses testes com a conta do modelo fechado acima e espere que a taxa caia se as respostas ficarem mais lentas.

Onde a lei de Little deixa de funcionar?

Ela liga médias sobre um trecho em que o sistema está em equilíbrio. Percentis, janelas curtas e rampas ficam de fora.

Só médias. Um teste pode cumprir a lei enquanto uma em cada vinte requisições espera dez vezes a média; julgue os resultados também pelos percentis.
Um trecho estável. A prova de 1961 supõe um processo estacionário, e a revisão de 2011 mostra que a fórmula também é exata em uma janela finita que começa e termina vazia. Um platô de teste não é nenhuma das duas coisas, então escolha um longo, em que tantos usuários terminem voltas quantos as comecem.
Rampas. Enquanto usuários estão sendo adicionados, o pico configurado não é L: use a média de usuários no tempo da janela ou deixe a rampa de fora.
Erros. Falhas rápidas contam como requisições concluídas com tempos curtos, então um sistema falhando ainda pode fechar a equação. Confira primeiro a taxa de erros.

FAQ

A lei de Little exige chegadas de Poisson ou um tipo de fila específico? Não. As provas da revisão de Little não supõem nada sobre o padrão de chegadas nem sobre os tempos de atendimento, e o resultado vale qualquer que seja a ordem de atendimento. Basta que as médias existam no período que você mede.

A lei de Little consegue prever o tempo de resposta p95? Não. Ela liga três médias, então pode conferir um tempo de resposta médio, mas não diz nada sobre a forma da distribuição nem sobre os poucos por cento mais lentos.

Leituras relacionadas

Critérios de aprovação de um teste de carga: como definir

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Os critérios de aprovação de um teste de carga são os poucos limites que uma execução precisa cumprir para ser aprovada: um percentil de latência para as requisições que os usuários esperam, uma taxa de erros e uma taxa mínima de requisições, tudo sob uma carga definida. Tire os limites de um objetivo de nível de serviço (SLO), coloque dentro deles limites de regressão vindos de execuções anteriores e deixe o código de saída da ferramenta reprovar a execução só por esses limites rígidos. Todo o resto é um aviso que uma pessoa lê.

Os fatos sobre as ferramentas foram conferidos em 9 de outubro de 2026 na documentação de cada projeto, e todo limite mostrado é um exemplo.

Critério	Limite de exemplo	De onde vem o número	Se não for cumprido
p95 de latência, checkout	Abaixo de 400 ms	SLO de latência menos uma margem	Reprovação
p99 de latência, checkout	Abaixo de 1.200 ms	Execuções anteriores deste teste	Aviso
Taxa de erros	Abaixo de 0,5%	SLO de disponibilidade	Reprovação
Requisições por segundo	Pelo menos 95% do plano	A carga planejada	Reprovação
CPU do gerador de carga	Abaixo de 80%	Ferramenta ou plataforma	Execução inválida

O que faz um teste de carga passar ou falhar?

Uma execução passa quando todos os limites rígidos se mantêm sob a carga planejada e falha assim que um deles é violado. Ela é inválida quando o próprio teste não cumpriu seu papel, sejam quais forem os números.

Um gerador de carga saturado, uma carga que nunca chegou à meta ou um script com erros produzem números sobre a montagem do teste. A LoadFocus, por exemplo, mostra um aviso de saturação do gerador de carga quando algum motor chegou a 80% de CPU ou mais no pico. Os códigos de saída do k6 separam os casos para a CI: 99 indica thresholds violados e 107 uma exceção no script (conferido em 9 de outubro de 2026).

Como transformar um SLO em critérios de teste de carga?

Reescreva cada SLO que a carga pode quebrar, em geral latência e disponibilidade, como um limite sobre o que o teste mede, e deixe esse limite mais rígido que o SLO para que a aprovação tenha folga.

O livro de SRE do Google define um SLO como um valor-alvo ou uma faixa de valores para um nível de serviço medido por um indicador (SLI), com exemplos como: 99% das chamadas Get terminam em menos de 100 ms. Ele pede que um SLO diga como é medido e em que condições vale, e recomenda uma margem de segurança: uma meta interna mais rígida que a prometida aos usuários.

Num teste de carga, essas condições são a carga e o mix de requisições. "95% das chamadas de checkout abaixo de 500 ms" poderia virar, como exemplo, "p95 do checkout abaixo de 400 ms com 300 requisições por segundo durante 15 minutos". Se ainda não houver SLO, combine um provisório com quem responde pelo produto.

Quais métricas os critérios devem cobrir?

A latência das requisições que os usuários esperam, uma taxa de erros, a taxa de requisições alcançada e, principalmente como avisos, os recursos dos servidores.

Latência por tipo de requisição. Um percentil global mistura um health check rápido com uma busca lenta. No k6, requisições com tag criam submétricas com limites próprios; no Gatling, details() mira uma requisição ou um grupo. Um teste que freou a própria carga mostra percentis bonitos demais (coordinated omission).
Erros, no sentido amplo. Um 200 rápido com uma página de erro continua sendo uma falha, então verifique o conteúdo. Uma Response Assertion do JMeter que falha marca sua amostra como malsucedida; os checks do k6 só afetam o código de saída por meio de um threshold.
Um piso para a taxa de requisições. Num modelo de carga fechado, um sistema lento recebe menos requisições, então uma execução pode cumprir os limites de latência com uma fração da carga planejada (modelo de carga aberto vs fechado).
Recursos dos servidores. CPU, memória e uso de pools vêm do seu monitoramento. Trate-os como avisos, a menos que um plano de capacidade defina um teto rígido.

Como escolher os números?

O teto vem do SLO e o limite de regressão vem de execuções anteriores do mesmo teste. O SLO diz o que os usuários toleram; as execuções anteriores dizem o que este build costuma fazer.

O livro de SRE desaconselha definir um SLO a partir do desempenho atual. Um limite de regressão existe para notar mudanças, então o desempenho atual é justamente a sua matéria-prima. Rode o build sem alterações várias vezes, com o mesmo ambiente e a mesma carga, anote quanto cada métrica varia e coloque o limite acima da pior execução com alguma folga, sempre abaixo do teto derivado do SLO quando houver um.

Se as execuções de um mesmo build variam mais do que a regressão que você quer detectar, o teste está ruidoso demais para bloquear builds: primeiro alongue a fase estável ou isole o ambiente. Registre novas execuções de referência depois de qualquer mudança intencional.

Quais critérios devem reprovar o build e quais devem só avisar?

Reprove o build nos limites que vêm de um SLO ou que verificam se as respostas estão corretas. Avise sobre percentis de cauda, uso de recursos e desvios lentos, que pedem avaliação; uma barreira que falha por ruído logo acaba desligada.

O plugin ensure do Artillery tem um nível de aviso: uma condição com strict: false é opcional, então descumpri-la não muda o código de saída (conferido em 9 de outubro de 2026). No k6, um check sem threshold nunca reprova a execução. Nas outras ferramentas, deixe os avisos fora das assertions.

config:
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 400
      conditions:
        - expression: "http.response_time.p99 < 1200"
          strict: false

Quando um teste de carga deve parar antes da hora?

Quando continuar só pode causar dano ou já não prova nada: erros muito acima do limite, um sistema já fora do ar ou um gerador que não dá conta. Dê à regra um período de carência para que o ruído do início não a dispare.

Deixe as regras de parada mais frouxas que os limites de aprovação: elas protegem um ambiente compartilhado. No k6, abortOnFail interrompe o teste assim que um threshold falha, depois de um delayAbortEval opcional. A documentação do Locust sobre extensões mostra um greenlet em segundo plano que encerra a execução quando a proporção de falhas passa de um limite. No Gatling, crashLoadGeneratorIf para o gerador com um código de falha quando uma condição é verdadeira na sessão de um usuário virtual. Um Thread Group do JMeter pode parar o teste diante de um erro de sampler, o que serve para uma verificação de correção (tudo conferido em 9 de outubro de 2026).

Como cada ferramenta codifica os critérios?

k6 e Artillery transformam um limite rígido violado em um código de saída diferente de zero, o Locust faz isso para qualquer requisição com falha ou para limites que você mesmo programa, e as assertions do Gatling reprovam o build. O JMeter deixa o veredito para uma etapa depois da execução.

k6: os thresholds ficam nas opções do script. Este exemplo reprova pelo p95 das requisições com a tag name: checkout ou por 0,5% de erros, e interrompe o teste após um minuto se os erros passarem de 5%:

export const options = {
  thresholds: {
    "http_req_duration{name:checkout}": ["p(95)<400"],
    http_req_failed: [
      "rate<0.005",
      { threshold: "rate<0.05", abortOnFail: true,
        delayAbortEval: "1m" },
    ],
  },
};

Gatling: as assertions combinam um escopo (global, forAll, details), uma estatística como um percentil ou requestsPerSec, e uma condição. Elas são avaliadas ao fim da execução, e uma única assertion com falha reprova a simulação.

O Locust sai com código 1 quando alguma requisição falhou, e --exit-code-on-error muda esse código. Para uma proporção ou um percentil, defina environment.process_exit_code num listener de quitting; o código-fonte do Locust dá prioridade a esse valor.

O JMeter julga cada amostra com suas assertions, e as suas opções de linha de comando não trazem nenhum limite para a execução inteira. Quem decide é a CI: um script curto sobre o arquivo de resultados, como no nosso guia de GitHub Actions, ou o jmeter-maven-plugin, um plugin de terceiros cujo goal results reprova o build se uma única amostra falhar, a menos que errorRateThresholdInPercent defina uma taxa (conferido em 9 de outubro de 2026).

A LoadFocus avalia as execuções com thresholds de aprovação ou reprovação salvos no teste: tempos de resposta p95 e p99 máximos, taxa de erros máxima e taxa mínima de requisições, cada um opcional. Cada execução recebe um selo PASS ou FAIL com os valores medidos e as metas, e uma API entrega o veredito a um pipeline. A LoadFocus roda cenários do k6 com taxa de chegada usando um número fixo de usuários, então ali um piso de taxa verifica o que esses usuários alcançaram.

FAQ

O tempo de resposta médio deve ser um critério de aprovação? Raramente. O livro de SRE prefere percentis: uma média esconde a cauda longa e pode ficar estável enquanto as requisições mais lentas ficam muito mais lentas.

Quantos critérios de aprovação um teste de carga deve ter? Um punhado de limites rígidos, mais avisos. O livro de SRE recomenda ter o menor número possível de SLOs e diz que, se citar um deles nunca ajuda a vencer uma discussão sobre prioridades, provavelmente não vale a pena mantê-lo. Aplique a mesma regra a cada limite de um teste de carga.

Um teste de carga pode passar com algumas requisições com falha? Sim, se a taxa de erros ficar abaixo do limite. Verifique o comportamento padrão da sua ferramenta: o Locust reprova a execução com uma única requisição com falha.

Leituras relacionadas

Teste de carga no GitHub Actions: guia prático

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Para fazer teste de carga no GitHub Actions basta um arquivo de workflow: instalar a ferramenta, rodar um teste curto contra uma URL de staging e deixar o código de saída da ferramenta reprovar o job quando um threshold não for atingido. Envie os resultados como artefato para que cada execução deixe registro. Mantenha o teste pequeno, porque um runner padrão hospedado pelo GitHub é uma única máquina virtual com poucos núcleos de CPU.

Os dados sobre as ferramentas e sobre o GitHub vêm da documentação de cada fornecedor, conferidos em 9 de outubro de 2026, e os workflows seguem esse uso documentado.

Ferramenta	Instalada por	O que reprova o job	Resultados para guardar
k6	`setup-k6-action` da Grafana	Um threshold não atingido	Saída em JSON
Artillery	`artilleryio/action-cli`	Uma verificação `ensure` que falhou	`report.json`
Locust	`pip install locust`	Qualquer requisição com falha, ou uma regra sua	Arquivos CSV e HTML
JMeter	O arquivo da versão	Nada embutido: adicione um passo de verificação	Arquivo `.jtl` e relatório HTML

Do que um workflow de teste de carga precisa?

De um gatilho, um runner, um passo que instala a ferramenta, um passo que roda o teste com thresholds e um passo que envia os resultados. O resto é opcional.

Guarde o script de teste no repositório, por exemplo em tests/load/. Leia a URL de staging de uma variável do repositório pelo contexto vars e defina timeout-minutes no job: o padrão é de 360 minutos (conferido em 9 de outubro de 2026).

Quais eventos devem disparar um teste de carga?

Rode um teste curto nos pull requests e um mais longo por agendamento ou manualmente.

Use pull_request para pegar uma regressão antes do merge, workflow_dispatch para execuções manuais e schedule para execuções cron (em UTC, a menos que você defina um fuso horário). A referência de eventos do GitHub traz alguns limites (conferido em 9 de outubro de 2026): agendamentos rodam só na branch padrão, no máximo a cada cinco minutos, e podem atrasar no começo de cada hora. Pull requests vindos de forks não recebem segredos além do GITHUB_TOKEN.

Como rodar o k6 no GitHub Actions?

Use as duas actions oficiais da Grafana, uma para instalar o k6 e outra para rodar o script. O passo falha sempre que o k6 termina com código de saída diferente de zero, que é o que um threshold não atingido provoca.

Tanto a setup-k6-action quanto a run-k6-action estão na v1 (conferido em 9 de outubro de 2026):

name: load-test
on:
  pull_request:
  workflow_dispatch:

jobs:
  k6:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    env:
      BASE_URL: ${{ vars.STAGING_URL }}
    steps:
      - uses: actions/checkout@v7
      - uses: grafana/setup-k6-action@v1
      - uses: grafana/run-k6-action@v1
        with:
          path: tests/load/smoke.js
          flags: --out json=results.json
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: k6-results
          path: results.json
          retention-days: 14

Os thresholds ficam no script, que lê BASE_URL do ambiente:

import http from "k6/http";

export const options = {
  vus: 10,
  duration: "1m",
  thresholds: {
    http_req_failed: ["rate<0.01"],
    http_req_duration: ["p(95)<500"],
  },
};

export default function () {
  http.get(`${__ENV.BASE_URL}/health`);
}

A documentação do k6 deixa claro que os checks não afetam o código de saída, então a decisão de aprovar ou reprovar precisa vir dos thresholds.

Como rodar Artillery, Locust ou JMeter no lugar?

Troque os passos de instalação e execução, mantenha o resto do workflow e use o mecanismo de cada ferramenta para falhar quando uma meta não for atingida.

Artillery tem uma GitHub Action oficial cujo README diz que a @v2 acompanha a versão 2.x mais recente (conferido em 9 de outubro de 2026). O passo é uses: artilleryio/action-cli@v2 com command: run --target ${{ vars.STAGING_URL }} tests/load/api.yml --output report.json, e o plugin ensure faz o Artillery sair com código diferente de zero quando uma meta não é atingida. A seção config do script:

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 5
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500

Locust sai com código 1 quando alguma requisição falhou, e para regras de latência você define environment.process_exit_code num listener do evento quitting, como mostra a mesma página (conferido em 9 de outubro de 2026). Depois de actions/setup-python@v7 com python-version: "3.13":

      - run: pip install locust
      - run: >
          locust -f tests/load/locustfile.py --headless
          -u 20 -r 5 -t 2m -H "$BASE_URL"
          --csv results --html report.html

JMeter roda sem interface gráfica com -n, e as opções de linha de comando do manual não incluem nenhum threshold de aprovação (conferido em 9 de outubro de 2026). Um passo curto pode ler o arquivo de resultados, em CSV com uma coluna success por padrão, e reprovar o job por conta própria:

      - uses: actions/setup-java@v6
        with:
          distribution: temurin
          java-version: "21"
      - name: Install JMeter 5.6.3
        env:
          JM_BASE: https://archive.apache.org/dist/jmeter/binaries
        run: curl -sSL "$JM_BASE/apache-jmeter-5.6.3.tgz" | tar -xzf -
      - name: Run the test plan
        run: >
          apache-jmeter-5.6.3/bin/jmeter -n -t tests/load/plan.jmx
          -l results.jtl -e -o report
      - name: Fail above 1% errors
        run: |
          python3 - <<'EOF'
          import csv, sys
          rows = list(csv.DictReader(open("results.jtl")))
          bad = sum(r["success"] != "true" for r in rows)
          print(f"{bad} of {len(rows)} samples failed")
          sys.exit(1 if not rows or bad > 0.01 * len(rows) else 0)
          EOF

Como fazer o job falhar quando o teste não atinge uma meta?

Escreva as metas no teste como thresholds e deixe o código de saída fazer o resto. O GitHub marca um passo como falho quando o comando dele termina com código diferente de zero, e o job falha junto.

Comece com uma taxa de erro rígida e um percentil de latência folgado, e aperte o limite de latência quando souber o quanto seus números variam de uma execução para outra. O guia passo a passo de teste de carga mostra como escolher essas metas.

Onde devem ficar os resultados de cada execução?

Envie-os como artefato do workflow, com if: always() para que um teste reprovado ainda guarde o relatório. Os artefatos ficam guardados por 90 dias por padrão, e retention-days encurta esse prazo.

O README da upload-artifact documenta os 90 dias padrão (conferido em 9 de outubro de 2026). Defina if-no-files-found: error para que um relatório ausente faça o passo falhar de forma visível.

Quanta carga um runner hospedado pelo GitHub consegue gerar?

O suficiente para um smoke test ou uma pequena checagem de regressão. Um runner Linux padrão tem 4 CPUs e 16 GB de RAM em repositórios públicos, 2 CPUs e 8 GB em privados, e um job para depois de 6 horas.

Esses números vêm da referência de runners e dos limites do Actions do GitHub (conferido em 9 de outubro de 2026), que não trazem nenhum número de largura de banda de rede.

Um job roda numa única máquina, então é um único gerador de carga: se a CPU dele satura, os tempos de resposta incluem o tempo de espera no próprio runner. Toda requisição também sai dessa máquina, então rate limiters que contam por endereço de cliente enxergam um único cliente muito ativo. O GitHub desaconselha colocar em allowlists as faixas de IP do Azure usadas pelos runners Ubuntu; runners maiores (larger runners) nos planos Team e Enterprise Cloud trazem mais CPU, mais memória e endereços IP estáticos.

Quando a carga deve vir de outro lugar?

Quando você precisa de mais carga do que uma máquina produz, de tráfego de várias regiões ou de execuções mais longas que o limite de um job.

Com k6, a run-k6-action roda o teste no Grafana Cloud k6 quando você define cloud-run-locally: false e passa K6_CLOUD_TOKEN, K6_CLOUD_PROJECT_ID e, com o k6 v2, K6_CLOUD_STACK_ID. Uma execução na nuvem ignora por padrão o ambiente do runner, então adicione -e BASE_URL=${{ vars.STAGING_URL }} a flags (conferido em 10 de outubro de 2026). A action do Artillery pode chamar run-fargate ou run-lambda para gerar a carga a partir da sua própria conta AWS (ambos conferidos em 9 de outubro de 2026). O comparativo k6 vs Artillery cobre os dois.

Para JMeter, a LoadFocus documenta uma integração com o GitHub Actions baseada no seu cliente npm. Você salva o teste na sua conta LoadFocus, guarda a chave de API e o ID do time como segredos e chama run-test. As flags abaixo seguem a ajuda do cliente:

      - run: npm install -g @loadfocus/loadfocus-api-client
      - env:
          LF_KEY: ${{ secrets.LOADFOCUS_API_KEY }}
          LF_TEAM: ${{ secrets.LOADFOCUS_TEAM_ID }}
        run: |
          test -n "$LF_KEY"
          test -n "$LF_TEAM"
          loadfocus-api config set \
            --apikey "$LF_KEY" --teamid "$LF_TEAM"
          loadfocus-api jmeter run-test --name checkout-api \
            --thresholds "avgresponse<=200,errors==0,p95<=250"

O cliente espera até 1.800 segundos por padrão (--wait-timeout muda isso), então dê ao job um timeout-minutes acima de 30, como 40. Ele sai com código 1 quando um threshold não é atingido e com 0 quando falta a chave de API ou o ID do time, por isso as linhas test -n fazem o passo falhar antes quando um segredo está vazio. A carga vem da LoadFocus, que roda scripts JMeter a partir de 25 regiões na nuvem.

FAQ

Quanto tempo deve durar um teste de carga num pull request? Alguns minutos: o bastante para passar da rampa de subida e obter um percentil estável, e pouco o bastante para ninguém ficar esperando.

É permitido fazer teste de carga a partir de runners hospedados pelo GitHub? Os termos do GitHub para o Actions proíbem perturbar qualquer serviço e limitam os runners hospedados ao trabalho no próprio projeto do repositório (conferido em 9 de outubro de 2026). Testar o ambiente de staging desse mesmo projeto, sem sobrecarregar os servidores do GitHub, é o tipo de teste que esses termos descrevem.

Posso usar um runner auto-hospedado no lugar? Sim. Ele roda no seu próprio hardware e na sua rede, e a página de limites do GitHub permite que um job dure até 5 dias nele. Ele continua sendo um único gerador de carga.

Leituras relacionadas

Teste de carga com Locust: análise da ferramenta Python

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

O Locust é uma ferramenta de teste de carga em Python, gratuita e sob licença MIT, em que cada teste é um programa Python, executado por usuários leves a partir de uma interface web ou da linha de comando. O teste de carga com Locust combina com equipes que escrevem Python e testam principalmente serviços HTTP. Quem precisa de muitos protocolos prontos para uso ou de um editor gráfico de testes fica mais bem servido pelo JMeter, e quem escreve JavaScript, pelo k6.

Não rodamos o Locust para esta análise. Os fatos vêm da documentação, do repositório e da página no PyPI do Locust, conferidos em 9 de outubro de 2026, e as avaliações são nossas.

Tema	Locust
Licença	MIT
Ambiente	Python 3.11 ou mais recente
Versão atual	2.46.7 (4 de outubro de 2026)
Formato dos testes	Classes Python em um locustfile
Execução	Interface web na porta 8089, ou headless
Protocolos embutidos	HTTP e HTTPS
Escala	Um master e quantos workers forem necessários
Resultados	Gráficos ao vivo, CSV, HTML, JSON, OpenTelemetry
CI	Código de saída 1 se alguma requisição falhar

Quem desenvolve o Locust, e ele ainda é mantido?

Lars Holmberg mantém o Locust, e a Microsoft patrocina esse trabalho. As versões saem com frequência: 17 até agora em 2026.

O README do Locust cita os dois. O PyPI mostra a 2.46.7, publicada em 4 de outubro de 2026, como a versão mais recente, e exige Python 3.11 ou mais recente (conferido em 9 de outubro de 2026).

Como funciona um locustfile?

Um locustfile é um módulo Python comum com pelo menos uma classe de usuário. Cada usuário simulado executa suas tarefas uma após a outra e faz uma pausa entre elas, conforme o seu wait_time.

Segundo o guia do locustfile, o HttpUser dá a cada usuário um client que encapsula o python-requests, mantém os cookies e registra cada requisição. Os métodos marcados com @task são sorteados, com peso dado pelo número no decorator, e o on_start roda uma vez por usuário. Este usuário faz login, navega pelo catálogo quatro vezes mais do que finaliza compras e inicia no máximo uma tarefa a cada 10 segundos:

from locust import HttpUser, task, constant_pacing


class Shopper(HttpUser):
    wait_time = constant_pacing(10)

    def on_start(self):
        self.client.post("/login", json={"user": "demo"})

    @task(4)
    def browse(self):
        self.client.get("/products?page=2", name="/products")

    @task
    def checkout(self):
        with self.client.post(
            "/checkout", catch_response=True
        ) as resp:
            if "order_id" not in resp.text:
                resp.failure("no order id")

O catch_response permite marcar uma requisição como falha pelo conteúdo, e o name agrupa URLs variáveis em uma única linha das estatísticas. As outras funções de espera são constant, between, constant_throughput e, desde a versão 2.46.6, poisson; nosso guia sobre tempo de pensamento em teste de carga explica como essas pausas moldam a carga. A documentação acrescenta que o tempo de espera só consegue limitar a vazão e não inicia novos usuários para atingir uma taxa-alvo. Um teste do Locust é, portanto, um grupo fixo de usuários: um modelo de carga fechado.

É melhor usar a interface web ou o modo headless?

Use a interface web enquanto explora e o modo headless para execuções repetíveis.

O comando locust sobe uma interface web na porta 8089. Nela você define o host, os usuários e a rampa de subida, acompanha gráficos ao vivo e muda a carga no meio do teste. O modo headless recebe as mesmas configurações como opções:

locust -f locustfile.py --headless -u 200 -r 10 -t 10m \
  --host https://staging.example.com \
  --csv results --html report.html

-u define os usuários, -r quantos começam por segundo e -t a duração, já contando a rampa de subida. As mesmas opções também funcionam em locust.conf ou pyproject.toml.

Como funciona o modo distribuído?

Um processo master cuida da interface web e coordena, enquanto processos worker executam os usuários e devolvem as estatísticas. Você precisa de um worker por núcleo de CPU, porque um processo Python não consegue aproveitar totalmente mais de um núcleo.

Segundo a documentação de carga distribuída, um único processo passa de mil requisições por segundo com um plano de teste simples, então testes maiores são distribuídos:

# na máquina master
locust -f locustfile.py --master
# em cada máquina worker, um worker por núcleo
locust -f - --worker --master-host 10.0.0.5 --processes -1

-f - busca o locustfile no master. O --processes depende de fork() e por isso não funciona no Windows, e toda mudança no locustfile exige reiniciar todos os processos. A documentação também cobre um operador para Kubernetes e o Azure Load Testing (conferido em 9 de outubro de 2026).

A LoadFocus, que publica este site, não roda testes do Locust. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem, então para o Locust os caminhos acima continuam sendo as formas de escalar.

O Locust consegue testar protocolos além de HTTP?

Sim, desde que você traga um cliente Python para o protocolo. Só HTTP e HTTPS vêm embutidos.

A página sobre outros protocolos mostra como encapsular um cliente para que cada chamada seja registrada, com exemplos para XML-RPC e gRPC e classes de usuário experimentais para MQTT, Socket.IO e OpenAI. O projeto separado locust-plugins adiciona usuários para Kafka, FTP, Selenium e Playwright (conferido em 9 de outubro de 2026).

Para HTTP existe ainda o FastHttpUser, que usa o geventhttpclient e consome bem menos CPU. No melhor caso, segundo a documentação, um processo chega a cerca de 16.000 requisições por segundo, contra 4.000 com o HttpUser. O FastHttpUser não deixa cada requisição mais rápida e, por padrão, não verifica certificados TLS.

Que relatórios o Locust entrega, e como ele entra na CI?

Você recebe gráficos ao vivo na interface web e, se pedir, arquivos de resultados. Na CI, o Locust sai com código 1 se alguma requisição falhou.

Pela referência de configuração, --csv grava arquivos de estatísticas, histórico e falhas, --html salva um relatório e --json imprime as estatísticas finais. O --otel exporta para um backend OpenTelemetry. A documentação do modo headless mostra um listener que reprova a execução pela taxa de falhas, pelo tempo de resposta médio ou pelo percentil 95, e nosso guia de teste de carga no GitHub Actions o coloca em um workflow.

O que o Locust faz bem, e onde estão seus limites?

Ele se destaca na lógica dos testes e com muitos usuários simultâneos que passam a maior parte do tempo esperando. Fica mais fraco na taxa de requisições por processo e nos protocolos que você precisa conectar por conta própria.

Como os testes são Python puro, laços, condições, dados gerados e o seu próprio cliente de API funcionam normalmente, e os testes ficam no controle de versão. A página What is Locust diz que o baixo custo de cada usuário combina com cargas muito concorrentes, mas admite que outras ferramentas podem enviar mais requisições por segundo no mesmo hardware.

Os limites que a própria documentação reconhece:

Um processo Python usa um único núcleo de CPU.
Bibliotecas que fazem E/S em C bloqueiam o processo, a menos que o gevent consiga aplicar patch nelas.
O HttpUser não interpreta HTML nem carrega os recursos da página.
O tempo de espera não consegue adicionar usuários para manter uma taxa de requisições.

Que outras ferramentas Python existem para teste de carga?

O Locust é o motor Python em desenvolvimento ativo. O Molotov, a principal alternativa, não lança nenhuma versão no PyPI desde 2022, e o Taurus roda o Locust por um de seus executores.

O Molotov é uma ferramenta para Python 3.8+ construída sobre asyncio e aiohttp; a versão mais recente no PyPI é a 2.6, de 21 de outubro de 2022, e o último commit do branch principal é de novembro de 2023 (conferido em 21 de outubro de 2026). O Taurus roda um locustfile, ou requisições GET e POST simples escritas em YAML, pelo executor locust. Você instala o Locust por conta própria, em modo distribuído o Taurus inicia só o master e a configuração throughput não tem efeito nesse executor (conferido em 21 de outubro de 2026).

Quando escolher k6, JMeter ou Gatling em vez do Locust?

Escolha outra ferramenta quando a linguagem, os protocolos ou o modelo de carga dela combinarem melhor com a sua equipe.

Nosso panorama de ferramentas de teste de carga open source coloca o Locust ao lado de outras cinco.

Prefira o k6 quando sua equipe escreve JavaScript, quer critérios de aprovação como thresholds no próprio script ou precisa de um modelo de carga aberto, que é o que os executores arrival-rate do k6 oferecem (conferido em 9 de outubro de 2026). A LoadFocus roda scripts k6 a partir de 25 regiões na nuvem, mas executa cenários arrival-rate com um número fixo de usuários; para manter uma taxa de requisições, rode-os com o próprio k6.

Prefira o JMeter quando você precisa de JDBC, JMS, LDAP ou FTP prontos para uso, como lista o README dele, ou quando seus testadores montam os testes em uma interface gráfica. Locust vs JMeter compara os dois em detalhe.

Prefira o Gatling quando sua equipe trabalha na JVM e quer perfis de injeção abertos e fechados em uma mesma API (conferido em 9 de outubro de 2026). Gatling vs JMeter trata disso com mais detalhe.

FAQ

O Locust é gratuito para uso comercial? Sim. O Locust é distribuído sob a licença MIT, que permite uso comercial, modificação e redistribuição.

Qual versão do Python o Locust exige? Python 3.11 ou mais recente, segundo os metadados no PyPI. Instale com pip install locust, ou rode em um ambiente temporário com uvx locust.

A LoadFocus consegue rodar testes do Locust? Não. A LoadFocus roda planos de teste JMeter e scripts k6. Para escalar um teste do Locust, use o modo master e workers, o operador para Kubernetes ou o Azure Load Testing.

Leituras relacionadas

Locust vs JMeter: scripts Python ou planos do JMeter?

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

Locust e Apache JMeter são ferramentas de teste de carga gratuitas e open source, e a melhor escolha depende principalmente de como o seu time quer construir os testes. Escolha o Locust se o seu time escreve Python e quer a lógica do teste como código comum, executada por usuários leves e baseados em eventos. Escolha o JMeter se você precisa de protocolos além de HTTP, como JDBC, JMS ou LDAP, prefere montar os testes em uma interface gráfica ou já tem uma coleção de planos de teste .jmx.

Os dados desta comparação Locust vs JMeter vêm da documentação e do repositório de cada projeto, conferidos em 9 de outubro de 2026.

	Locust	Apache JMeter
Licença	MIT (repositório)	Apache 2.0 (repositório)
Ambiente de execução	Python 3.11 ou mais recente	Java 8 ou mais recente (versão 5.6.3)
Testes escritos como	Código Python em um locustfile	Planos de teste montados em uma interface gráfica e salvos como XML (`.jmx`)
Interface gráfica	Interface web para iniciar, ajustar e acompanhar um teste em andamento	IDE desktop para gravar, montar e depurar planos de teste
Protocolos embutidos	HTTP e HTTPS; os demais por meio de um cliente Python	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, e-mail, TCP, comandos de shell, objetos Java
Usuários virtuais	Um greenlet por usuário sobre o gevent (baseado em eventos)	Uma thread Java por usuário
Modo distribuído	Um master e quantos workers você quiser	Um cliente que controla servidores JMeter remotos
CI e execução sem interface	`--headless`, código de saída 1 quando requisições falham	Modo CLI (`jmeter -n`)
Relatórios	Gráficos ao vivo na interface web, arquivos CSV, relatório HTML	Dashboard HTML, resultados ao vivo com um Backend Listener

Qual é a diferença entre Locust e JMeter?

No Locust, um teste é um programa Python. No JMeter, um teste é um plano que você monta em uma interface gráfica desktop e salva em um arquivo, e quase todas as outras diferenças vêm daí.

O README do Locust descreve testes escritos com laços, condições e bibliotecas comuns de Python. Ele é instalado com pip install locust e precisa do Python 3.11 ou mais recente, segundo os metadados do pacote.

Um teste do JMeter é uma árvore de elementos: um Thread Group para os usuários, samplers para as requisições e assertions e listeners para os resultados. O JMeter 5.6.3, versão atual na página de download, exige Java 8 ou mais recente. O README do branch de desenvolvimento do JMeter já exige Java 17 (conferido em 10 de outubro de 2026). Quando um passo precisa de lógica de verdade, um sampler JSR223 roda um script Groovy dentro do plano.

Como se escreve um teste em cada ferramenta?

No Locust, você escreve uma classe Python para cada tipo de usuário, com métodos marcados como tarefas. No JMeter, você adiciona um Thread Group e samplers na interface gráfica, salva o plano e roda esse arquivo pela linha de comando.

Um usuário do Locust que espera de um a três segundos entre as tarefas e consulta a lista de usuários três vezes mais do que abre um usuário específico:

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def list_users(self):
        self.client.get("/api/users")

    @task
    def view_user(self):
        self.client.get("/api/users/42", name="/api/users/[id]")

Para rodar sem interface com 50 usuários, cinco novos por segundo, durante cinco minutos:

locust -f locustfile.py --headless -u 50 -r 5 \
  --run-time 5m --host https://staging.example.com

No JMeter, o mesmo teste é um Thread Group com 50 threads e um período de rampa de subida, contendo dois samplers HTTP Request. O guia de primeiros passos roda um plano salvo no modo CLI, e -e -o acrescenta o relatório HTML no final:

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

O arquivo .jmx é XML, como mostram os exemplos que vêm com o JMeter, e é mais difícil de revisar em um pull request do que um arquivo Python. O JMeter também grava um plano a partir do navegador; o equivalente no Locust é o har2locust, um conversor de gravações HAR em locustfile que ainda está em beta (conferido em 9 de outubro de 2026).

Quais protocolos cada ferramenta consegue testar?

O JMeter cobre muito mais protocolos de fábrica. O Locust vem com HTTP e HTTPS e espera que você traga um cliente Python para todo o resto.

O README do JMeter lista HTTP e HTTPS, SOAP e REST, FTP, bancos de dados via JDBC, LDAP, mensageria JMS, e-mail por SMTP, POP3 e IMAP, TCP, comandos nativos e objetos Java. JDBC e JMS precisam dos JARs de driver fornecidos pelo seu fornecedor de banco de dados ou de JMS.

A página sobre outros protocolos da documentação do Locust mostra como encapsular uma biblioteca de protocolo, com exemplos para gRPC, XML-RPC e MQTT, e indica o locust-plugins para Kafka, Selenium e Playwright (conferido em 9 de outubro de 2026). A biblioteca precisa funcionar com o gevent, porque E/S feita em código C compilado bloqueia o processo inteiro; a documentação cita o driver de PostgreSQL psycopg2, que precisa de um pacote extra. Para testes de carga em bancos de dados, o sampler JDBC do JMeter é o caminho mais curto.

Como funcionam os usuários virtuais no Locust e no JMeter?

O JMeter executa cada usuário virtual como uma thread Java. O Locust executa cada usuário como um greenlet no loop de eventos do gevent, o que mantém baixo o custo de cada usuário.

Cada thread de um Thread Group do JMeter percorre o plano inteiro de forma independente. O JMeter inicia por padrão com um heap de 1 GB, que segundo o guia pode não bastar para planos maiores e muitas threads.

Segundo o README, um único processo do Locust consegue lidar com muitos milhares de usuários simultâneos. A documentação de carga distribuída acrescenta que um processo Python não aproveita totalmente mais de um núcleo de CPU, então você roda um worker por núcleo, algo que o --processes configura para você em uma única máquina.

Como distribuir um teste entre várias máquinas?

As duas têm um modo distribuído embutido. No Locust, um master comanda os workers que executam os usuários, e no JMeter o cliente inicia o plano de teste completo em cada servidor remoto.

No Locust, um processo iniciado com --master roda a interface web e avisa os processos --worker quando iniciar e parar usuários. A documentação do Locust também cobre um operador para Kubernetes e o Azure Load Testing, um serviço da Microsoft que executa testes do Locust na nuvem (conferido em 9 de outubro de 2026).

O modo de teste remoto do JMeter permite que um cliente controle quantos servidores você quiser via RMI. Cada servidor roda o plano inteiro, então 1.000 threads em seis servidores viram 6.000 threads. Todos os nós devem rodar a mesma versão do JMeter e do Java, o RMI precisa de um keystore a menos que o SSL esteja desativado, e arquivos de dados precisam ser copiados para cada servidor.

Existe um terceiro caminho para planos de teste do JMeter. A LoadFocus, que publica este site, roda planos de teste JMeter existentes sem alterações a partir de 25 regiões na nuvem, sem servidores remotos para configurar. A LoadFocus não roda testes do Locust, então para o Locust as opções acima continuam sendo as formas de escalar.

Como eles entram na CI e quais relatórios você recebe?

Os dois rodam sem interface pela linha de comando. O Locust ainda termina com código de saída 1 quando requisições falham, e o JMeter gera o relatório HTML mais completo.

A documentação do modo headless do Locust mostra um listener de eventos curto que define o código de saída pela taxa de falhas, pelo tempo de resposta médio ou pelo percentil 95, além de um exemplo para GitHub Actions. As opções --csv e --html salvam os resultados e um relatório ao final da execução.

A documentação do JMeter é categórica: testes de carga rodam no modo CLI, e a interface gráfica fica para montar e depurar. O README indica bibliotecas de terceiros para Maven, Gradle e Jenkins. O dashboard do JMeter traz uma tabela APDEX, uma tabela de estatísticas com três percentis configuráveis, resumos de erros e gráficos do tempo de resposta.

Qual você deve escolher?

Escolha o Locust se o seu time escreve Python e quer revisar os testes de carga como o resto do código. Escolha o JMeter em vez dele se você precisa de protocolos além de HTTP, se os seus testers preferem uma interface gráfica ou se você já tem planos .jmx.

O Locust combina com cenários que têm laços, ramificações e dados gerados, com testes que reaproveitam um cliente Python interno da sua API e com alta concorrência de usuários que passam a maior parte do tempo esperando.

O JMeter é a melhor escolha para testar JDBC, JMS, LDAP, FTP ou e-mail, onde o Locust exigiria um cliente mantido por você, e para testers que gravam um fluxo no navegador e o refinam visualmente. Uma empresa que já usa o JMeter também preserva seus planos e seu conhecimento.

FAQ

O Locust é mais rápido que o JMeter? Não medimos isso nós mesmos, então não vamos apontar um vencedor. A comparação justa é rodar o mesmo cenário com as duas ferramentas no seu próprio hardware.

O Locust consegue rodar arquivos .jmx do JMeter? Não, segundo a documentação, que descreve os testes apenas como locustfiles em Python. Levar um plano de teste do JMeter para o Locust significa reescrevê-lo em Python.

A LoadFocus consegue rodar testes do Locust? Não. A LoadFocus roda scripts JMeter e k6. Para escalar um teste do Locust além de uma máquina, use o modo master e workers do Locust, o operador para Kubernetes ou o Azure Load Testing.

Leituras relacionadas

Modelo de carga aberto vs fechado: qual usar e quando

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Escolher um modelo de carga aberto vs fechado depende principalmente de como os usuários chegam ao seu sistema. Use um modelo aberto, que inicia novas iterações a uma taxa de chegada definida, para sites e APIs públicos em que os usuários continuam chegando por mais lento que você responda, e um modelo fechado, um número fixo de usuários virtuais que esperam cada um o fim da iteração anterior, só onde o próprio sistema limita a concorrência. A escolha pesa mais na saturação, quando um teste fechado freia a própria carga e faz o sistema parecer mais saudável do que está.

Os fatos sobre as ferramentas vêm da documentação de cada projeto, conferida em 9 de outubro de 2026.

	Modelo aberto	Modelo fechado
O que você define	Novas iterações ou usuários por segundo	Usuários virtuais simultâneos
Quando as respostas ficam lentas	O trabalho continua chegando e as filas crescem	Os usuários esperam e menos carga é enviada
Sistemas reais assim	A maioria dos sites e APIs públicos	Call centers, filas de venda de ingressos, pools de workers
k6	`constant-arrival-rate`, `ramping-arrival-rate`	`constant-vus`, `ramping-vus`
Gatling	`injectOpen`	`injectClosed`
Locust	Aproximado com `constant_throughput` ou `poisson`	Usuários com um `wait_time`
JMeter	Open Model Thread Group, plugin Arrivals	Thread Group

Qual é a diferença entre um modelo de carga aberto e um fechado?

No modelo aberto, quem decide quando o trabalho chega é o gerador de carga, e no fechado é o tempo de resposta do sistema.

A documentação do k6 diz isso com clareza: no modelo fechado, a próxima iteração de um usuário virtual só começa quando a anterior termina, enquanto no modelo aberto as novas iterações chegam sem depender do fim das anteriores (conferido em 9 de outubro de 2026). Um teste fechado com 50 usuários virtuais nunca tem mais de 50 iterações em andamento. Um teste aberto a 50 iterações por segundo dispara mais 50 a cada segundo, e se cada uma demora mais, mais delas se sobrepõem.

Por que um modelo fechado esconde a latência quando o sistema satura?

Porque o teste fica lento junto com o sistema. Quando as respostas demoram mais, cada usuário de um modelo fechado envia menos requisições, e a carga cai bem na hora em que você queria vê-la subir.

A documentação do k6 descreve o efeito: respostas mais lentas significam iterações mais longas e uma taxa de chegada menor de iterações novas. A página do Gatling sobre modelos de carga vai além e diz que usar um modelo fechado contra um sistema que na verdade é aberto é um teste quebrado, que mede um comportamento imaginário (conferido em 9 de outubro de 2026).

Por isso um teste fechado mostra tempos de resposta que se estabilizam, já que nunca pode haver mais requisições em andamento do que usuários. Um teste aberto mostra a fila crescendo, com tempos de resposta que sobem enquanto as chegadas superam o que o sistema processa. Essa segunda imagem é a que seus usuários veriam, e os tempos de resposta p95 e p99 que você lê no fim só são tão confiáveis quanto o modelo de carga que os produziu.

A documentação do k6 observa que parte da literatura sobre testes chama esse problema de coordinated omission. Um artigo da USENIX de 2006 citado pela documentação do Gatling, Open Versus Closed: A Cautionary Tale, concluiu que os dois modelos dão resultados bem diferentes mesmo com a mesma carga e as mesmas demandas de serviço.

Qual modelo combina com o seu tráfego real?

Escolha um modelo aberto para tudo que o público consegue acessar, e um fechado só onde o próprio sistema limita quantos usuários ficam ativos ao mesmo tempo.

A documentação do Gatling cita como sistemas fechados os call centers com todos os atendentes ocupados e os sites de venda de ingressos que colocam os usuários em fila quando lotam, e diz que a maioria dos sites se comporta como sistema aberto. Um job em lote com um número fixo de workers, ou um consumidor de fila com concorrência definida, também é fechado. APIs públicas, páginas web e webhooks são abertos: nada segura a próxima requisição porque a anterior foi lenta.

Muitos sistemas ficam no meio do caminho: uma compradora chega no próprio ritmo e depois espera cada página durante a visita. O artigo citado chama isso de modelo parcialmente aberto. No k6 ou no Gatling, defina a taxa de chegada das sessões e faça de cada iteração uma jornada de usuário completa, com as próprias pausas.

Como configurar cada modelo no k6?

Pelo executor. constant-vus e ramping-vus dão um modelo fechado, e constant-arrival-rate e ramping-arrival-rate dão um aberto.

Um cenário fechado define executor: "constant-vus" com um número de vus e uma duration. Um cenário aberto define uma taxa, e você pré-aloca usuários virtuais suficientes para sustentá-la:

export const options = {
  scenarios: {
    open_model: {
      executor: "constant-arrival-rate",
      rate: 50,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 100,
    },
  },
  thresholds: {
    dropped_iterations: ["count<10"],
  },
};

O k6 só inicia uma iteração enquanto tem um usuário virtual livre, e a documentação desaconselha depender de maxVUs, porque adicionar usuários no meio do teste pode sobrecarregar o gerador de carga. Quando nenhum usuário está livre, o k6 registra uma iteração descartada, o que, já perto do fim de um teste, costuma indicar que o sistema está ficando lento. O limite acima faz a execução falhar ao chegar a dez. Não coloque sleep() no fim de uma iteração com taxa de chegada, porque o executor já cadencia os inícios (conferido em 9 de outubro de 2026).

Se você roda scripts k6 na LoadFocus, a execução de k6 na nuvem da plataforma usa a carga definida nas configurações do teste, e o validador de scripts avisa que cenários com taxa de chegada rodam ali com um número fixo de usuários, então a taxa de requisições não é mantida. Para um teste de verdade com modelo aberto, rode os executors de taxa de chegada com o próprio k6, ou em um serviço que os execute do jeito que foram escritos.

Como Gatling, Locust e JMeter expressam cada modelo?

O Gatling separa os dois modelos na API, o JMeter oferece os dois por meio de thread groups diferentes, e o Locust é construído em torno de um número fixo de usuários.

Gatling. Um cenário usa injectOpen ou injectClosed. Passos abertos como constantUsersPerSec e rampUsersPerSec definem taxas de chegada, e passos fechados como constantConcurrentUsers e rampConcurrentUsers definem a concorrência. Um mesmo perfil de injeção não pode misturar os dois (conferido em 9 de outubro de 2026).

Locust. Você define um número de usuários, e o wait_time de cada usuário controla a pausa entre tarefas. constant_throughput e constant_pacing ajustam essa pausa para que cada usuário rode no máximo um número definido de tarefas por segundo, mas a documentação diz que o tempo de espera só consegue limitar a vazão e não inicia novos usuários para atingir uma meta. poisson() sorteia pausas aleatórias, que a documentação considera mais próximas das chegadas reais. O exemplo da documentação para 500 iterações de tarefa por segundo é constant_throughput(0.1) com 5.000 usuários, um pool fechado com bastante folga (conferido em 9 de outubro de 2026).

JMeter. O Thread Group clássico é um pool fechado de threads. Os timers Constant Throughput e Precise Throughput cadenciam esse pool rumo a uma taxa alvo, e a referência avisa que a vazão cai se o servidor não der conta ou se faltarem threads. Para chegadas, o JMeter 5.5 adicionou o Open Model Thread Group, ainda marcado como experimental, com agendas como rate(10/sec) random_arrivals(1 min). O plugin da comunidade Arrivals Thread Group inicia novas threads quando todas as existentes estão ocupadas, com um limite de concorrência como válvula de segurança (conferido em 9 de outubro de 2026).

O que observar em um teste com modelo aberto?

Observe o gerador de carga tão de perto quanto o sistema sob teste. No modelo aberto, um sistema lento significa mais usuários simultâneos do seu lado, e isso custa memória e CPU.

Defina um teto, como maxVUs no k6 ou o limite de concorrência do plugin do JMeter, e trate atingi-lo como um resultado: o sistema não conseguiu absorver a taxa que você pediu.

FAQ

Um modelo de carga fechado é a escolha certa em algum caso? Sim. Use-o quando o sistema real limita a concorrência, como um pool fixo de workers, um consumidor de fila ou um call center, ou quando você quer saber quantas sessões simultâneas um componente aguenta. Para tráfego web público, um modelo aberto se encaixa melhor.

Adicionar tempo de pensamento transforma um modelo fechado em aberto? Não. O tempo de pensamento reduz a frequência com que cada usuário envia requisições, mas cada usuário continua esperando a resposta anterior, então um sistema lento ainda freia o teste. Só uma taxa de chegada definida independentemente dos tempos de resposta gera um modelo aberto.

Quantos usuários virtuais um teste com taxa de chegada precisa? O suficiente para cobrir todas as iterações em andamento ao mesmo tempo. A documentação do k6 sugere a mediana da duração de uma iteração multiplicada pela taxa alvo, mais uma margem para a variação, ajustada com testes curtos antes do teste completo.

Leituras relacionadas

Tempo de pensamento em teste de carga: como definir

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Tempo de pensamento em teste de carga é a pausa que um usuário virtual faz entre duas ações, representando os segundos que uma pessoa real passa lendo uma página ou preenchendo um formulário. Ele decide quanta pressão cada usuário virtual exerce: quanto mais longa a pausa, menos requisições por segundo o mesmo número de usuários envia. Meça o valor com dados de usuários reais, varie-o aleatoriamente em torno desse valor e escreva-o no script com o comando de pausa da sua ferramenta.

Tempo de pensamento por volta	Uma volta leva	Requisições por segundo com 100 usuários
0 s	0,5 s	200
1 s	1,5 s	cerca de 67
3 s	3,5 s	cerca de 29
5 s	5,5 s	cerca de 18
10 s	10,5 s	cerca de 10

É só aritmética, sem nenhum teste por trás: uma requisição por volta, uma resposta em 0,5 segundo, e o número de usuários dividido por (tempo de resposta + tempo de pensamento).

O que é tempo de pensamento em teste de carga?

Tempo de pensamento é a espera proposital que um script de teste insere entre os passos de uma jornada de usuário. Ele reproduz a parte humana de uma sessão: ler, comparar, digitar.

No script de uma loja, ele fica entre "abrir a página do produto" e "adicionar ao carrinho", fora de qualquer requisição. O guia da LoadFocus sobre atrasos em teste de carga separa esse tempo do atraso de rampa, que adiciona usuários aos poucos, e do atraso de início entre um usuário e o próximo, e observa que muitas ferramentas chamam de "delay", sem mais nada, o atraso de rampa. Quando uma ferramenta oferecer um campo "delay", confira a qual dos três ele se refere.

Por que o tempo de pensamento muda a carga com o mesmo número de usuários?

Com um número fixo de usuários virtuais, cada um espera uma resposta, faz uma pausa e só então envia a próxima requisição. A volta dele leva o tempo de resposta mais o tempo de pensamento, então cada segundo de pausa a mais reduz as requisições que cada usuário envia por segundo.

Cem usuários sem pausa enviam 200 requisições por segundo com uma resposta de 0,5 segundo; com uma pausa de 5 segundos enviam cerca de 18, de modo que duas execuções "com 100 usuários" podem ser testes bem diferentes. A documentação do k6 descreve o mesmo efeito para o seu modelo fechado: a próxima iteração só começa quando a anterior termina, então respostas mais lentas também reduzem o ritmo (conferido em 9 de outubro de 2026).

Cortar o tempo de pensamento para tirar mais carga de menos usuários tem um custo: vinte usuários sem pausas podem igualar o ritmo de requisições de várias centenas que fazem pausas, mantendo abertas muito menos sessões e conexões do que a produção.

Qual é a diferença entre tempo de pensamento e pacing?

Tempo de pensamento é uma pausa depois de um passo, então uma volta fica mais longa sempre que as respostas ficam lentas. Pacing fixa o intervalo entre o início de uma volta e o início da seguinte, e encurta a espera quando o trabalho demorou mais.

Com pacing de 30 segundos, um usuário começa uma volta a cada 30 segundos, quer as requisições tenham levado 2 segundos ou 20, o que combina com testes montados a partir de volumes de negócio como "500 pedidos por hora". A documentação do constant_pacing do Locust explica o caso extremo: se a tarefa durar mais que o intervalo, a espera cai para zero (conferido em 9 de outubro de 2026). Muitos scripts usam os dois, com tempo de pensamento entre os passos e pacing na volta inteira.

O tempo de pensamento deve ser fixo ou aleatório?

Aleatório, em torno de uma média que você mediu. Uma pausa fixa mantém no mesmo passo os usuários que começaram juntos, que chegam à mesma página no mesmo momento, volta após volta.

Essas ondas sincronizadas podem criar picos que a produção nunca vê, e uma pausa aleatória espalha os usuários. Mantenha a média onde seus dados a colocam: uma pausa uniforme entre 2 e 8 segundos dá 5 em média, a mesma carga média de uma pausa fixa de 5 segundos. A distribuição uniforme é a escolha simples por padrão; uma normal (gaussiana) agrupa as pausas em torno de um valor típico, e uma exponencial gera muitas esperas curtas e algumas longas.

Como escolher os valores do tempo de pensamento?

Tire-os do que os usuários reais fazem em cada passo, usando sua ferramenta de analytics, os logs de acesso ou uma ferramenta de monitoramento de usuários reais (RUM). Use um valor diferente por passo, porque ler a página de um produto leva mais tempo do que apertar um botão.

O tempo na página registrado pelo analytics, ou o intervalo entre requisições consecutivas de uma mesma sessão nos logs de acesso, se aproxima do tempo de pensamento daquele passo. Use a mediana como pausa média e a dispersão para definir a faixa aleatória, e descarte os tempos ociosos, como uma aba esquecida aberta durante o almoço.

Uma API chamada por outros programas não tem ninguém humano no circuito, então modele diretamente o ritmo de requisições dela. Sem dados, anote no plano de teste os valores que você supôs, para que uma execução futura os substitua; o guia passo a passo para fazer um teste de carga mostra onde eles entram.

Como adicionar tempo de pensamento no k6, JMeter, Gatling, Locust e Artillery?

Cada ferramenta tem seu próprio comando de pausa, e a maioria também oferece pacing ou controle de ritmo.

Ferramenta	Pausa fixa	Pausa aleatória	Pacing ou ritmo
k6	`sleep(3)`	`sleep(2 + Math.random() * 6)`	Executores por taxa de chegada
JMeter	Constant Timer	Uniform ou Gaussian Random Timer	Constant Throughput Timer
Gatling	`pause(3)`	`pause(2, 8)`	`pace(30)`
Locust	`constant(3)`	`between(2, 8)`	`constant_pacing`
Artillery	`think: 3`	`think` + `jitter` (em `config.http.defaults`)	Taxa de chegada por fase

Os fatos da tabela acima e das notas abaixo vêm da documentação de cada projeto, conferidos em 9 de outubro de 2026; as cinco ferramentas aparecem na nossa análise de ferramentas de teste de carga open source.

k6. sleep(t) pausa o usuário virtual por t segundos; a documentação monta pausas aleatórias com Math.random() ou com randomIntBetween() do k6-utils:

import http from "k6/http";
import { sleep } from "k6";

export default function () {
  http.get("https://example.com/products");
  sleep(2 + Math.random() * 6); // de 2 a 8 segundos
  http.get("https://example.com/cart");
}

JMeter. Entre os timers, o Constant Timer recebe um atraso em milissegundos, os Uniform e Gaussian Random Timers somam uma parte aleatória a um deslocamento fixo, e o Constant Throughput Timer varia suas pausas para manter uma meta de amostras por minuto. Um timer roda antes de cada sampler do seu escopo, então um único timer no nível do Thread Group pausa antes de cada requisição.

Gatling. pause(2, 8) espera um tempo aleatório uniforme, e pace(30) dentro de um laço o executa no máximo uma vez a cada 30 segundos. No nível da simulação, você pode passar todas as pausas para uma distribuição normal ou exponencial, ou desligá-las com disablePauses().

Locust. O wait_time vale depois de cada tarefa, então uma tarefa com duas requisições sob constant_throughput(2) envia quatro requisições por segundo por usuário.

Artillery. Um passo think pausa por um número de segundos, e uma configuração think.jitter em config.http.defaults adiciona variação aleatória a cada passo think. Para ver duas dessas ferramentas lado a lado, leia k6 vs Artillery.

O tempo de pensamento importa num teste por taxa de chegada?

Menos, no que diz respeito ao ritmo de requisições. Quando a ferramenta inicia novas iterações num ritmo fixo, as pausas decidem quanto tempo cada usuário fica e, portanto, quantos estão ativos ao mesmo tempo.

Os executores por taxa de chegada do k6 ditam o ritmo das iterações pela taxa, e a documentação desaconselha um sleep no fim da iteração; as fases de carga do Artillery também criam um número fixo de novos usuários virtuais por segundo (ambos conferidos em 9 de outubro de 2026). O tempo de pensamento entre os passos continua moldando cada sessão.

Como as ferramentas de script da LoadFocus definem o tempo de pensamento?

Elas o escrevem no script do k6 ou do JMeter como valor inicial, para você ajustar depois.

A importação de cURL, HAR, Postman ou OpenAPI transforma uma requisição capturada em um script do k6 que termina cada iteração com sleep(1); trate esse segundo como um valor provisório a substituir pelas suas medições. O gerador de testes com IA da LoadFocus é instruído a dar a cada passo um tempo de pensamento, escreve esse tempo como sleep() para o k6 ou como Constant Timer para o JMeter, e avisa quando um cenário com vários passos não tem nenhum.

FAQ

Dá para rodar um teste de carga sem tempo de pensamento? Sim, para encontrar a vazão máxima de um endpoint ou num teste de estresse, desde que você apresente o resultado em requisições por segundo. Ele diz pouco sobre quantos usuários reais o sistema consegue atender.

O tempo de pensamento entra no tempo de resposta? Não nos tempos de cada requisição. No k6, http_req_duration cobre o envio, a espera e o recebimento, enquanto iteration_duration cobre a volta inteira (referência de métricas, conferido em 9 de outubro de 2026). Um Transaction Controller do JMeter deixa os timers fora do seu tempo, a menos que você marque a opção que os inclui.

Leituras relacionadas

Ferramentas de teste de carga WebSocket: seis opções

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

Entre as ferramentas de teste de carga WebSocket, k6, Artillery, Gatling e Tsung suportam o protocolo de fábrica, enquanto o JMeter precisa do plugin WebSocket Samplers e o Locust precisa de código cliente escrito por você ou do seu usuário experimental de Socket.IO. Escolha pela linguagem em que o seu time escreve e, depois, pelo rigor com que você precisa verificar as mensagens que o servidor devolve.

Para este artigo, não rodamos essas ferramentas contra um servidor WebSocket. Os dados vêm da documentação e do repositório de cada projeto, conferidos em 9 de outubro de 2026, e as notas de "Prefira" são a nossa avaliação.

Ferramenta	Suporte a WebSocket	Testes escritos em	Verificar o que o servidor envia
k6	De fábrica: `k6/websockets`, o antigo `k6/ws`	JavaScript	Handlers de eventos no seu script
Artillery	Engines de fábrica `ws` e `socketio`	YAML, mais funções JavaScript	Respostas e acknowledgements do Socket.IO
Gatling	Parte do SDK de HTTP	Java, Kotlin, Scala, JavaScript	Checks que esperam uma mensagem específica
Apache JMeter	Plugin WebSocket Samplers	Planos de teste montados na interface gráfica	Samplers de request-response e de leitura
Locust	Seu próprio cliente, ou o `SocketIOUser` experimental	Python	O que o seu código reportar
Tsung	Tipo de sessão de fábrica `ts_websocket`	XML	`ack` espera uma resposta do servidor

O que muda na carga WebSocket em relação à carga HTTP?

Um usuário WebSocket abre uma conexão e a mantém durante toda a sessão, e o servidor pode mandar mensagens quando quiser. Por isso um teste tem dois controles, conexões abertas e mensagens por segundo, e cada um carrega o servidor de um jeito.

O guia de WebSocket do k6 descreve tráfego full-duplex sobre uma única conexão TCP e explica que um usuário virtual roda ali um loop de eventos enquanto o socket fica aberto e para de repetir a função principal. A referência de WebSocket do Gatling acrescenta que o tráfego vai nos dois sentidos, então o modelo de requisição e resposta do HTTP deixa de servir.

Planeje três formatos de teste. Muitas conexões ociosas mostram quantos sockets os seus servidores conseguem manter. Um grupo menor de clientes que falam muito testa o tratamento de mensagens. Um broadcast, em que uma mensagem vai para todos os assinantes, testa o caminho do push.

O que medir em um teste de carga WebSocket?

Meça o tempo de conexão, a latência das mensagens e as conexões perdidas, além de quantas conexões continuam abertas. São esses valores que os usuários de um app em tempo real sentem.

As métricas embutidas do k6 incluem ws_connecting, ws_ping, ws_session_duration, ws_sessions e contadores de mensagens. Nenhuma delas cronometra uma mensagem da aplicação, então o tempo entre a mensagem de um cliente e a resposta do servidor pede uma métrica Trend própria. A engine ws do Artillery reporta a contagem e a taxa de mensagens, e a engine de Socket.IO acrescenta socketio.response_time, do envio de uma mensagem até a chegada da resposta.

Para as conexões perdidas, conte os eventos close e error que o seu script não provocou, e compare as sessões iniciadas com as que ainda estão abertas no fim de cada etapa.

Quando o k6 é a ferramenta WebSocket certa?

Quando o seu time escreve JavaScript e cada usuário virtual precisa manter vários sockets ao mesmo tempo. O k6 traz suporte a WebSocket de fábrica, sem extensão para instalar.

O módulo k6/websockets segue a API WebSocket do navegador e usa um loop de eventos global, que permite a um usuário virtual manter várias conexões abertas. O módulo antigo k6/ws continua documentado, mas o k6 recomenda k6/websockets para testes novos, e k6/experimental/websockets está obsoleto.

import { WebSocket } from 'k6/websockets';

export default function () {
  const ws = new WebSocket('wss://example.com/ws');
  ws.onopen = () => ws.send('hello');
  ws.onmessage = (e) => {
    console.log(e.data);
    ws.close();
  };
}

Os thresholds também funcionam com métricas próprias, então uma meta de latência não cumprida devolve à CI um código de saída diferente de zero. Prefira o Artillery quando o seu servidor fala Socket.IO e você quer verificar emits e acknowledgements sem escrever código cliente. A nossa comparação k6 vs Artillery cobre as outras diferenças.

Quando o Artillery faz sentido?

Quando você quer cenários YAML curtos, ou quando o seu servidor usa Socket.IO. As duas engines vêm com o próprio Artillery.

Um cenário na engine de WebSocket é montado com cinco ações: connect, send, think, loop e function. A engine de Socket.IO vai além: um emit pode declarar a resposta que espera, validar um acknowledgement com uma correspondência JSONPath e dividir o cenário com requisições HTTP, o que serve bem a apps que fazem login por HTTP antes de abrir um socket.

Prefira o k6 ou o Gatling quando um teste precisa verificar o que um servidor WebSocket puro devolve, porque a documentação da engine ws não descreve nenhuma etapa que espere ou compare uma resposta.

Para quem é o Gatling em WebSockets?

Para times na JVM, ou no SDK de JavaScript do Gatling, que querem escrever as verificações de mensagens dentro do cenário. O suporte a WebSocket faz parte do SDK de HTTP do Gatling, então os passos HTTP e WebSocket dividem a mesma simulação.

A referência cobre connect, sendText, sendBytes e close, além de checks que bloqueiam até a mensagem esperada chegar ou um timeout passar. As configurações do protocolo permitem reconectar um socket que o servidor fechou, responder automaticamente a certas mensagens de texto, como um ping, e guardar em buffer as mensagens que nenhum check reconheceu. Segundo o repositório, WebSocket faz parte da Community Edition sob Apache 2.0, sem limites.

Prefira o k6 se você gosta mais de reagir às mensagens enviadas pelo servidor em handlers de eventos do que em checks bloqueantes.

O JMeter consegue fazer teste de carga de WebSockets?

Sim, com um plugin. O JMeter não tem sampler de WebSocket, e a extensão de costume é o WebSocket Samplers, de Peter Doornbosch.

A referência de componentes do JMeter não menciona WebSocket em nenhum momento. O repositório do plugin descreve seis samplers: abrir conexão, request-response, ping-pong, leitura única, escrita única e fechamento. Eles rodam na thread do próprio thread group, suportam wss e frames binários, e podem filtrar os frames que não importam para o teste. A instalação é pelo Plugins Manager ou copiando o jar para lib/ext, e a versão 1.3.2 foi marcada em janeiro de 2026 (conferido em 9 de outubro de 2026).

Escolha outra ferramenta se você prefere não manter um plugin de terceiros em cada gerador de carga.

E o Locust e o Tsung?

O Locust só chega aos WebSockets puros com código cliente que você adiciona, e o Tsung os suporta na configuração XML, mas lança versões novas raramente. Os dois funcionam, com mais esforço.

Segundo a documentação do Locust, a ferramenta suporta de fábrica só HTTP e HTTPS; outros protocolos entram envolvendo uma biblioteca cliente e disparando um evento request depois de cada chamada. A biblioteca precisa aceitar o patch do gevent, ou vai bloquear o processo inteiro. Para Socket.IO existe um SocketIOUser experimental. Escolha o Locust se o seu time escreve Python e não se importa de manter esse código cliente.

O Tsung é um projeto em Erlang que se descreve como uma ferramenta de teste de carga distribuída e multiprotocolo. A sua documentação de sessões define para WebSocket as requisições connect, message e close, com um atributo ack para esperar uma resposta. A sua última versão marcada, a 1.8.0, é de março de 2023.

Onde entra um serviço hospedado como a LoadFocus?

Manter muitos sockets abertos a partir das suas próprias máquinas dá trabalho, e um serviço hospedado assume a geração de carga. Ele se encaixa melhor quando os seus testes já são scripts k6.

A LoadFocus, que publica este site, roda scripts k6 a partir de 25 regiões na nuvem, e a sua página de k6 lista conexões WebSocket entre os recursos do k6 suportados. Ela também oferece um template de teste WebSocket com rampa de subida e descida (em inglês). Não verificamos se ela roda plugins do JMeter como o WebSocket Samplers, então não afirmamos nada sobre isso.

Como escolher entre elas?

Parta da linguagem do seu time e depois pergunte se você testa WebSockets puros ou Socket.IO e com que rigor precisa verificar as mensagens enviadas pelo servidor. Normalmente sobram uma ou duas candidatas.

Escreva nas duas o mesmo teste curto de conectar, enviar e receber, e compare o tempo de conexão e a latência das mensagens com pouca carga. O nosso guia Como fazer um teste de carga mostra os passos, e o panorama de ferramentas de teste de carga open source compara esses projetos além do WebSocket.

FAQ

Com qual ferramenta de teste de carga WebSocket devo começar? Se o seu time escreve JavaScript, comece pelo k6, que traz WebSocket de fábrica. Para apps com Socket.IO, a engine do Artillery pede menos código, e times da JVM vão se sentir em casa no Gatling.

O JMeter consegue testar WebSockets sem plugin? A referência de componentes dele não traz nenhum sampler de WebSocket, então o caminho prático é o plugin WebSocket Samplers, instalado pelo Plugins Manager ou como jar em lib/ext.

Devo usar k6/ws ou k6/websockets? Use k6/websockets em testes novos, como recomenda a documentação do k6. O módulo antigo k6/ws continua documentado para scripts existentes.

Leituras relacionadas

Como fazer um teste de carga: guia passo a passo

Thu, 08 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, um serviço de teste de carga mencionado neste artigo.

Para fazer um teste de carga, decida como é um bom resultado, roteirize uma jornada de usuário realista, confira esse script com um único usuário e depois aumente a carga em degraus enquanto observa tempos de resposta e erros. Compare o que você mediu com a meta definida no começo e mude uma coisa de cada vez antes da próxima execução.

Passo	O que você faz	Pronto quando
1. Definir a meta	Escolher a carga a testar e os números que contam como aprovação	Você consegue escrever os critérios numa frase
2. Roteirizar uma jornada	Transformar um caminho real de usuário em script	O script roda sem erros
3. Teste de fumaça	Rodar com um usuário virtual	Todas as verificações passam
4. Subir a carga	Aumentar a carga em degraus e segurar na meta	Você chega à meta ou a uma condição de parada
5. Ler os resultados	Comparar percentis e erros com a meta	Você sabe se passou e o que mudar

O que decidir antes de rodar um teste de carga?

Decida para qual carga você está testando e qual resultado conta como aprovado. Sem as duas coisas, um teste de carga gera números, mas não uma resposta.

Parta do tráfego real se você tiver. Seu analytics ou seus logs de acesso mostram o horário de pico, quantas requisições por segundo chegam e quais páginas ou endpoints recebem a maior parte. Coloque a meta acima desse pico, porque a ideia é saber que você tem folga. Depois escreva os critérios como números, por exemplo: o percentil 95 do tempo de resposta fica abaixo de 500 ms e menos de 1% das requisições falham com 200 usuários virtuais.

Duas decisões práticas também entram aqui. Escolha um ambiente parecido com a produção em tamanho e configuração, porque um servidor de staging com um quarto da capacidade diz pouco sobre a produção. E garanta que você tem permissão para testá-lo: rodar um teste de carga contra um sistema que não é seu, ou que é compartilhado com outros times, sem avisar parece exatamente um ataque.

Como roteirizar uma jornada de usuário realista?

Roteirize o caminho que mais importa para o negócio, passo a passo, com pausas onde uma pessoa de verdade leria ou digitaria. Um script que chama uma única URL o mais rápido possível mede alguma coisa, mas raramente o que importa.

Numa loja pode ser: abrir a página inicial, buscar, abrir um produto, colocar no carrinho. Numa API: fazer login, listar itens, buscar um item. Coloque uma pausa curta entre os passos (tempo de pensamento), use dados de teste variados para que os caches se comportem como na vida real e verifique cada resposta para que uma página de erro não passe por uma resposta rápida.

Este é o script que usamos no exemplo deste guia, escrito para k6. Ele sobe para 10 usuários virtuais, segura a carga e desce, com dois critérios de aprovação embutidos:

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "10s", target: 10 },
    { duration: "20s", target: 10 },
    { duration: "5s", target: 0 },
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const res = http.get("http://127.0.0.1:8765/");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Uma jornada real tem várias requisições e URLs reais. Esta é minúscula de propósito, para os passos ficarem fáceis de acompanhar.

Por que rodar primeiro um teste de fumaça com um usuário?

Um teste de fumaça com um usuário virtual prova que o script funciona antes de colocar carga de verdade em qualquer coisa. É o jeito mais barato de pegar uma URL errada, um token de login faltando ou uma verificação que sempre falha.

No k6 você pode sobrescrever a carga pela linha de comando, então o mesmo script roda uma vez com um único usuário:

k6 run --vus 1 --iterations 1 script.js

Na nossa execução, a única verificação passou, então o script estava pronto para a carga. Se uma verificação falhar aqui, corrija o script antes de seguir: erros com um usuário viram ruído com cem.

Como subir a carga?

Aumente a carga em degraus e segure cada degrau tempo suficiente para estabilizar, em vez de pular direto para a meta. Uma rampa em degraus mostra a partir de qual nível as coisas começam a piorar.

Um formato comum é subir até um primeiro degrau, segurar alguns minutos, subir para o próximo, segurar de novo e assim por diante até a meta, e depois descer. Olhando cada patamar separado, você vê se os tempos de resposta sobem aos poucos com a carga ou ficam estáveis e depois saltam. Esse salto, o ponto em que cada usuário a mais deixa cada requisição mais lenta, é a coisa mais útil que um teste de carga pode encontrar. Nosso exemplo só sobe para 10 usuários e segura por 20 segundos, o suficiente para mostrar os degraus, mas curto demais para um teste real.

O que observar enquanto o teste roda?

Observe os percentis do tempo de resposta, a taxa de erros e a vazão do lado do gerador de carga, e CPU, memória e carga do banco de dados no sistema testado. As três primeiras dizem como os usuários sentiriam, e as três últimas dizem por quê.

Combine condições de parada antes de começar, por exemplo: parar se a taxa de erros passar de 5% ou se os tempos de resposta chegarem a vários segundos. Continuar forçando um sistema que já caiu não ensina nada, e num ambiente compartilhado atrapalha o trabalho dos outros.

Observe também o gerador de carga. Se ele estiver com a CPU a 100%, as respostas lentas podem estar vindo do seu próprio notebook, e não do servidor.

Como ler os resultados de um teste de carga?

Leia os percentis e a taxa de erros contra os critérios que você anotou no começo. O tempo de resposta médio é o número menos útil do relatório.

Este foi o resultado da nossa execução de exemplo (35 segundos, até 10 usuários virtuais, uma pequena página estática servida num notebook, em 8 de outubro de 2026):

Métrica	Valor
Requisições	282 (8 por segundo)
Requisições com falha	0%
Tempo de resposta médio	0,69 ms
Percentil 90	0,66 ms
Percentil 95	0,71 ms
Percentil 99	2,68 ms
Requisição mais lenta	15,98 ms
Thresholds	Os dois aprovados

Os números são minúsculos porque o alvo era um arquivo estático na mesma máquina, então eles não servem como benchmark. A lição está no formato: a média ficou acima do percentil 90, porque um punhado de requisições lentas a puxou para cima. Os percentis descrevem o que a maioria das requisições viveu, e o percentil 99 e a requisição mais lenta mostram a cauda que poucos usuários enfrentam. Julgue a execução pelo percentil dos seus critérios e use a cauda para decidir se algo merece um olhar mais de perto.

Se uma execução não bater a meta, mude uma única coisa (uma consulta, uma configuração de cache, um tamanho de instância) e rode o mesmo teste de novo, para saber o que fez a diferença.

Quando rodar o teste a partir da nuvem?

Leve o gerador de carga para a nuvem quando uma máquina não consegue produzir a carga necessária, ou quando importa onde seus usuários estão. Um notebook no Wi-Fi do escritório mede a sua conexão tanto quanto o seu servidor.

O mesmo script k6 pode rodar em infraestrutura que você mesmo opera, no serviço hospedado da Grafana ou na LoadFocus, que roda scripts k6 a partir de 25 regiões na nuvem. Os relatórios dela separam os resultados por localização e mostram o tempo de resposta em relação ao número de usuários virtuais, que é onde o salto descrito acima aparece (como ler os resultados na LoadFocus).

FAQ

Quanto tempo deve durar um teste de carga? O suficiente para segurar a carga da meta por vários minutos depois da subida, para que picos curtos não decidam o resultado. Segurar por pelo menos 10 minutos é um bom começo, e bem mais se você estiver procurando vazamentos de memória ou uma degradação lenta.

De quantos usuários virtuais eu preciso? Calcule a partir do tráfego real. Pegue as requisições por segundo do horário de pico, estime quantas requisições uma jornada faz e quanto tempo ela dura, e dimensione os usuários virtuais para que o teste produza essa taxa com alguma folga.

É seguro fazer teste de carga em produção? Pode ser, com cuidado: teste num horário tranquilo, avise quem opera o sistema, defina condições de parada e comece bem abaixo do pico esperado. Muitos times preferem um ambiente de staging do tamanho da produção, para que um teste que falhe não afete nenhum cliente.

Leituras relacionadas

k6 vs Artillery: qual ferramenta de teste de carga escolher

Thu, 08 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

k6 e Artillery são ferramentas de teste de carga open source em que os testes são escritos como código, e qualquer uma das duas testa bem uma API HTTP sob carga. Escolha o k6 se você quer um único binário, a lógica do teste em JavaScript e limites de aprovação já embutidos. Escolha o Artillery se o seu time já vive no Node.js, prefere cenários curtos em YAML ou precisa de testes de navegador com Playwright e execuções distribuídas na AWS ou no Azure direto da linha de comando.

Os dados abaixo vêm da documentação e do repositório de cada projeto, conferidos em 8 de outubro de 2026.

	k6	Artillery
Licença	AGPL-3.0 (repositório)	MPL-2.0, alguns módulos de Azure sob BSL (repositório)
Ambiente de execução	Um binário Go com um motor JavaScript embutido	Node.js, versão LTS mais recente
Scripts de teste	JavaScript	YAML, TypeScript ou JavaScript
Protocolos principais	HTTP, WebSockets, gRPC	HTTP, WebSocket, Socket.IO (gRPC e Kinesis via engines adicionais)
Testes de navegador	Módulo de navegador embutido	Playwright
Critérios de aprovação	Thresholds	Plugin `ensure`
Execução distribuída	k6-operator no Kubernetes, ou Grafana Cloud k6	`run-lambda` ou `run-fargate` na AWS, `run-aci` no Azure

Qual é a diferença entre k6 e Artillery?

Eles se diferenciam principalmente no ambiente de execução e na forma de descrever a carga. O k6 é uma ferramenta compilada em Go que executa código de teste em JavaScript, enquanto o Artillery é uma ferramenta Node.js que lê cenários em YAML ou JavaScript.

Essa diferença aparece logo no primeiro dia. Instalar o k6 é instalar um pacote ou um binário independente, sem um ambiente de execução para manter. O Artillery precisa do Node.js e é instalado pelo npm, o que é natural num projeto JavaScript e é mais um ambiente para manter atualizado em qualquer outro lugar.

Em protocolos, o que os dois têm em comum cobre quase todo o trabalho web: ambos falam HTTP e WebSockets de fábrica. O k6 traz também gRPC, e o Artillery, Socket.IO. O Artillery ganha gRPC e Kinesis com engines adicionais instaladas à parte (conferido em 9 de outubro de 2026), e o k6 vai além com seu ecossistema de extensões.

Como se escreve um teste em cada ferramenta?

No k6 você escreve um módulo JavaScript com as opções no topo e uma função padrão que cada usuário virtual executa. No Artillery você normalmente escreve um arquivo YAML com um bloco config para a carga e um bloco scenarios para o que cada usuário virtual faz.

Um teste k6 que sobe para 20 usuários virtuais e falha se o percentil 95 do tempo de resposta passar de 500 ms:

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 20 },
    { duration: "1m", target: 20 },
    { duration: "15s", target: 0 },
  ],
  thresholds: { http_req_duration: ["p(95)<500"] },
};

export default function () {
  const res = http.get("https://staging.example.com/api/users");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

A mesma ideia no formato YAML do Artillery, com dez novos usuários virtuais por segundo durante um minuto:

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 10
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500
scenarios:
  - flow:
      - get:
          url: "/api/users"

Os dois exemplos modelam a carga de jeitos diferentes. O script k6 define um número de usuários virtuais simultâneos, e o arquivo do Artillery define quantos usuários virtuais novos chegam a cada segundo. O k6 também consegue controlar taxas de chegada com seus executors de cenários, e o Artillery pode limitar a concorrência com maxVusers, então escolha o modelo que se parece com o jeito que o tráfego real chega ao seu sistema, e não o que cada ferramenta mostra primeiro.

Como o k6 e o Artillery decidem se um teste passou?

Os dois transformam uma meta de desempenho em código de saída, que é o que um pipeline de CI precisa. Uma meta não cumprida encerra a execução com código de saída diferente de zero nas duas ferramentas.

No k6 as metas são thresholds e ficam nas opções do script, como no exemplo acima. No Artillery elas ficam no plugin ensure, que aceita limites simples e condições que combinam várias métricas.

A diferença prática está em onde as metas ficam. Os thresholds do k6 ficam no mesmo arquivo da lógica do teste. As verificações do Artillery ficam no bloco config, onde alguém que nunca mexe nos cenários ainda consegue ajustá-las.

Como rodar um teste maior do que uma máquina consegue gerar?

As duas ferramentas conseguem distribuir um teste entre várias máquinas, por caminhos bem diferentes. O k6 se apoia no Kubernetes ou no serviço hospedado da Grafana, e o Artillery na sua própria conta da AWS ou do Azure.

Para o k6, o k6-operator divide um teste entre pods de um cluster Kubernetes, e o Grafana Cloud k6 roda os mesmos scripts como serviço hospedado. Para o Artillery, os comandos run-lambda e run-fargate sobem workers na sua conta da AWS depois de uma configuração de IAM feita uma única vez com uma stack do CloudFormation. No Azure, o run-aci faz o mesmo com Azure Container Instances, mas exige uma assinatura paga do Artillery para qualquer uso além de avaliação (conferido em 9 de outubro de 2026). Se você já usa Kubernetes, o caminho do operator vai parecer familiar. Se prefere não operar nada, o caminho serverless do Artillery tem menos peças móveis, desde que o teste possa viver na AWS ou no Azure.

Existe um terceiro caminho para scripts k6. A LoadFocus roda scripts k6 na própria infraestrutura de nuvem a partir de 25 regiões, então o script que você roda no notebook vira um teste distribuído sem cluster nem conta da AWS. A LoadFocus não roda scripts do Artillery, então para o Artillery os próprios comandos dele para AWS e Azure continuam sendo o jeito de escalar.

Para onde vão os resultados?

As duas ferramentas mostram um resumo no fim de cada execução e podem enviar métricas para outros sistemas, para painéis e alertas.

Segundo o repositório, o k6 oferece estatísticas resumidas ou métricas detalhadas exportadas para o serviço que você escolher. O Artillery lista no repositório mais de 20 integrações de monitoramento, observabilidade e CI/CD. As duas conseguem alimentar os painéis que você já tem. Antes de decidir, confira se a saída exata de que você precisa está na lista, porque as duas listas mudam de uma versão para outra.

Qual delas você deve escolher?

Escolha o k6 quando quiser um único binário na CI, lógica de teste em JavaScript com controle de fluxo de verdade e thresholds no mesmo arquivo do teste. Ele também combina com times que já usam Grafana, porque a ferramenta open source e o serviço hospedado compartilham a mesma API de scripts.

Escolha o Artillery quando o seu time escreve Node.js todo dia, quando um arquivo YAML curto é mais fácil para o resto do time revisar do que um script, ou quando você precisa de testes de navegador com Playwright e de Socket.IO na mesma ferramenta. O escalonamento serverless dele também é o caminho mais curto se a sua infraestrutura já vive na AWS e o Kubernetes não faz parte dela.

Se ainda estiver em dúvida, escreva o mesmo teste de fumaça nas duas. Vinte linhas bastam para ver qual delas o seu time lê com mais facilidade numa revisão de código.

FAQ

O k6 é gratuito? Sim. O k6 é open source sob a licença AGPL-3.0 e roda de graça nas suas próprias máquinas. O Grafana Cloud k6 é um serviço hospedado separado, com preços próprios.

O Artillery é gratuito? Em grande parte. A maior parte do Artillery está sob a licença MPL-2.0, mas alguns módulos específicos de Azure usam uma licença source-available que exige licença comercial para uso em produção no Azure, segundo o repositório do projeto (conferido em 8 de outubro de 2026).

A LoadFocus consegue rodar testes do Artillery? Não. A LoadFocus roda scripts k6 e JMeter. Para escalar um teste do Artillery além de uma máquina, use os comandos do próprio Artillery para AWS Lambda, Fargate ou Azure Container Instances na sua própria conta de nuvem.

Qual ferramenta consome menos recursos no gerador de carga? Não medimos isso nós mesmos, então não apontamos um vencedor. O projeto k6 diz que até máquinas mais simples conseguem simular muito tráfego, e a comparação justa é rodar o mesmo cenário com as duas ferramentas no seu próprio hardware.

Leituras relacionadas

Ferramentas de teste de carga open source: seis opções

Thu, 08 Oct 2026 00:00:00 GMT

Aviso: o loadtest.app é publicado pela LoadFocus, que vende um serviço de teste de carga abordado neste artigo.

Seis ferramentas de teste de carga open source muito usadas hoje são Apache JMeter, k6, Gatling, Locust, Artillery e Vegeta. Escolha pela linguagem em que o seu time escreve testes e pela forma como você precisa escalar: JMeter para a maior cobertura de protocolos, k6 ou Artillery para JavaScript, Gatling para a JVM, Locust para Python e Vegeta para verificações HTTP rápidas com taxa fixa.

Para este artigo, não fizemos benchmark dessas ferramentas umas contra as outras. Os dados vêm do repositório e da documentação de cada projeto, conferidos em 8 de outubro de 2026, e as notas de "Bom para" são a nossa avaliação.

Ferramenta	Licença	Testes escritos em	Roda em	Distribuir a carga entre máquinas
Apache JMeter	Apache 2.0	Planos de teste montados numa interface gráfica	Java	Modo remoto (cliente-servidor) embutido
k6	AGPL-3.0	JavaScript	Um binário Go	k6-operator no Kubernetes
Gatling	Apache 2.0 (alguns componentes sob licença enterprise)	Java, Kotlin, Scala, JavaScript, TypeScript	JVM	Edição Enterprise comercial
Locust	MIT	Python	Python	Embutido
Artillery	MPL-2.0 (alguns módulos de Azure sob BSL)	YAML, JavaScript, TypeScript	Node.js	AWS Lambda, Fargate ou Azure ACI pela CLI
Vegeta	MIT	Linha de comando ou código Go	Um binário Go	Rodar várias instâncias

O Apache JMeter ainda vale a pena?

Vale, principalmente quando você precisa de protocolos além de HTTP. O JMeter cobre o leque mais amplo das seis e tem o maior volume de planos de teste e conhecimento acumulado.

O JMeter é uma aplicação Java sob a licença Apache 2.0. A lista de protocolos inclui HTTP e HTTPS, web services SOAP e REST, FTP, bancos de dados via JDBC, LDAP, mensageria JMS, e-mail e TCP puro. Você monta os planos de teste numa interface gráfica de desktop, roda os testes de verdade sem interface pela linha de comando, e o modo remoto cliente-servidor distribui um teste entre várias máquinas.

Bom para sistemas com vários protocolos, times que já têm planos de JMeter e testers que preferem montar testes de forma visual. Escolha outra coisa quando o seu time quer testes como código puro, revisados como a aplicação, porque planos XML montados numa interface gráfica são difíceis de ler num pull request.

Quando o k6 é a escolha certa?

Quando o seu time escreve JavaScript e quer testes em código com limites de aprovação embutidos. Ele vem como um único binário Go, o que deixa a configuração na CI simples.

O k6 está sob a licença AGPL-3.0 e fala HTTP, WebSockets e gRPC, com um módulo de navegador para verificações de front-end. Os thresholds transformam uma meta, como um limite para o percentil 95, num código de saída diferente de zero para a CI. Para escalar, o k6-operator roda testes distribuídos no Kubernetes, e a Grafana vende um serviço hospedado.

Bom para desenvolvedores que mantêm testes de API junto do código e para pipelines de CI. Escolha outra coisa quando o seu time não quer JavaScript, ou quando a licença AGPL não combina com o jeito como você embute ou distribui a ferramenta. Comparamos as duas em detalhe em k6 vs Artillery.

Para quem é o Gatling?

Para times na JVM que querem testes como código e um relatório HTML detalhado sem nada a mais. Ele também oferece um SDK de JavaScript e TypeScript sobre o mesmo motor.

O Gatling roda os usuários virtuais num motor não bloqueante construído sobre o Netty, então uma única máquina consegue gerar muita carga. As simulações são escritas em Java, Kotlin, Scala, JavaScript ou TypeScript e rodam por plugins de Maven, Gradle, sbt ou npm. A edição community está sob Apache 2.0 e cobre HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events e JMS, enquanto os componentes de gRPC, MQTT e GraphQL usam a licença enterprise do Gatling.

Bom para times de Java e Scala e para quem quer relatórios completos sem ferramentas extras. Escolha outra coisa quando você precisa distribuir a carga entre máquinas só com a edição open source: gerar carga a partir de infraestrutura gerenciada ou privada é o papel do Gatling Enterprise, a edição comercial.

O Locust é uma boa escolha para times de Python?

É. Os testes do Locust são Python puro, então laços, condições e qualquer biblioteca Python funcionam como em código comum.

O Locust está sob a licença MIT e funciona por eventos com gevent, o que permite que um único processo atenda muitos usuários. Os testes rodam pela linha de comando ou por uma interface web que mostra ao vivo a vazão, os tempos de resposta e os erros, e o Locust distribui um teste entre várias máquinas por conta própria. HTTP vem embutido, e outros protocolos entram escrevendo Python.

Bom para times de Python, cenários com lógica complexa e quem gosta de acompanhar um teste no navegador. Escolha outra coisa quando você quer testes declarativos no estilo de arquivo de configuração, ou quando um plugin pronto para um protocolo incomum importa mais do que escrever o seu.

Quando o Artillery faz sentido?

Quando o seu time vive no Node.js, gosta de cenários curtos em YAML ou quer testes de navegador com Playwright na mesma ferramenta dos testes de API.

O Artillery está quase todo sob MPL-2.0, com alguns módulos de Azure sob uma licença source-available. Ele traz de fábrica HTTP, WebSocket e Socket.IO, ganha gRPC e Kinesis com engines adicionais, e os comandos run-lambda e run-fargate distribuem um teste entre workers na sua própria conta da AWS. O comando run-aci faz o mesmo no Azure Container Instances, com uma assinatura paga do Artillery para qualquer uso além de avaliação (conferido em 9 de outubro de 2026).

Bom para times de Node.js, testes mistos de API e navegador, e empresas que já usam AWS. Escolha outra coisa quando você prefere não ter Node.js nos seus geradores de carga, ou quando testes grandes precisam rodar fora da AWS e do Azure.

Para que serve o Vegeta?

Para verificações HTTP rápidas, com taxa constante, pela linha de comando. Ele faz uma coisa só, enviar requisições a uma taxa fixa, e mantém essa coisa simples.

O Vegeta é uma ferramenta Go sob a licença MIT que funciona como programa de linha de comando ou como biblioteca Go, com uma CLI pensada para se combinar com outras ferramentas Unix. Como ele mantém a taxa de requisições constante em vez de modelar usuários, responde melhor a perguntas como "o que acontece com 500 requisições por segundo?" do que reproduz jornadas de usuário.

Bom para conferir rapidamente um endpoint, testes de capacidade com taxa fixa e scripts de shell. Escolha outra coisa quando você precisa de jornadas com vários passos, tempo de pensamento ou relatórios detalhados.

Onde entra um serviço hospedado como a LoadFocus?

Nenhuma dessas ferramentas precisa de um serviço hospedado, mas gerar carga grande ou espalhada geograficamente a partir das suas próprias máquinas dá trabalho. Um serviço hospedado assume a geração de carga e deixa os seus scripts como estão.

A LoadFocus, que publica este site, é um desses serviços. Ela roda planos de teste JMeter existentes e scripts k6 a partir de 25 regiões na nuvem. Ela não roda testes de Gatling, Locust, Artillery ou Vegeta, então para essas ferramentas valem as opções de escala descritas acima. Grafana Cloud k6 e Gatling Enterprise são os caminhos hospedados dos próprios fabricantes para k6 e Gatling.

Como escolher entre elas?

Parta da linguagem que o seu time já escreve e dos protocolos que você precisa testar, e depois veja como cada ferramenta escala. Isso costuma reduzir seis opções a uma ou duas.

Depois escreva o mesmo teste curto nas suas duas favoritas. Ler os dois lado a lado resolve a maioria das discussões mais rápido do que qualquer tabela de recursos, e o nosso guia Como fazer um teste de carga acompanha esse primeiro teste passo a passo.

FAQ

Qual ferramenta de teste de carga open source é a mais fácil para começar? Para um único endpoint HTTP, Vegeta ou k6 dão um resultado em minutos, porque cada um é um único binário. Para jornadas com vários passos, escolha a ferramenta cuja linguagem de teste o seu time já escreve.

Ferramentas de teste de carga open source conseguem rodar testes distribuídos? Conseguem, por caminhos diferentes: o JMeter tem um modo remoto embutido, o Locust distribui entre máquinas nativamente, o k6 usa o k6-operator no Kubernetes e o Artillery usa AWS Lambda, Fargate ou Azure Container Instances. No Gatling, gerar carga a partir de infraestrutura gerenciada ou privada faz parte da edição comercial Enterprise.

O JMeter é melhor que o k6? Nenhum é melhor no geral. O JMeter cobre mais protocolos e combina com o desenho de testes em interface gráfica, enquanto o k6 combina com desenvolvedores que querem testes como código JavaScript na CI.