Latency Test for Redis
Estimate latency P50/P99 and throughputs of Redis for 5 workloads with different configurations: Redis 6/RedisStack/DragonFly DB/Ollama (Key-Value)/Valtira, bottleneck analysis & recommended deployments by @antirez.
Disclaimer: heuristic times based on public benchmarks (antirez.com, dragonflydb.io, valkey.io). Real values depend on hardware, OS scheduler and concurrent load. Use `` redis-cli --latency and ``redis-benchmark in production.
Configure Workload and Topology
Latency and Throughput Estimation
Redis 7Configurazione ottimale. Monitorare redis-cli INFO stats e slowlog per anomalie in produzione.
Redis Compatible Concurrency Engine (Ollama)
Cache Read-Heavy| Machine | page 50 | Maximum throughput | For | Against |
|---|---|---|---|---|
| Redis 7SelectedSSPL + RSALv2 (2024) | 113 µs | Ecosistema maturo, client ubiqui, documentazione estesa (antirez blog), supporto Redis Ltd. | Licenza SSPL limita embedding in prodotti SaaS. Single-threaded: bottleneck su molti core. | |
| Redis StackSSPL + RSALv2 (moduli proprietari) | 118 µs | Moduli ufficiali integrati (RediSearch, RedisJSON, TimeSeries). Ideale per RAG e vector store. | Overhead moduli +5-15% memoria. Licenza proprietaria per Redis Stack Server. | |
| DragonflyDBBSL 1.1 (production use requires commercial license) | 79 µs | Multi-threaded: throughput +50% su server multi-core. Memory efficiency migliorata. Compatibile API Redis. | BSL 1.1: uso commerciale richiede licenza. No cluster mode nativo Redis. Ecosistema più giovane. | |
| KeyDBBSD 3-Clause | 96 µs | Multi-threaded BSD. Active Replica per HA con scritture su replica. Flash storage per dataset grandi. | Sviluppo community post-Snap meno attivo. Alcuni comandi Redis 7 non ancora supportati. | |
| ValkeyBSD 3-Clause | 113 µs | BSD 3-Clause, fork Linux Foundation. Drop-in replacement Redis 7.2. Supporto Google/AWS/Oracle. | Nessun modulo equivalente a Redis Stack (RediSearch, RedisJSON) nel core. Roadmap multi-thread in progress. |
Engine Details and Licensing
Il database in-memory originale, creato da Salvatore "antirez" Sanfilippo nel 2009. Single-threaded event loop con I/O multiplexing. Strutture dati native: String, List, Hash, Set, ZSet, Stream, HyperLogLog.
- Single-threaded per operazione (no lock contention)
- Persistence: RDB snapshot + AOF append-only
- Cluster mode nativo (hash slot 16384)
- Pub/Sub e Streams (Redis Streams, Kafka-like)
- Lua scripting + MULTI/EXEC transactions
- Keyspace notifications
Redis 7 + moduli ufficiali: RediSearch (full-text + vector HNSW), RedisJSON (JSON nativo), RedisGraph (dismesso), RedisTimeSeries, RedisBloom. Ideale per RAG, ricerca ibrida, timeseries IoT.
- RediSearch: full-text, vector similarity (HNSW flat/IVF)
- RedisJSON: JSON.GET/SET/ARRAPPEND nativi
- RedisTimeSeries: retention, downsample, aggregazioni
- RedisBloom: Bloom/Cuckoo filter, Count-Min Sketch
- Stessa baseline latenza di Redis 7
- Overhead memoria moduli +5-15% per dataset indexato
Re-implementazione multi-threaded compatibile Redis. Utilizza fibers (Boost.Context) per parallelismo I/O senza lock. Benchmark ufficiali dichiarano 25x throughput vs Redis su server multi-core. Compatibile con client Redis (RESP protocol).
- Multi-threaded shared-nothing architecture
- Fino a 25x throughput su workload GET/SET paralleli
- Dash hash table per menor contention
- Memory efficiency migliorata (~30% vs Redis per stessi dataset)
- Compatibilità API Redis quasi completa (95%+ comandi)
- Nessun cluster mode nativo (single node scale-up)
Fork multi-threaded di Redis. Approccio server-threads per parallelizzare I/O su più CPU core. Supporta Active Replica (ogni replica può essere scritta). Ora sotto guida community dopo acquisizione Snap.
- Multi-threaded server (server-threads config)
- Active Replica: scritture su ogni nodo replica
- Flash storage: overflow su SSD (FLASH tier)
- Moduli Redis compatibili
- LOLWUT e comandi Redis 7 supportati
- Community-driven post-Snap
Fork ufficiale Redis 7.2 sotto Linux Foundation, nato dopo il cambio licenza Redis in SSPL 2024. Mantenuto da AWS, Google, Oracle, Ericsson e altri. Drop-in replacement con stessa API e performance baseline identica.
- Drop-in replacement Redis 7.2 (100% compatibile)
- Licenza BSD 3-Clause (open source permissiva)
- Sviluppo attivo da major cloud provider
- Stessa architettura single-threaded Redis
- Valkey Cluster compatibile con Redis Cluster
- Roadmap: I/O threading migliorato in v9
Come utilizzare Redis Latency Tester
Configure workload and size
Choose workload type (cache, session store, queue, vector search, etc.), key/value size in bytes and operations per second.
Set topology, persistence, and engine
Choose the deployment topology (single node, cluster, sentinel), persistence mode (RDB, AOF) and test engine among Redis 7, Redis Stack, DragonflyDB, KeyDB, Valkey.
Read estimated metrics
Check latency (p50/p99), max throughput, memory footprint, and identified bottleneck (CPU, memory, disk fsync, network).
Compare engines
Use the comparison table and detailed cards to evaluate pros and cons and licensing of each engine compared to your scenario.
Suggerimenti
- Use pre-set scenarios (Cache, Vector Search, Cluster Queue) as a realistic starting point before modifying individual parameters.
- If the indicated bottleneck is "disk-fsync", consider switching from AOF always to AOF every second if your application can tolerate a 1-second durability window.
- For high-throughput workloads, always compare the multi-shard cluster topology: distributing load reduces pressure on a single node's CPU and memory.
Domande frequenti
Are latency estimates based on actual measurements or rough calculations?
Estimates are heuristic based on public benchmarks (antirez.com, dragonflydb.io, valkey.io), not direct measurements of your environment. For actual production numbers use redis-cli --latency and redis-benchmark on your hardware.
Why does AOF always increase latency so much?
AOF always performs synchronous disk sync on writes, adding about 0.5ms to the p50 latency in the tool model. AOF everysec has minimal impact as fsync occurs in batch every second at the cost of a small window of durability.
Why does Vector Search have a latency multiplier of 3x?
Queries on HNSW in Redis Stack require traversal of the vector index graph, a more expensive operation than simple GET/SET. The tool applies a 3x multiplier to reflect this overhead in the calculation of the vector search workload.
What's the difference between Redis 7, DragonflyDB, KeyDB and Valkey?
All engines are Redis-compatible with diverse licenses and architectures: Redis 7 is the original single-thread event loop, DragonflyDB is multi-thread designed for high throughput, KeyDB is a multi-thread fork of Redis, Valkey is an open-source fork guided by the Linux Foundation after Redis's license change. The "Detail Engine" cards summarize each engine's license and key features.
Does the tool send data to a server for calculations?
No, all calculations occur client-side in the browser using heuristic formulas based on the parameters you input. No configuration or data is sent to an external server.