KeyDB es un fork de Redis. La gente de KeyDB sostiene que la forma en que Redis está implementado no es la correcta y que se puede hacer mejor, hablando de rendimiento.
El argumento principal es que KeyDB puede tirar de varios hilos, mientras que Redis se queda en uno.
En su sitio web dicen que es más rápido que Redis. Como me picó la curiosidad, monté unas pruebas rápidas para ver qué tal se porta como servidor de caché, o sea, con comandos GET y SET. Aquí van los resultados.
¿Cómo hice las pruebas?
Levanté un Docker para Redis y otro para KeyDB. Le di 4 vCPUs al Docker Engine para que KeyDB pudiera lucirse con su multihilo:
También subí los límites del sistema operativo, que si no se te queda corto en cuanto pides muchas conexiones concurrentes:
> ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-v: address space (kbytes) unlimited
-l: locked-in-memory size (kbytes) unlimited
-u: processes 11136
-n: file descriptors 256
Condiciones de las pruebas
Lancé todas las pruebas con estos parámetros:
- Total de consultas: 50.000
- Comando probado: GET /
- Clientes concurrentes: 500
- Ejecuté la misma prueba 5 veces.
Resultados de KeyDB
Versión de KeyDB: 6.3.1
Servidor con 4 hilos
> docker run -p 6777:6379 eqalpha/keydb keydb-server --server-threads 4
Ejecutando pruebas:
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 23775.56 requests per second, p50=14.559 msec
GET: 22758.31 requests per second, p50=13.439 msec
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 18903.59 requests per second, p50=16.247 msec
GET: 22872.83 requests per second, p50=13.359 msec
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 23430.18 requests per second, p50=14.583 msec
GET: 20729.69 requests per second, p50=14.687 msec
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 17325.02 requests per second, p50=19.263 msec
GET: 19723.87 requests per second, p50=16.591 msec
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 25706.94 requests per second, p50=13.191 msec
GET: 19817.68 requests per second, p50=14.839 msec
Como resumen:
Servidor con 2 hilos
> docker run -p 6777:6379 eqalpha/keydb keydb-server --server-threads 2
Ejecutando pruebas:
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 31605.56 requests per second, p50=11.095 msec
GET: 33692.72 requests per second, p50=10.815 msec
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 30395.14 requests per second, p50=12.271 msec
GET: 32959.79 requests per second, p50=13.639 msec
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 29691.21 requests per second, p50=13.087 msec
GET: 32467.53 requests per second, p50=13.159 msec
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 28216.71 requests per second, p50=14.295 msec
GET: 30693.68 requests per second, p50=14.103 msec
> redis-benchmark -p 6777 -t get,set -q -n 50000 -c 500
SET: 31486.14 requests per second, p50=12.543 msec
GET: 35087.72 requests per second, p50=12.543 msec
Como resumen:
Servidor con 1 hilo
Probé también con un solo hilo, pero salieron los mismos números que con 2, así que no los pongo para no repetir.
Resultados de Redis
Versión de Redis: 6.2.5
Ejecutando servidor:
> docker run -p 6379:6379 redis
Ejecutando pruebas:
> redis-benchmark -p 6379 -t get,set -q -n 50000 -c 500
SET: 37622.27 requests per second, p50=12.527 msec
GET: 28392.96 requests per second, p50=12.919 msec
> redis-benchmark -p 6379 -t get,set -q -n 50000 -c 500
SET: 27442.37 requests per second, p50=13.439 msec
GET: 31446.54 requests per second, p50=15.527 msec
> redis-benchmark -p 6379 -t get,set -q -n 50000 -c 500
SET: 27808.68 requests per second, p50=13.751 msec
GET: 35335.69 requests per second, p50=13.391 msec
> redis-benchmark -p 6379 -t get,set -q -n 50000 -c 500
SET: 30156.82 requests per second, p50=14.631 msec
GET: 37009.62 requests per second, p50=12.711 msec
> redis-benchmark -p 6379 -t get,set -q -n 50000 -c 500
SET: 33068.79 requests per second, p50=13.359 msec
GET: 40225.26 requests per second, p50=10.999 msec
Como resumen:
Tabla comparativa
Cogiendo el rendimiento de Redis como referencia, así queda KeyDB al lado:
Operaciones de GET
| Servidor | Get Ops/sec (media) | Rendimiento (%) |
|---|---|---|
| Redis | 34481,48 | 100 |
| KeyDB (2 hilos) | 32979,62 | 95,6 |
| KeyDB (4 hilos) | 21179,8 | 61,4 |
Operaciones de SET
| Servidor | Set Ops/sec (media) | Rendimiento (%) |
|---|---|---|
| Redis | 31219,21 | 100 |
| KeyDB (2 hilos) | 30278,60 | 97,0 |
| KeyDB (4 hilos) | 21827,82 | 69,9 |
Sale más lento que Redis, tanto en GET como en SET.
Conclusiones
Ok. Los resultados son curiosos:
- KeyDB dice que son más rápidos que Redis porque pueden ejecutarse de forma multihilo, pero en mis pruebas van más rápido cuanto más se acerca el número de hilos a 1… o sea, cuanto más se parecen a Redis.
- Traducido: KeyDB necesita más recursos para llegar al mismo rendimiento que Redis.
- Y si no le das hardware de sobra a esos hilos, mejor quédate con Redis.
Eso sí, hay que reconocerle a KeyDB una cosa que Redis no tiene, al menos en su versión de código abierto:
El modo “On Flash”, que usa discos SSD como si fueran una extensión de la RAM. Gastas mucha menos RAM y el rendimiento se queda muy parecido.
- Redis en flash: Redis on Flash
- KeyDb en flash: KeyDb en flash
Nota:
*Intenté ejecutar el servidor KeyDB con la función On Flash, pero no pude. Me dio el error: “FLASH Is Not yet Supported”*.
