Comparaison des performances des SGBD Valkey et Redis

Les résultats des tests des dernières versions des bases de données Redis 8.0 et Valkey 8.1 ont été publiés, révélant d'importantes optimisations de performance. Dans tous les tests effectués, le fork soutenu par la communauté a surpassé le projet original, principalement grâce à l'implémentation dans Valkey d'un nouveau mécanisme pour le traitement multithread d'E/S en mode asynchrone, transmis au projet par Amazon.

Dans l'environnement de test AWS Graviton4 c8g.2xlarge avec 8 VCPU, Valkey 8.1.1 a atteint une performance de 999,8 milliers de requêtes SET par seconde, tandis que Redis 8.0 a atteint 729,4 milliers de requêtes par seconde. En général, la bande passante de Valkey était supérieure à celle de Redis de 37% pour les opérations SET et de 16% pour les opérations GET. En outre, par rapport à Redis, Valkey a montré une réduction des latences de traitement des requêtes de 30% pour les opérations SET et de 60% pour les opérations GET.

Comparaison des performances des SGBD Valkey et Redis

Une analyse distincte a été réalisée sur les changements de bande passante et de latence en fonction du nombre de gestionnaires exécutés en parallèle en mode de traitement multithread d'E/S. Jusqu'à 3 threads, Valkey et Redis montrent des résultats à peu près équivalents, mais ensuite Valkey prend l'avantage. Avec 6 threads sur un système avec 8 VCPU, la performance de Valkey était de 678 milliers de requêtes SET par seconde, tandis que Redis atteignait 563 milliers de requêtes par seconde avec une limite de 256 connexions simultanées. En augmentant les connexions à 400, la performance de Valkey a augmenté à 832 milliers de requêtes SET par seconde.

Comparaison des performances des SGBD Valkey et Redis

Après l'optimisation du traitement des interruptions dans le système pour réduire le nombre de commutations de contexte, Valkey a réussi à améliorer sa performance à 999,8 milliers de requêtes SET par seconde. L'optimisation consistait à allouer 2 VCPU pour le traitement des interruptions et à lier les 6 VCPU restants aux threads de traitement d'E/S de Valkey et Redis, afin d'éviter la migration des gestionnaires entre les CPU. sudo ethtool -L ens34 combined 2 # limiter à 2 le nombre de gestionnaires IRQ grep ens34 /proc/interrupts # voir quels gestionnaires sont utilisés (99 et 100) echo 1 | sudo tee /proc/irq/99/smp_affinity # lier le gestionnaire 99 au cœur 1 echo 2 | sudo tee /proc/irq/100/smp_affinity # lier le gestionnaire 100 au cœur 2 # Lancer la base de données (pour Redis, remplacer valkey/valkey:8.1.1 par redis:8.0) en liant le conteneur aux cœurs 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

Pour tester les performances, la commande suivante a été utilisée : 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

Source : opennet.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster