Valkey: миллион RPS c напёрстком дёгтя
Мы (R&D-банда devhands.io) закончили тестирование официального релиза Valkey и его сравнение с прародителем, Redis, форком которого тот является. Для тех, кто не очень в курсе: Valkey появился на свет после смены лицензии Redis, под покровительством облачных провайдеров, в первую очередь AWS.
Основное внимание мы уделили пропускной способности и времени отклика в зависимости от параметра io-threads, отвечающего за «частичный параллелизм» в этих продуктах.
Подробности тестового стенда и методика тестирования приведена в конце статьи. На следующих графиках представлены результаты. Сначала обратимся к пропускной способности и времени отклика Redis.
Redis: пропускная способность
.
Redis: время отклика
.
Видно, что даже с одним I/O-тредом пропускная способность Redis не то чтобы маленькая, примерно 160.000 RPS (requests per second, запросов в секунду). И она, вопреки расхожему мнению о неспособности Redis масштабироваться по ядрам — может вырасти примерно в 2–2.5 раза. Однако уже при числе I/O-тредов выше 8 масштабирование по ядрам нее имеет смысла, что хорошо видно и по графику пропускной способности, и по графику времени отклика: оно начинает заметно расти, производительность деградирует.
Valkey же показал заметно лучше результаты:
Valkey: пропускная способность
.
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
Результаты хорошо согласуются с официальными бенчмарками на 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/
