redis-benchmark: cómo usarlo y leer sus resultados

redis-benchmark es la utilidad de benchmark que viene con Redis: abre un número de conexiones de cliente (50 por defecto), envía un número fijo de comandos (100.000 por defecto) e informa, para cada prueba, de las peticiones por segundo y la latencia. Lanza redis-benchmark -q -n 100000 contra un servidor en marcha, limítalo con -t a los comandos que te interesan y lee el resultado como la velocidad de una sola instancia de Redis con comandos sintéticos. Tu aplicación añade su propio camino de red, su biblioteca cliente y su mezcla de comandos, así que espera otras cifras.

Lo ejecutamos el 31 de octubre de 2026 en un portátil Apple M1 Max, con servidor y cliente Redis 7.2.6 en la misma máquina por loopback y sin persistencia. Cada fila es una ejecución de 100.000 peticiones, con las peticiones por segundo redondeadas al millar; el p50 aparece tal como lo imprimió la herramienta.

¿Cómo se ejecuta redis-benchmark?

Apunta la herramienta a un servidor en marcha con -h y -p; sin opciones, ejecuta su batería de pruebas por defecto contra 127.0.0.1:6379. Añade -t para elegir pruebas y -q para ver una línea por prueba.

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

La página oficial de benchmark de Redis y la salida de --help de la versión 7.2.6 recogen, entre otras, estas opciones (comprobado el 31 de octubre de 2026):

• -c conexiones en paralelo (50 por defecto) y -n peticiones en total (100.000 por defecto).
• -d tamaño de los valores de SET y GET en bytes (3 por defecto).
• -P comandos por pipeline (1 por defecto, sin pipelining).
• -t una lista de pruebas separadas por comas; -q salida resumida; --csv salida en CSV.
• -r claves aleatorias dentro de un espacio de claves de ese tamaño. Sin esta opción, todos los comandos usan la misma clave.
• -k 1 mantiene las conexiones abiertas (por defecto) y -k 0 vuelve a conectar.
• --threads activa el modo multihilo y --cluster el modo clúster, en el que -c debe ser al menos igual al número de nodos.

¿Cómo se lee la salida de redis-benchmark?

Con -q obtienes una línea por prueba: peticiones por segundo y latencia mediana. Sin -q, cada prueba imprime su configuración, una distribución de la latencia por percentiles y un resumen con la media, el mínimo, p50, p95, p99 y el máximo.

La cabecera también muestra los ajustes save y appendonly del servidor, que te dicen si la persistencia formaba parte de la prueba. Nuestra ejecución completa de GET dio 119.617 peticiones por segundo, una media de 0,352 ms, un p95 de 0,559 ms, un p99 de 0,623 ms y un máximo de 0,759 ms. Una petición que llama muchas veces a Redis tiene más probabilidades de dar con una llamada lenta, así que mira también el p99; nuestro artículo sobre la latencia de cola explica por qué.

--csv imprime el resumen como una fila por prueba. Repite las ejecuciones antes de fiarte de una diferencia pequeña: dos ejecuciones de la misma prueba SET nos dieron unas 113.000 y 125.000 peticiones por segundo.

¿Por qué el pipelining cambia tanto las cifras?

Sin -P, cada cliente espera una respuesta antes de enviar su siguiente comando, así que cada comando cuesta un viaje de ida y vuelta completo. Con -P 16, cada cliente envía 16 de golpe, y en nuestra ejecución SET pasó de unas 113.000 a 1.010.000 peticiones por segundo y GET de 118.000 a 1.190.000.

La página oficial considera realista el pipelining, porque muchas aplicaciones Redis lo usan, y aconseja un tamaño de pipeline cercano a la media que tu aplicación puede usar de verdad. Nuestra latencia mediana subió a la vez, a 0,711 y 0,583 ms.

¿Qué pasa si añades más clientes?

Cuando el cuello de botella ya está saturado, más clientes solo añaden espera. En un solo portátil puede ser el servidor o el cliente de benchmark, que usa un único hilo.

Al pasar de 50 a 200 clientes, el rendimiento se mantuvo casi plano (unas 117.000 peticiones SET y 123.000 GET por segundo) mientras la latencia mediana casi se triplicó, hasta 1,135 y 1,071 ms. Es la ley de Little en acción. Cada cliente tiene como mucho un comando en curso, así que -c fija cuántos hay en el sistema, y si el rendimiento no puede crecer, tiene que crecer el tiempo que cada uno pasa ahí. En nuestra ejecución completa de GET, 50 clientes ÷ 119.617 peticiones por segundo dan 0,42 ms por vuelta de cliente, algo por encima de la media medida de 0,352 ms. Con 200 clientes, la misma cuenta da 1,63 ms.

Por eso la herramienta también sigue un modelo de carga cerrado: cuando Redis se atasca, los clientes esperan, y los comandos que tu aplicación habría enviado mientras tanto nunca aparecen. Ni la página oficial ni --help ofrecen una opción de ritmo de peticiones fijo, así que lee sus percentiles teniendo presente la coordinated omission.

¿Cómo mides tu propio comando o un script Lua?

Escribe el comando después de las opciones. La herramienta ejecuta entonces solo ese 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

La primera línea es el ejemplo de la página oficial; en nuestro portátil corrió a unas 106.000 peticiones por segundo. SCRIPT LOAD solo carga el script, así que usa eval, como en la segunda línea, sacada de --help, para medir su ejecución. Con -r, la ayuda indica que __rand_int__ dentro de un argumento se sustituye por un número aleatorio de 12 cifras en ese rango, y en modo clúster la clave debe contener un {tag} para llegar al nodo correcto.

¿Por qué tu aplicación ve otras cifras?

Tu aplicación mide todo su camino hasta Redis: red, biblioteca cliente, serialización y su propia mezcla de comandos. La página oficial enumera trampas que conviene revisar antes de comparar.

• Un bucle de comandos síncronos mide sobre todo la red y la biblioteca cliente.
• Con cliente y servidor en la misma máquina, la CPU limita el benchmark. Los sockets de dominio Unix pueden dar alrededor de un 50 % más de rendimiento que el loopback TCP, por ejemplo en Linux.
• Cadenas de 4 KB a 100.000 peticiones por segundo necesitan unos 3,2 Gbit/s, más de lo que soporta un enlace de 1 Gbit/s.
• Para comparar Redis con una base de datos transaccional, activa AOF y elige una política de fsync adecuada.
• Los portátiles varían la frecuencia de la CPU, lo que perjudica la repetibilidad.
• INFO a intervalos regulares probablemente no molesta durante una ejecución, mientras que MONITOR ralentiza Redis de forma notable.

¿Muestran estas cifras de portátil la capacidad real de Redis?

No. Muestran un portátil hablando consigo mismo, sin red, con valores de 3 bytes en casi todas las ejecuciones, sin persistencia y con una ejecución por fila.

La tabla enseña cómo mueve cada opción las cifras. La capacidad depende de tu servidor, tu red, el tamaño de tus valores y tu configuración de persistencia.

¿Cuándo no es redis-benchmark la herramienta adecuada?

Cuando quieres saber qué notan los usuarios. Envía comandos sintéticos solo a Redis, mientras que el tiempo de respuesta de una página incluye también el código de la aplicación y sus otras llamadas.

Para eso, pon carga sobre la aplicación o la API que usa Redis y vigila Redis durante la prueba. LoadFocus, que publica este sitio, trabaja en esa capa: ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube contra tu aplicación web o tu API. No ejecuta redis-benchmark.

Si necesitas más control sobre el tráfico de Redis, el repositorio de memtier_benchmark menciona clientes multihilo, una proporción de lecturas y escrituras, patrones de claves aleatorios o secuenciales, Redis Cluster y TLS (comprobado el 31 de octubre de 2026).

FAQ

¿Está redis-benchmark diseñado para que Redis parezca rápido? No. La página oficial de Redis lo llama un error de concepto habitual: por defecto, la herramienta mantiene como mucho una consulta pendiente por conexión, sin pipelining, y un cliente que usa pipelining puede generar más rendimiento.

¿Cómo se llena una base de datos Redis con redis-benchmark? Ejecuta solo la prueba SET con claves aleatorias, como muestra la ayuda de la herramienta: -t set -n 1000000 -r 100000000 llena alrededor de un millón de claves. Las claves aleatorias pueden repetirse, así que el total final queda algo por debajo.

¿Puede LoadFocus ejecutar redis-benchmark? No. LoadFocus no ejecuta redis-benchmark. Sus planes de prueba JMeter y sus scripts de k6 se dirigen a la aplicación web o la API que está delante de Redis.

Lecturas relacionadas

• Ley de Little en pruebas de carga: dimensionar y comprobar
• Latencia de cola: qué es y cómo medirla
• Coordinated omission: qué es y cómo evitarla
• Modelo de carga abierto vs cerrado: cuál usar y cuándo
• Herramientas de benchmark HTTP: wrk, hey, oha, ab y más
• pgbench: benchmark y pruebas de carga de PostgreSQL
• Cómo usar sysbench: benchmarks de CPU, disco y MySQL
• YCSB: cargas de trabajo A-F, ejecución y límites

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.