Misurare Redis: latenza, SLOWLOG e memoria per chiave

In breve. «Redis è lento» e «Redis consuma troppo» non sono misure. Le misure sono tre. redis-cli --intrinsic-latency cronometra il sistema operativo, non il database: qui il picco è stato di 1.218 microsecondi, ritardo che Redis non ha causato. La SLOWLOG dà i comandi lenti: un SORT su 200.000 elementi con LIMIT 0 10 ha bloccato il server per 255.950 microsecondi. La differenza di used_memory dà la memoria per chiave: 100.000 stringhe da 100 byte sono costate 202,54 byte ciascuna, mentre MEMORY USAGE ne dichiarava 184 e lo stimatore del sito 160. Ma la misura che insegna di più è un'altra: mentre un client eseguiva SORT in ciclo, un secondo ha misurato 238,24 ms di media sul PING, e di quei PING la SLOWLOG non ha traccia.

Metodo. Ogni comando è stato eseguito l'8 novembre 2026 e ogni numero viene da quell'esecuzione. Dove l'uscita era lunga l'ho tagliata e gli argomenti della SLOWLOG stanno su una riga: i numeri sono quelli usciti. In fondo, i numeri non trasferibili.

L'ambiente, prima dei numeri

La macchina e le versioni

$ redis-server --version
Redis server v=8.0.5 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=d47fc40702b1fad8
$ redis-server --port 6392 --save "" --appendonly no --daemonize yes --dir /tmp/redis6392
$ redis-cli -p 6392 info server | grep -E "redis_version|^os|io_threads_active"
redis_version:8.0.5
os:Linux 7.0.0-42-generic x86_64
io_threads_active:0
$ nproc
12
$ grep -m1 "model name" /proc/cpuinfo
model name  : AMD Ryzen 5 5600H with Radeon Graphics
$ cat /proc/loadavg
1.37 11.43 21.43 3/2377 763499

Tre righe vanno lette insieme. È un portatile con 12 thread, non un server. Il carico medio a quindici minuti è 21,43: altri processi pesanti usavano la CPU. E io_threads_active:0 dice che i comandi girano in un solo thread.

Tre istanze, e perché tre

• Redis 8.0.5 nativo, porta 6392, senza persistenza: la latenza non raccoglie il costo del disco. È dove scrivo.
• Redis Stack 7.4.7 in contenitore, su 127.0.0.1:6398: ripete ciò che dipende dalla versione.
• L'istanza di sviluppo del sito, porta 6379, 2.439 chiavi: qui leggo soltanto, perché è un dato reale.

Le tre voci non sono ambienti equivalenti: rispondono a obiezioni diverse. La prima isola Redis dal disco, la seconda la versione, la terza porta dati veri. Pesa la terza, e la sua regola vale anche per te: una misura che altera i dati che sta misurando non è una misura, è un danno.

La cassetta degli attrezzi, e a cosa risponde ciascun pezzo

• --intrinsic-latency: il minimo che l'hardware concede, Redis escluso.
• --latency e --latency-history: il costo di un giro client-server.
• redis-benchmark: quante richieste al secondo regge.
• SLOWLOG GET: quali comandi hanno superato la soglia di esecuzione.
• LATENCY LATEST e LATENCY DOCTOR: quando il server si è fermato.
• INFO commandstats e INFO latencystats: costo per comando lato server.
• INFO memory: memoria in uso, residente, frammentata.
• MEMORY USAGE: quanto pesa una chiave, per confronto.
• --bigkeys e --memkeys: chi ha più elementi dentro e chi occupa più byte.

L'ordine va da fuori verso dentro, dall'hardware alla singola chiave. Il criterio che conta è che nessuno di questi comandi risponde a più di una domanda, e i due errori più comuni nascono dal confonderli: leggere --latency come costo di un comando, e sommare MEMORY USAGE come un bilancio. Le sezioni che seguono smontano entrambi.

Prima misura: la macchina, senza Redis

--intrinsic-latency non misura Redis

Non apre nemmeno una connessione: esegue un ciclo stretto e cronometra quanto il sistema operativo gli ruba. La documentazione avverte del dettaglio che rovina più misure: va eseguito sul server.

$ redis-cli --intrinsic-latency 10
Max latency so far: 1 microseconds.
Max latency so far: 104 microseconds.
Max latency so far: 1218 microseconds.

211012952 total runs (avg latency: 0.0474 microseconds / 47.39 nanoseconds per run).
Worst run took 25701x longer than the average latency.

La media, 47 nanosecondi, non interessa a nessuno. Il picco è 1.218 microsecondi: un processo resta fermo 1,2 ms senza che Redis esista, e il peggiore è 25.701 volte la media.

Un'esecuzione precedente, a carico più basso, aveva dato un picco di 83 microsecondi: quindici volte meglio, stessa macchina, stesso comando. Se il requisito è «p99 sotto il millisecondo», qui non lo rispetti nemmeno a Redis spento.

Il PING come sonda, e chi ne paga il prezzo

--latency-history manda PING e chiude una finestra ogni -i secondi, stampando minimo, massimo, media e campioni. Accanto, lo stesso intervallo visto dal server:

$ redis-cli -p 6392 config resetstat
OK
$ timeout 12 redis-cli -p 6392 --latency-history -i 5
0 8 0.19 484
 -- 5.00 seconds range
$ redis-cli -p 6392 info commandstats | grep cmdstat_ping
cmdstat_ping:calls=1157,usec=1503,usec_per_call=1.30,rejected_calls=0,failed_calls=0
$ redis-cli -p 6392 info latencystats | grep latency_percentiles_usec_ping
latency_percentiles_usec_ping:p50=1.003,p99=3.007,p99.9=8.031

Il client dice 190 microsecondi di media; il server 1,30 microsecondi per chiamata, p50 a 1,003. Oltre il 99 per cento di quello che il client misura non è Redis: è rete, scheduler, libreria.

Quindi --latency dice se il percorso fra applicazione e Redis è sano, non se Redis esegue bene i comandi. Per la seconda domanda servono commandstats e latencystats.

redis-benchmark: lo stesso server, quattro numeri diversi

$ redis-benchmark -p 6392 -q -n 50000 -t set,get
SET: 82918.74 requests per second, p50=0.311 msec
GET: 82918.74 requests per second, p50=0.311 msec
$ redis-benchmark -p 6392 -q -n 50000 -t set -c 1
SET: 38372.98 requests per second, p50=0.023 msec
$ redis-benchmark -p 6392 -q -n 50000 -t set -P 16
SET: 1282051.25 requests per second, p50=0.367 msec

# attraverso il port forwarding di Docker (127.0.0.1:6398 -> contenitore:6379), Redis 7.4.7
$ redis-benchmark -p 6398 -q -n 50000 -t set -c 1
SET: 17205.78 requests per second, p50=0.055 msec
# lo stesso server, misurato da dentro il contenitore
$ docker exec art9-redis-stack redis-benchmark -q -n 50000 -t set -c 1
SET: 38314.18 requests per second, p50=0.023 msec

Con un client: 38.373 richieste al secondo, mediana 0,023 ms. Con i 50 di default: 82.919, mediana 0,311 ms, tredici volte tanto. Con la pipeline da 16: 1,28 milioni. Tre domande, non tre verità.

Le ultime due righe stavano per farmi scrivere che la linea 7 è più lenta. Lo stesso server dà 17.206 richieste al secondo da fuori il contenitore e 38.314 da dentro: il 55,1 per cento se ne andava nel port forwarding.

Seconda misura: quali comandi sono lenti, e per chi

Le soglie che decidono cosa è lento

$ redis-cli -p 6392 config get slowlog-log-slower-than
1) "slowlog-log-slower-than"
2) "10000"
$ redis-cli -p 6392 config get slowlog-max-len
1) "slowlog-max-len"
2) "128"
$ redis-cli -p 6392 config get latency-monitor-threshold
1) "latency-monitor-threshold"
2) "0"

Identici su 8.0.5, 7.4.7 e sull'istanza del sito: nella SLOWLOG finisce solo ciò che supera 10.000 microsecondi, la coda tiene 128 voci, il monitor è spento.

Quattro comandi O(N) su dati realistici

$ redis-cli -p 6392 config set slowlog-log-slower-than 1000
OK
$ redis-cli -p 6392 slowlog reset
OK
$ redis-cli -p 6392 llen coda ; redis-cli -p 6392 hlen sessione
200000
50000
$ redis-cli -p 6392 lrange coda 0 -1 > /dev/null
$ redis-cli -p 6392 hgetall sessione > /dev/null
$ redis-cli -p 6392 keys 'key:0*' > /dev/null
$ redis-cli -p 6392 sort coda alpha limit 0 10 > /dev/null
$ redis-cli -p 6392 --no-raw slowlog get 4
1) 1) (integer) 4
   3) (integer) 255950
   4) 1) "sort"  2) "coda"  3) "alpha"  4) "limit"  5) "0"  6) "10"
2) 1) (integer) 3
   3) (integer) 22837
   4) 1) "keys"  2) "key:0*"
3) 1) (integer) 2
   3) (integer) 14278
   4) 1) "hgetall"  2) "sessione"
4) 1) (integer) 1
   3) (integer) 8331
   4) 1) "lrange"  2) "coda"  3) "0"  4) "-1"

La graduatoria sorprende. LRANGE coda 0 -1, 200.000 elementi, costa 8,3 ms; HGETALL su 50.000 campi 14,3 ms; KEYS key:0* 22,8 ms. E SORT con LIMIT 0 10, che ne restituisce dieci, costa 256 ms.

La complessità documentata di SORT è O(N+M·log M), con N pari agli elementi della collezione: il LIMIT riduce M, non N, quindi Redis ordina tutto e poi taglia. Serve un sorted set mantenuto in scrittura: il primo articolo della serie lo misura.

La vittima non compare nella SLOWLOG

Un client ripete SORT per circa cinque secondi; nello stesso momento un secondo client misura il PING:

$ ( for i in $(seq 1 25); do redis-cli -p 6392 sort coda alpha limit 0 10 > /dev/null; done ) &
$ sleep 0.3
$ timeout 12 redis-cli -p 6392 --latency-history -i 5
196 248 238.24 21
 -- 5.20 seconds range
0 243 1.90 414
 -- 5.01 seconds range
$ redis-cli -p 6392 slowlog len
29
$ redis-cli -p 6392 slowlog get 128 | grep -E "^(ping|sort|keys|hgetall|lrange)$" | sort | uniq -c
      1 hgetall
      1 keys
      1 lrange
     26 sort
$ redis-cli -p 6392 info commandstats | grep cmdstat_ping
cmdstat_ping:calls=4977,usec=6392,usec_per_call=1.28,rejected_calls=0,failed_calls=0

Nella prima finestra il PING costa 238,24 ms di media, minimo 196: non un picco, il regime. Finito il ciclo torna a 1,90 ms. Ma nelle ventinove voci di SLOWLOG ci sono zero PING.

I 4.977 PING sono stati eseguiti in 1,28 microsecondi l'uno. La documentazione dice perché: il tempo registrato è solo «il tempo necessario a eseguire il comando, l'unica fase in cui il thread è bloccato». Chi ha aspettato 238 ms era in coda, non lento.

Un campione non è una misura

$ redis-cli -p 6392 --no-raw slowlog get 12 | grep -E "^\s+3\) \(integer\)"
    3) (integer) 296149
    3) (integer) 302254
    3) (integer) 529203
    3) (integer) 613418
    3) (integer) 611342
    3) (integer) 620495
    3) (integer) 612992
    3) (integer) 612236
    3) (integer) 403879
    3) (integer) 296428
    3) (integer) 526522
    3) (integer) 418588
$ redis-cli -p 6392 info latencystats | grep latency_percentiles_usec_sort
latency_percentiles_usec_sort:p50=528482.303,p99=620756.991,p99.9=620756.991

Dodici esecuzioni dello stesso comando sugli stessi dati: da 296 a 620 millisecondi, media 487 ms. Un gruppo precedente di 26, a carico più basso, dava 246 ms. Il numero onesto è «fra 0,3 e 0,6 secondi su questa macchina».

Su un SORT cronometrato da fuori ho letto 0,63 s, la SLOWLOG 627.420 microsecondi, LATENCY LATEST 627 ms: tre strumenti, un fatto. Se non coincidono, «sto misurando due cose diverse».

La coda che dimentica, e il monitor che è spento

$ redis-cli -p 6392 config set slowlog-max-len 3
OK
$ redis-cli -p 6392 slowlog reset
OK
$ for i in 1 2 3 4 5; do redis-cli -p 6392 hgetall sessione > /dev/null; done
$ redis-cli -p 6392 slowlog len
3

$ redis-cli -p 6392 latency latest        # con threshold 0: nessuna riga
$ redis-cli -p 6392 config set latency-monitor-threshold 100
OK
$ for i in 1 2 3; do redis-cli -p 6392 sort coda alpha limit 0 10 > /dev/null; done
$ redis-cli -p 6392 latency latest
command
1794121372
607
627
$ redis-cli -p 6392 latency doctor
1. command: 2 latency spikes (average 617ms, mean deviation 10ms, period 0.50 sec). Worst all time event 627ms.

Cinque comandi lenti, tre voci conservate: con il default di 128 e decine al minuto, la SLOWLOG copre pochi minuti e va raccolta, non consultata il giorno dopo.

Il monitor risponde a un'altra domanda: quando il server si è fermato, anche per cause che non sono comandi. Fra gli eventi documentati ci sono fork e aof-fsync-always, invisibili alla SLOWLOG.

Che cosa ha registrato l'istanza del sito

$ redis-cli -p 6379 slowlog len
3
$ redis-cli -p 6379 --no-raw slowlog get 3
1) 3) (integer) 23310    4) 1) "SCAN" 2) "0" 3) "COUNT" 4) "1000"
2) 3) (integer) 15598    4) 1) "SCAN" 2) "0" 3) "MATCH" 4) "article:*" 5) "COUNT" 6) "1000"
3) 3) (integer) 53605    4) 1) "SCAN" 2) "0" 3) "COUNT" 4) "1000"
$ redis-cli -p 6379 info commandstats | sed 's/^cmdstat_//' | head -4
hget:calls=4852,usec=72620,usec_per_call=14.97,rejected_calls=0,failed_calls=0
ttl:calls=2444,usec=987,usec_per_call=0.40,rejected_calls=0,failed_calls=0
memory|usage:calls=362,usec=59713,usec_per_call=164.95,rejected_calls=0,failed_calls=0
scan:calls=51,usec=114154,usec_per_call=2238.31,rejected_calls=0,failed_calls=0

Tre voci, tutte SCAN, da 15,6 a 53,6 ms. E non sono traffico dell'applicazione: sono comandi di diagnosi, miei e di chi ha misurato prima.

Su un'istanza che serve due operazioni al secondo, le uniche cose lente abbastanza per la SLOWLOG sono gli strumenti di misura. MEMORY USAGE costa 164,95 microsecondi per chiave: tre minuti su un milione.

Terza misura: quanto costa una chiave

La differenza di used_memory è l'unica che non bara

$ redis-cli -p 6392 flushall
OK
$ redis-cli -p 6392 info memory | grep -E "^(used_memory|mem_fragmentation_ratio):"
used_memory:1083720
mem_fragmentation_ratio:2.65
$ python3 -I -c "v='v'*100; print('\n'.join('SET key:%06d %s'%(i,v) for i in range(1,100001)))" | redis-cli -p 6392 --pipe
All data transferred. Waiting for the last reply...
errors: 0, replies: 100000
$ redis-cli -p 6392 info memory | grep -E "^(used_memory|used_memory_human|used_memory_rss|mem_fragmentation_ratio):"
used_memory:21338024
used_memory_human:20.35M
used_memory_rss:30908416
mem_fragmentation_ratio:1.45
$ redis-cli -p 6392 memory usage key:000001 ; redis-cli -p 6392 strlen key:000001
184
100

La differenza è 20.254.304 byte per 100.000 chiavi: 202,54 byte per chiave, con valore di 100 byte e chiave di 10 caratteri. Il doppio di quello che hai scritto. Sulla 7.4.7: 194,98 byte.

Guarda anche il mem_fragmentation_ratio: 2,65 da vuota, 1,45 da piena. Su un dataset minuscolo quel rapporto non significa niente.

MEMORY USAGE confronta, non somma

$ redis-cli -p 6392 info memory | grep -E "^used_memory:"
used_memory:28001808
# somma riportata da --memkeys: 18400000 (stringhe) + 2941138 (lista) + 2924400 (hash)
$ python3 -I -c "print(28001808 - (18400000+2941138+2924400))"
3736270
$ redis-cli -p 6392 memory usage coda ; redis-cli -p 6392 memory usage coda samples 0
2941138
3311440
$ redis-cli -p 6392 memory usage sessione ; redis-cli -p 6392 memory usage sessione samples 0
2924400
2924400

Sulla singola chiave mancano 18,54 byte dei 202,54 reali, il 9,2 per cento: la quota della tabella delle chiavi, non attribuita a nessuno. Sommando tutte le chiavi mancano 3.736.270 byte, il 13,3 per cento di used_memory.

E sui tipi aggregati campiona cinque valori annidati, come dichiara la sua pagina. Sull'hash, con campi uguali, i due numeri coincidono; sulla lista, dove la lunghezza varia, il default sottostima dell'11,2 per cento rispetto a SAMPLES 0.

Lo stimatore di questo sito sbaglia del 21 per cento

Sul sito c'è uno strumento che stima latenza, throughput e memoria di Redis. La formula dichiarata nel suo commento è «chiavi × (chiave + valore + 50 byte) / 1.048.576». Con i miei parametri:

$ python3 -I -c "
keys=100000; stima=keys*(10+100+50); reale=20254304
print('stima  = %d byte = %.2f MB' % (stima, stima/1048576))
print('reale  = %d byte = %.2f MB' % (reale, reale/1048576))
print('sottostima = %.2f%%' % (100*(1-stima/reale)))"
stima  = 16000000 byte = 15.26 MB
reale  = 20254304 byte = 19.32 MB
sottostima = 21.00%

Lo scarto è del 21,00 per cento, nella direzione pericolosa: la stima promette che ci stai, la misura no. Leggendo il codice invece del commento c'è di peggio, e lo dichiaro perché il difetto è mio.

Alla riga 143 il calcolo moltiplica i byte per chiave per input.opsPerSec, e in RedisInput un campo «numero di chiavi» non esiste: il modello usa le operazioni al secondo come se fossero chiavi. È una stima euristica, dichiarata tale nel suo header, e una decisione di capacità la chiude la misura.

--bigkeys e --memkeys non misurano la stessa cosa

$ redis-cli -p 6392 --bigkeys | grep -E '^Biggest|strings with'
Biggest   list found "coda" has 200000 items
Biggest   hash found "sessione" has 50000 fields
Biggest string found "key:033846" has 100 bytes
100000 strings with 10000000 bytes (100.00% of keys, avg size 100.00)
$ redis-cli -p 6392 --memkeys | grep -E '^Biggest|strings with'
Biggest   list found "coda" has 2941138 bytes
Biggest   hash found "sessione" has 2924400 bytes
Biggest string found "key:033846" has 184 bytes
100000 strings with 18400000 bytes (100.00% of keys, avg size 184.00)

--bigkeys conta elementi: per lui coda, con 200.000 voci, è quattro volte sessione. --memkeys conta byte: 2.941.138 contro 2.924.400, pari. Sulla stringa, 100 byte contro 184.

Entrambi usano SCAN, quindi non bloccano il server come KEYS, ma per dimensionare serve --memkeys e per trovare la struttura che degrada un comando O(N) serve --bigkeys.

Le chiavi di questo sito: 2.920 byte per 1.536 di vettore

$ redis-cli -p 6379 dbsize
2439
$ redis-cli -p 6379 object encoding article:1416:en ; redis-cli -p 6379 hstrlen article:1416:en embedding
hashtable
1536
$ redis-cli -p 6379 memory usage article:1416:en
2880
$ redis-cli -p 6379 --scan --pattern 'article:*' --count 1000 | head -200 \
    | awk '{print "MEMORY USAGE "$0}' | redis-cli -p 6379 | python3 -I -c "
import sys; v=sorted(int(x) for x in sys.stdin)
print('n =',len(v),'min =',v[0],'max =',v[-1],'media = %.2f'%(sum(v)/len(v)),'mediana =',v[len(v)//2])"
n = 200 min = 2764 max = 3225 media = 2920.09 mediana = 2918

Ogni articolo è un hash di sei campi, uno è un vettore di 1.536 byte (384 dimensioni a 32 bit). MEMORY USAGE dichiara 2.880 byte, 1,875 volte il vettore; su 200 chiavi la media è 2.920,09.

La proiezione sulle 2.426 chiavi dell'indice dà 6,76 MB, e used_memory dice 7.465.736 byte: coerente. Così si risponde a «quanto costa indicizzare il doppio degli articoli».

Il trade-off, e dove questo metodo non arriva

Avrei potuto misurare meglio: macchina dedicata, dieci ripetizioni per punto, client su un altro host, valori reali invece di cento byte uguali. Ho scelto la misura che si fa in mezz'ora: una misura imperfetta e dichiarata cambia una decisione, una perfetta che non fai non cambia niente.

Il prezzo è che il valore assoluto non è trasferibile. Il guadagno è che il rapporto fra due numeri presi nello stesso minuto resta valido: 1 microsecondo di esecuzione contro 190 di latenza vista dal client, 202,54 byte reali contro 160 stimati. È il gradino fra un intermedio e un senior: non più comandi, ma l'ambiente accanto a ogni numero.

I numeri di questo articolo che NON puoi portare in produzione

• I throughput (82.919, 38.373, 1.282.051, 17.206 al secondo): portatile, client e server sulla stessa macchina.
• Le latenze assolute (0,023 ms, 0,311 ms, 0,19 ms): senza una rete reale.
• I 256 e i 627 ms di SORT: si trasferisce l'ordine di grandezza rispetto a un GET, non il valore.
• I 202,54 byte per chiave: valgono per quelle chiavi e quei valori. Il metodo sì, il numero no.
• La produzione non è verificata: senza accesso al VPS parlo dell'istanza di sviluppo, e la produzione potrebbe non essere la 8.0.5.

Il criterio che tiene insieme le cinque voci è uno: cade ciò che è assoluto, resta ciò che è un rapporto. Le prime quattro le annulli rifacendo le prove sulla tua macchina. L'ultima no: finché nessuno legge la configurazione di produzione, nessun numero di produzione esiste.

Domande frequenti

Perché la SLOWLOG è vuota se gli utenti vedono timeout?

Perché registra il tempo di esecuzione, non l'attesa in coda. Nella mia prova 4.977 PING sono costati 238 ms di media visti dal client senza produrre nessuna voce: il server li eseguiva in 1,28 microsecondi.

MEMORY USAGE basta per dimensionare un'istanza Redis?

No. Sulla singola chiave ha dichiarato 184 byte contro 202,54 reali, e la somma su tutta l'istanza ha lasciato fuori il 13,3 per cento di used_memory. Sulla mia lista sottostimava anche dell'11,2 per cento rispetto a SAMPLES 0.

Che differenza c'è fra --latency e --intrinsic-latency?

--latency misura il giro completo di un PING: rete, client e server. --intrinsic-latency non si collega a niente, cronometra quanto il sistema operativo ruba a un ciclo stretto e va eseguito sul server: qui ha dato un picco di 1,2 ms senza Redis.

Cosa sai fare adesso

Hai un protocollo in tre passi. Sai che la SLOWLOG denuncia il colpevole e non la vittima, e che per vederla servono commandstats, latencystats e il monitor di latenza. E che la memoria di una chiave si misura con una differenza, non con una formula.

Il resto della serie applica questi strumenti a decisioni concrete. Persistenza, RDB e AOF spiega perché l'appendfsync che ho tolto cambia tutti i numeri di latenza; maxmemory ed eviction è la decisione che si prende con i byte per chiave in mano; Lua mostra un comando bloccante voluto; Pub/Sub o Streams è dove «quanto è lento» diventa «quanti messaggi restano indietro». Per l'indice vettoriale c'è il setup di RediSearch, che non misura il costo per chiave. Prima di questo articolo c'è fail-open e fail-closed; il dopo è HNSW in Redis, con recall e latenza misurati.

Se stai dimensionando un'istanza Redis, o cerchi una latenza che non si spiega, e vuoi farlo con qualcuno che ti mostra i comandi invece di consegnarti un numero, puoi prenotare una call.

Fonti

• Redis, Diagnosing latency issues - la natura a thread singolo («a single process serves all the client requests»), l'elenco dei comandi lenti con SORT fra gli esempi, e l'avvertenza che --intrinsic-latency va eseguito «in the server not in the client», consultata il 2026-11-08.
• Redis, SLOWLOG GET - il tempo registrato «does not include I/O operations ... but just the time needed to actually execute the command», il ruolo di slowlog-log-slower-than e slowlog-max-len, e la struttura della voce: sette valori nella pagina corrente, di cui il settimo «Added in Redis 8.10», mentre la mia 8.0.5 ne restituisce sei, consultata il 2026-11-08.
• Redis, Redis latency monitoring - il monitor «is turned off by default (threshold set to 0)», l'elenco degli eventi (command, fast-command, fork, aof-fsync-always) e il consiglio di usare come soglia la latenza massima accettabile, consultata il 2026-11-08.
• Redis, MEMORY USAGE - il campionamento sui tipi annidati, «By default, this option is set to 5» e l'uso di SAMPLES 0 per guardarli tutti, consultata il 2026-11-08.
• Redis, Redis benchmark - «the golden rule of a useful benchmark is to only compare apples and apples» e il fatto che iterare su comandi sincroni misuri la rete e il client, non Redis, consultata il 2026-11-08.
• Redis, SORT - la complessità O(N+M·log(M)) «where N is the number of elements in the list or set to sort, and M the number of returned elements», che spiega il costo con LIMIT, consultata il 2026-11-08.
• Redis, redis-cli - le modalità --bigkeys e --memkeys, entrambe basate su SCAN, e il significato diverso dei loro totali, consultata il 2026-11-08.
• Redis, KEYS - «Use extreme care when using this command in production environments ... Don't use KEYS in your regular application code», consultata il 2026-11-08.
• Misure proprie: tutti i comandi dei blocchi sopra, eseguiti l'8 novembre 2026 su Redis 8.0.5 nativo (porta 6392, --save "", --appendonly no), su Redis Stack 7.4.7 in contenitore (redis/redis-stack-server:latest) e in sola lettura sull'istanza di sviluppo del sito (porta 6379, 2.439 chiavi).
• Codice di questo sito: frontend/src/app/pages/dev-tools/redis-latency-tester/redis-latency.service.ts, commento alle righe 20-23 e calcolo alle righe 143-147; interfaccia RedisInput in redis-latency.models.ts, righe 48-58, letto l'8 novembre 2026.

Le prime otto voci sono pagine che cambiano, e per questo portano la data: se una frase non la ritrovi, è la pagina che si è mossa, non la citazione. Le ultime due si verificano meglio, perché sono comandi e righe di codice che riesegui tu. Dove le due famiglie si contraddicono, vince il comando.