Redis è un filo unico. Allora perché dovrei usare la lattuga?

Perché trascorri del tempo non solo mentre Redis esegue i comandi, ma anche trasferendo dati (invio di comandi, ricezione di risultati). In modalità thread singolo durante il trasferimento, Redis non funziona. Mentre Redis funziona, non si verifica alcun trasferimento. Sono disponibili connessioni multiple o una connessione pipeline per aiutarti a saturare sia la larghezza di banda che i cicli della CPU.

E Luttece non riguarda solo la velocità. Ti aiuta anche a organizzare meglio il tuo codice con l'API asincrona e reattiva.

Tornando all'argomento delle prestazioni, ecco un semplice benchmark per ottenere una comprensione generale dell'impatto del threading e del pooling. Nota che mentre il pooling è un po' più lento (dedichi un po' di tempo alle operazioni del pool), ti consente di isolare le azioni (quindi un errore non influisce sugli altri thread) e utilizzare MULTI e comandi di blocco.

Ecco i miei risultati (il sistema locale ha 4 core, la CPU del sistema remoto è circa 2 volte più lenta):

Fili=1

Fili=2

  Benchmark (indirizzo) Modalità CNT SCOPO ERROR UNITSLETUCETHReads.Poooled Thrpt 25 56938.187 ± 2727.772 Ops/SletuCeTheReads.Pooled Localhost 2506.748 ± 2091.631 Ops/SletuuCeThereadshreed. socket thrpt 25 81195.900 ± 1593.424 ops/sLettuceThreads.shared localhost thrpt 25 78404.688 ± 3878.044 ops/sLettuceThreads.shared remote thrpt 25 3992.023 ± 39.092 ops/s 

Fili=4

  Benchmark (indirizzo) Modalità CNT SCOPO ERRORE UNITSLETUCETHReads.Poooled Thrpt 25 87345.126 ± 8149.009 OPS/SLETTUCETHREADS.Pooled Local Thrt 25 75003.031 ± 4481.289 Ops/SletuCeThereads. socket thrpt 25 169112.489 ± 3749.897 ops/sLettuceThreads.shared localhost thrpt 25 115464.778 ± 5099.728 ops/sLettuceThreads.shared remote thrpt 25 7952.492 ± 133.521 ops/s 

Puoi vedere qui che le prestazioni si adattano molto bene al numero di fili, quindi la lattuga non è inutile.