Redis è a thread singolo, ma scritto in C puro, utilizza un loop di eventi all'interno e gestisce le connessioni in modo asincrono, quindi il conteggio delle connessioni non lo influisce di molto a condizione che lo stesso numero di richieste. È in grado di gestire le richieste più velocemente di quanto la tua applicazione possa generarle a causa del ritardo della rete, del fatto che ruby è più lento del C compilato e ottimizzato, ecc., quindi non devi preoccuparti che sia a thread singolo.
L'aumento del numero di connessioni è vantaggioso per le richieste simultanee provenienti da thread diversi perché non è necessario attendere la consegna della risposta sulla rete per sbloccare la connessione, inoltre ruby può eseguire IO paralleli.
Inoltre puoi sapere se il pool è troppo piccolo quando i tempi di checkout della connessione diventano peggiori di quanto ti aspetti/tolleri e il thread/worker corrispondente è inattivo mentre lo aspetti, quindi confronta il tuo codice e dai un'occhiata ai tuoi modelli di utilizzo e comportamento effettivi.
D'altra parte, sconsiglio di utilizzare tutto il limite di conteggio delle connessioni, ci sono momenti in cui potresti aver bisogno di queste connessioni extra. Ad esempio:
- per riavvii dinamici "zero downtime" ("preboot") sono necessarie due volte le connessioni, poiché i vecchi processi sono ancora in esecuzione per un po' di tempo
- mantieni almeno una connessione libera per il debug di emergenza, poiché potresti volerti connettere dalla console/direttamente e vedere quali dati sono all'interno quando arriva un carico imprevisto
