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

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.

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

• Ferramentas de teste de carga WebSocket: seis opções
• Teste de carga de API GraphQL: guia prático
• Gatling vs k6: simulações na JVM ou um único binário Go?
• Ferramentas de benchmark HTTP: wrk, hey, oha, ab e mais

As afirmações técnicas deste artigo não foram revisadas de forma independente.