Comparação do desempenho do Valkey e do Redis DBMS

Apresentamos os resultados dos testes das versões mais recentes dos SGBDs Redis 8.0 e Valkey 8.1, nos quais foram declaradas otimizações significativas de desempenho. Em todos os testes realizados, o fork desenvolvido pela comunidade superou o projeto original, principalmente devido à implementação no Valkey de um novo mecanismo para processamento multithread de entrada/saída em modo assíncrono, transferido para o projeto pela Amazon.

No ambiente de teste AWS Graviton4 c8g.2xlarge com 8 VCPUs, o Valkey 8.1.1 atingiu uma taxa de transferência de 999.8 mil solicitações SET por segundo, enquanto o Redis 8.0 atingiu 729.4 mil solicitações por segundo. No geral, a taxa de transferência do Valkey foi 37% maior que a do Redis para operações SET e 16% maior para GET. Ao mesmo tempo, em comparação com o Redis, o Valkey demonstrou uma redução de 30% na latência de SET e de 60% na latência de GET.

 Comparação do desempenho do Valkey e do Redis DBMS

Uma análise separada foi conduzida para avaliar a variação na taxa de transferência e nos atrasos, dependendo do número de processadores paralelos no modo de processamento de E/S multithread. Até 3 threads, Valkey e Redis apresentam resultados aproximadamente iguais, mas o Valkey assume a liderança. Com 6 threads em um sistema com 8 VCPUs, o desempenho do Valkey foi de 678 mil solicitações SET por segundo, e o do Redis foi de 563 mil solicitações por segundo, com um limite de 256 conexões simultâneas. Quando o número de conexões aumentou para 400, o desempenho do Valkey aumentou para 832 mil solicitações SET por segundo.

 Comparação do desempenho do Valkey e do Redis DBMS

Após otimizar o tratamento de interrupções no sistema para reduzir o número de trocas de contexto no Valkey, conseguimos aumentar o desempenho para 999.8 mil requisições SET por segundo. A essência da otimização se resumiu à alocação de 2 VCPUs para tratamento de interrupções e à vinculação das 6 VCPUs restantes às threads de processamento de E/S do Valkey e do Redis para eliminar a migração de manipuladores entre CPUs. sudo ethtool -L ens34 combined 2 # limita o número de manipuladores de IRQ para 2 grep ens34 /proc/interrupts # verifica quais manipuladores estão envolvidos (99 e 100) echo 1 | sudo tee /proc/irq/99/smp_affinity # vincula o manipulador 99 ao núcleo 1 echo 2 | sudo tee /proc/irq/100/smp_affinity # vincular o manipulador 100 ao núcleo 2 # Iniciar o SGBD (para Redis, alterar valkey/valkey:8.1.1 para redis:8.0) com vinculação de contêiner aos 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 testes de desempenho, o seguinte comando foi usado: 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

Fonte: opennet.ru

Adicionar um comentário