KeyDB es un fork de Redis. El proyecto KeyDB afirma que el enfoque de implementación de Redis no es correcto y puede ser mejor, en términos de rendimiento.
KeyDB puede ejecutar más de un hilo, en comparación con el enfoque de Redis que solo ejecuta uno.
El sitio web de KeyDB afirma que es más rápido que Redis. Realicé algunas pruebas rápidas para verificar el rendimiento como servidor de caché (lo que significa que probé comandos como GET / SET) y en esta publicación compartiré mis resultados.
¿Cómo hice las pruebas?
Para mis pruebas, utilicé un Docker para ejecutar Redis y otro para KeyDB. Configuré mi Docker Engine con 4 vCPUs para aprovechar el multihilo de KeyDB:
También aumenté los límites del sistema operativo para permitir un alto número de conexiones concurrentes para las pruebas:
> 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
Las pruebas se realizaron con los siguientes 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
Hice pruebas con solo un hilo, pero los resultados fueron los mismos que con 2 hilos, por lo que no los he incluido.
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
Tomando como base el rendimiento de Redis, podemos comparar los resultados de KeyDB:
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 |
Podemos ver que KeyDB es más lento que Redis en las operaciones de GET y 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 las pruebas, los resultados muestran que se ejecutan más rápido cuando el número de hilos tiende a 1… como Redis.
- Esto significa que KeyDB necesita más recursos para alcanzar el mismo rendimiento que Redis.
- Los hilos de KeyDB necesitan contar con los recursos de hardware; de lo contrario, Redis.
También debemos tener en cuenta que KeyDB tiene una gran característica que Redis no tiene (al menos en su versión de código abierto) como:
La característica “On Flash”. Esta característica utiliza discos SSD como una extensión de la RAM, gastando menos RAM con un rendimiento muy similar.
- 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”*.
