redis-benchmark: como usar e ler os resultados

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.

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

• Lei de Little em teste de carga: dimensionar e conferir
• Latência de cauda: o que é e como medir
• Coordinated omission: o que é e como evitar
• Modelo de carga aberto vs fechado: qual usar e quando
• Ferramentas de benchmark HTTP: wrk, hey, oha, ab e mais
• pgbench: benchmark e teste de carga do PostgreSQL
• Como usar o sysbench: benchmarks de CPU, disco e MySQL
• YCSB: cargas de trabalho A-F, execução e limites

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