Мы (R&D-банда devhands.io) закончили тестирование официального релиза Valkey и его сравнение с прародителем, Redis, форком которого тот является. Для тех, кто не очень в курсе: Valkey появился на свет после смены лицензии Redis, под покровительством облачных провайдеров, в первую очередь AWS.

Основное внимание мы уделили пропускной способности и времени отклика в режиме чтения - в зависимости от параметра io-threads, отвечающего за "частичный параллелизм" в этих продуктах. Забегая вперед, скажем, что в режиме записи результаты похожие и все пропорции сохраняются - всё-таки это in-memory store.

Подробности тестового стенда и методика тестирования приведена в конце статьи. На следующих графиках представлены результаты. Сначала обратимся к пропускной способности и времени отклика Redis.

.

.

Видно, что даже с одним I/O-тредом пропускная способность Redis не то чтобы маленькая, примерно 160.000 RPS (requests per second, запросов в секунду). И она, вопреки расхожему мнению о неспособности Redis масштабироваться по ядрам – может вырасти примерно в 2-2.5 раза. Однако уже при числе I/O-тредов выше 8 масштабирование по ядрам не имеет смысла, что хорошо видно и по графику пропускной способности, и по графику времени отклика: оно начинает заметно расти, производительность деградирует.

Valkey же показал заметно лучше результаты:

.

.

Несмотря на то, что в однотредовом режиме Valkey стартует с той же производительности, что и Redis - примерно 160.000 RPS, затем пропускная способность взлетает почти до 900.000 RPS (мы "выжимали" и миллион, но на меньшем количестве и размере ключей - о методике тестирования см. ниже). При этом время отклика остается фантастически низким: ниже 0.1 миллисекунды (а это, на секундочку, всего 100 микросекунд).

Нельзя не обратить внимание на то, что произвотельность не растет при увеличении числа I/O-тредов выше 8. Скорее всего, родовая проблема single-main-thread архитектуры и Redis и Valkey. И именно столько - 8 тредов - стоит у разработчиков valkey в якорных маркетинговых бенчмарках (unlocking 1 million RPS). Имейте в виду это при планировании мощностей: на мощных боксах придется либо раскидывать ключи по разным инстансам, либо использовать кластерный режим (который, кстати, в обоих проект отлично работает).

Итак, саммари сравнения:
(1) Redis масштабируется по ядрам, но не очень хорошо.
(2) Valkey выдает в 2.5 раза больше RPS при сильно меньшей latency
(3) Ни один, ни второй не увеличивают пропускную спосоность при числе тредов больше 8

Valkey показывает отличный результат! Несмотря на небольшую "ложку дёгтя" в виде отсутствия масштабирования по ядрам на нодах с CPU выше 8, которой и ложкой-то не назовешь - так, наперсток. Что дальше? А дальше мы продолжаем отвечать на вопрос, которому не меньше 20 лет: нужен ли Хайлоад-проекту кеш-слой в 2024м году. Поэтому на стендах уже PostgreSQL 17 (уже выдает на стенде свой миллион+ RPS, но отжирает весь проц), а скоро будет MySQL 8.4 (детка, верим в тебя), Memcached и DragonFly.

Телеграм-канал автора: https://t.me/rybakalexey.

Методика тестирования

• bare metal Xeon Gold 6312U 24/48vCPU, 128G

• режим без записи на диск (без снэпшотирования и aof)

• redis-benchmark, GET commands, -c 64 --threads 16

• 10 миллионов ключей по 256 байт каждый

• 5 миллионов запросов для вычисления latency / throughput

• Valkey 8.0.0, Redis 7.2.5

Результаты хорошо согласуются с официальными бенчмарками на EC2 C7g.16xlarge instance:

"The data demonstrates a substantial performance improvement with the new I/O threads approach. Throughput increased by approximately 230%, rising from 360K to 1.19M requests per second compared to Valkey 7.2 Latency metrics improved across all percentiles, with average latency decreasing by 69.8% from 1.792 ms to 0.542 ms.
Tested with 8 I/O threads, 3M keys DB size, 512 bytes value size, and 650 clients running sequential SET commands using AWS EC2 C7g.16xlarge instance".
https://valkey.io/blog/unlock-one-million-rps/