Redis ist Single-Threaded, aber in reinem C geschrieben, verwendet eine interne Ereignisschleife und verarbeitet Verbindungen asynchron, sodass die Anzahl der Verbindungen es nicht wesentlich beeinflusst, vorausgesetzt, die gleiche Anzahl von Anforderungen. Aufgrund von Netzwerkverzögerungen, Ruby ist langsamer als kompiliertes und optimiertes C usw. kann es Anfragen schneller verarbeiten, als Ihre Anwendung sie erzeugen kann, sodass Sie sich keine Sorgen darüber machen müssen, dass es Single-Threaded ist.
Eine zunehmende Anzahl von Verbindungen ist vorteilhaft für gleichzeitige Anfragen von verschiedenen Threads, da nicht auf die Antwort gewartet werden muss, die über das Netzwerk geliefert wird, um die Verbindung zu entsperren, außerdem kann Ruby parallele IOs ausführen.
Sie können auch feststellen, ob der Pool zu klein ist, wenn die Checkout-Zeiten der Verbindung schlechter werden, als Sie erwarten/tolerieren, und der entsprechende Thread/Worker im Leerlauf ist, während er darauf wartet, also vergleichen Sie Ihren Code und sehen Sie sich Ihre tatsächlichen Nutzungs- und Verhaltensmuster genau an.
Auf der anderen Seite würde ich davon abraten, das gesamte Verbindungslimit zu verwenden, da es Zeiten gibt, in denen Sie diese zusätzlichen Verbindungen benötigen könnten. Zum Beispiel:
- für elegante/"zero downtime" Dyno-Neustarts ("preboot") benötigen Sie doppelt so viele Verbindungen, da alte Prozesse noch einige Zeit laufen
- Halten Sie mindestens eine freie Verbindung für Notfall-Debugging bereit, da Sie sich möglicherweise von der Konsole/direkt verbinden und sehen möchten, welche Daten darin enthalten sind, wenn eine unerwartete Hochlast kommt
