Se presentan los resultados de las pruebas de las últimas versiones de las bases de datos Redis 8.0 y Valkey 8.1, en las que se han anunciado significativas optimizaciones de rendimiento. En todas las pruebas realizadas, el fork desarrollado por la comunidad superó el proyecto original, principalmente gracias a la implementación en Valkey de un nuevo mecanismo para el procesamiento multihilo de entrada/salida en modo asíncrono, proporcionado al proyecto por Amazon.
En el entorno de prueba AWS Graviton4 c8g.2xlarge con 8 VCPU, Valkey 8.1.1 logró un rendimiento de 999.8 mil solicitudes SET por segundo, mientras que en Redis 8.0 se alcanzó un nivel de 729.4 mil solicitudes por segundo. En general, la capacidad de Valkey fue superior a la de Redis en un 37% para operaciones SET y en un 16% para GET. Además, en comparación con Redis, el proyecto Valkey mostró una disminución de la latencia en el procesamiento de solicitudes del 30% para operaciones SET y del 60% para operaciones GET.
Se llevó a cabo un análisis separado de la variación de la capacidad y la latencia en función del número de manejadores en ejecución en paralelo en modo de procesamiento multihilo de entrada/salida. Con hasta 3 hilos, Valkey y Redis muestran resultados aproximadamente equivalentes, pero luego Valkey toma la delantera. Con 6 hilos en un sistema con 8 VCPU, el rendimiento de Valkey fue de 678 mil solicitudes SET por segundo, mientras que Redis alcanzó 563 mil solicitudes por segundo con un límite de 256 conexiones simultáneas. Al aumentar las conexiones a 400, el rendimiento de Valkey creció a 832 mil solicitudes SET por segundo.
Después de optimizar el procesamiento de interrupciones en el sistema para reducir el número de cambios de contexto, en Valkey se logró elevar el rendimiento a 999.8 mil solicitudes SET por segundo. La optimización consistió en asignar 2 VCPU para el manejo de interrupciones y vincular las 6 VCPU restantes a los hilos de procesamiento de entrada/salida de Valkey y Redis, para evitar la migración de los manejadores entre CPU. sudo ethtool -L ens34 combined 2 # limitamos el número de manejadores IRQ a 2 grep ens34 /proc/interrupts # verificamos qué manejadores están activos (99 y 100) echo 1 | sudo tee /proc/irq/99/smp_affinity # vinculamos el manejador 99 al núcleo 1 echo 2 | sudo tee /proc/irq/100/smp_affinity # vinculamos el manejador 100 al núcleo 2 # Ejecutamos la base de datos (para Redis cambiar valkey/valkey:8.1.1 por redis:8.0) vinculando el contenedor a los núcleos de CPU 2-7 docker run —network="host" —rm \ —cpuset-cpus="2-7" valkey/valkey:8.1.1 \ —save "" —appendonly no —io-threads 6 \ —protected-mode no —maxmemory 10gb
Para probar el rendimiento se utilizó el comando: docker run —network="host" —rm —cpuset-cpus="2-7" \ valkey/valkey:8.0.1 valkey-benchmark \ -h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \ -r 3000000 —threads 6 -d 1024
Fuente: opennet.ru
