Redis est monothread, mais écrit en pur C, utilise une boucle d'événements à l'intérieur et gère les connexions de manière asynchrone, de sorte que le nombre de connexions ne l'affecte pas beaucoup à condition que le même nombre de requêtes. Il est capable de gérer les requêtes plus rapidement que votre application ne peut les générer en raison du retard du réseau, du fait que ruby est plus lent que le C compilé et optimisé, etc., vous n'avez donc pas à vous soucier du fait qu'il soit monothread.
L'augmentation du nombre de connexions est bénéfique pour les requêtes simultanées provenant de différents threads car il n'est pas nécessaire d'attendre que la réponse soit livrée sur le réseau pour déverrouiller la connexion, et ruby peut effectuer des E/S parallèles.
Vous pouvez également savoir si le pool est trop petit lorsque les délais de vérification de la connexion deviennent pires que ce que vous attendez/tolérez et que le thread/travailleur correspondant est inactif en attendant, alors comparez votre code et examinez attentivement votre utilisation réelle et vos modèles de comportement. /P>
D'un autre côté, je déconseille d'utiliser toute la limite du nombre de connexions, il y a des moments où vous pourriez avoir besoin de ces connexions supplémentaires. Par exemple :
- pour des redémarrages dyno gracieux/"zéro temps d'arrêt" ("preboot"), vous avez besoin de deux fois plus de connexions, car les anciens processus sont encore en cours d'exécution pendant un certain temps
- conservez au moins une connexion libre pour le débogage d'urgence, car vous voudrez peut-être pouvoir vous connecter depuis la console/directement et voir quelles données se trouvent à l'intérieur en cas de surcharge inattendue
