{"id":135788,"date":"2025-06-04T09:05:06","date_gmt":"2025-06-04T07:05:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/sravnenie-proizvoditelnosti-subd-valkey-i-redis"},"modified":"2025-06-04T09:05:06","modified_gmt":"2025-06-04T07:05:08","slug":"sravnenie-proizvoditelnosti-subd-valkey-i-redis","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/sravnenie-proizvoditelnosti-subd-valkey-i-redis","title":{"rendered":"Comparaison des performances des SGBD Valkey et Redis","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Les r\u00e9sultats des tests des derni\u00e8res versions des bases de donn\u00e9es Redis 8.0 et Valkey 8.1 ont \u00e9t\u00e9 publi\u00e9s, r\u00e9v\u00e9lant d'importantes optimisations de performance. Dans tous les tests effectu\u00e9s, le fork soutenu par la communaut\u00e9 a surpass\u00e9 le projet original, principalement gr\u00e2ce \u00e0 l'impl\u00e9mentation dans Valkey d'un nouveau m\u00e9canisme pour le traitement multithread d'E\/S en mode asynchrone, transmis au projet par Amazon. <\/p>\n
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\u00eates SET par seconde, tandis que Redis 8.0 a atteint 729,4 milliers de requ\u00eates par seconde. En g\u00e9n\u00e9ral, la bande passante de Valkey \u00e9tait sup\u00e9rieure \u00e0 celle de Redis de 37% pour les op\u00e9rations SET et de 16% pour les op\u00e9rations GET. En outre, par rapport \u00e0 Redis, Valkey a montr\u00e9 une r\u00e9duction des latences de traitement des requ\u00eates de 30% pour les op\u00e9rations SET et de 60% pour les op\u00e9rations GET.
<\/center> <\/p>\n
Une analyse s\u00e9par\u00e9e a \u00e9t\u00e9 effectu\u00e9e pour \u00e9tudier les changements dans la bande passante et les latences en fonction du nombre de gestionnaires ex\u00e9cutant des op\u00e9rations en mode multithreading d'entr\u00e9e\/sortie. Jusqu'\u00e0 3 threads, Valkey et Redis montrent des r\u00e9sultats \u00e0 peu pr\u00e8s \u00e9quivalents, mais ensuite Valkey prend l'avantage. Avec 6 threads sur un syst\u00e8me avec 8 VCPU, la performance de Valkey a atteint 678 000 requ\u00eates SET par seconde, tandis que Redis a enregistr\u00e9 563 000 requ\u00eates par seconde avec une limite de 256 connexions simultan\u00e9es. En augmentant le nombre de connexions \u00e0 400, la performance de Valkey a grimp\u00e9 \u00e0 832 000 requ\u00eates SET par seconde.
<\/center> <\/p>\n
Apr\u00e8s avoir optimis\u00e9 le traitement des interruptions dans le syst\u00e8me pour r\u00e9duire le nombre de changements de contexte, Valkey a r\u00e9ussi \u00e0 porter la performance \u00e0 999,8 milliers de requ\u00eates SET par seconde. L'optimisation a consist\u00e9 \u00e0 allouer 2 VCPU pour le traitement des interruptions et \u00e0 lier les 6 VCPU restants aux threads de traitement d'entr\u00e9e\/sortie de Valkey et Redis, afin d'\u00e9viter la migration des gestionnaires entre les CPU. sudo ethtool -L ens34 combined 2 # limit\u00e9 \u00e0 2 le nombre de gestionnaires IRQ grep ens34 \/proc\/interrupts # v\u00e9rifier quels gestionnaires sont actifs (99 et 100) echo 1 | sudo tee \/proc\/irq\/99\/smp_affinity # lier le gestionnaire 99 au c\u0153ur 1 echo 2 | sudo tee \/proc\/irq\/100\/smp_affinity # lier le gestionnaire 100 au c\u0153ur 2 # D\u00e9marrer la base de donn\u00e9es (pour Redis, remplacer valkey\/valkey:8.1.1 par redis:8.0) avec le conteneur li\u00e9 aux c\u0153urs CPU 2-7 docker run --network='host' --rm \\ --cpuset-cpus='2-7' valkey\/valkey:8.1.1 \\ --save \u00ab \u00bb --appendonly no --io-threads 6 \\ --protected-mode no --maxmemory 10gb <\/p>\n
![\"Comparaison](\"\/wp-content\/uploads\/2025\/06\/512bd8dc9f4e4cc2562b59db68823b07.png\")
<\/center> <\/p>\n![\"Comparaison](\"\/wp-content\/uploads\/2025\/06\/b81d26ec066d0af829859a11236ae2a6.png\")
<\/center> <\/p>\n