Redis Latency Tester
Stima latenza p50/p99 e throughput Redis in 7 scenari workload reali. Confronta Redis 7, Redis Stack, DragonflyDB, KeyDB e Valkey. Bottleneck detection + raccomandazione deployment. KB antirez.
Disclaimer: stime euristiche basate su benchmark pubblici (antirez.com, dragonflydb.io, valkey.io). I valori reali dipendono da hardware, OS scheduler e carico concorrente. Usa redis-cli --latency e redis-benchmark in produzione.
Configura Workload e Topologia
Stime Latenza e Throughput
Redis 7Configurazione ottimale. Monitorare redis-cli INFO stats e slowlog per anomalie in produzione.
Confronto Engine Redis-Compatible
Cache Read-Heavy| Engine | p50 | Throughput max | Pro | Contro |
|---|---|---|---|---|
| Redis 7SelezionatoSSPL + 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. |
Dettaglio Engine e Licenze
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
Configura workload e dimensioni
Scegli il tipo di workload (cache, session store, queue, vector search, ecc.), dimensione chiave/valore in byte e operazioni al secondo target.
Imposta topologia, persistenza ed engine
Seleziona la topologia di deployment (single node, cluster, sentinel), la modalità di persistenza (RDB, AOF) e l'engine da testare tra Redis 7, Redis Stack, DragonflyDB, KeyDB, Valkey.
Leggi le metriche stimate
Controlla latenza p50/p99, throughput massimo, memory footprint e il bottleneck identificato (CPU, memoria, disk fsync, network).
Confronta gli engine
Usa la tabella di confronto e le card dettagliate per valutare pro/contro e licenza di ciascun engine rispetto al tuo scenario.
Suggerimenti
- Usa gli scenari preset (Cache, Vector Search, Cluster Queue) come punto di partenza realistico prima di modificare i singoli parametri.
- Se il bottleneck indicato è "disk-fsync", valuta di passare da AOF always ad AOF everysec se la tua applicazione tollera una finestra di durabilità di 1 secondo.
- Per workload ad altissimo throughput, confronta sempre la topologia cluster multi-shard: distribuire il carico riduce la pressione su CPU e memoria del singolo nodo.
Domande frequenti
Le stime di latenza sono misurazioni reali o calcoli euristici?
Sono stime euristiche basate su benchmark pubblici (antirez.com, dragonflydb.io, valkey.io), non misurazioni dirette del tuo ambiente. Per numeri reali di produzione usa redis-cli --latency e redis-benchmark sul tuo hardware.
Perché AOF always aumenta così tanto la latenza p50?
AOF always esegue un fsync sincrono su disco a ogni scrittura, aggiungendo circa 0.5ms alla latenza p50 nel modello del tool. AOF everysec ha impatto minimo perché il fsync avviene in batch ogni secondo, a scapito di una minima finestra di durabilità.
Perché Vector Search ha un moltiplicatore di latenza 3x?
Le query HNSW su Redis Stack richiedono attraversamento del grafo dell'indice vettoriale, un'operazione più costosa di una GET/SET semplice. Il tool applica un moltiplicatore 3x per riflettere questo overhead nel calcolo del workload vector-search.
Che differenza c'è tra Redis 7, DragonflyDB, KeyDB e Valkey?
Sono tutti engine Redis-compatible con licenze e architetture diverse: Redis 7 è l'originale single-thread event loop, DragonflyDB è multi-thread pensato per throughput elevato, KeyDB è un fork multi-thread di Redis, Valkey è il fork open-source guidato dalla Linux Foundation dopo il cambio licenza di Redis. Le card "Dettaglio Engine" riassumono licenza e feature chiave di ciascuno.
Il tool invia dati a un server per calcolare le stime?
No, tutti i calcoli avvengono client-side nel browser tramite formule euristiche basate sui parametri che inserisci. Nessuna configurazione o dato viene trasmesso a un server esterno.