Redis es de subproceso único, pero está escrito en C puro, utiliza un bucle de eventos en su interior y maneja las conexiones de forma asincrónica, por lo que el recuento de conexiones no lo afecta mucho siempre que haya la misma cantidad de solicitudes. Es capaz de manejar solicitudes más rápido de lo que su aplicación puede generar debido a la demora en la red, Ruby es más lento que C compilado y optimizado, etc., por lo que no necesita preocuparse de que sea de un solo subproceso.
Aumentar el número de conexiones es beneficioso para las solicitudes simultáneas de diferentes subprocesos porque no es necesario esperar a que se entregue la respuesta a través de la red para desbloquear la conexión, además, Ruby puede realizar operaciones de E/S paralelas.
También puede saber si el grupo es demasiado pequeño cuando los tiempos de verificación de la conexión son peores de lo que espera/tolera y el subproceso/trabajador correspondiente está inactivo mientras lo espera, así que compare su código y observe bien su uso real y patrones de comportamiento.
Por otro lado, desaconsejaría usar todo el límite de conteo de conexiones, hay momentos en los que podría necesitar estas conexiones adicionales. Por ejemplo:
- para reinicios correctos/"sin tiempo de inactividad" del dinamómetro ("prearranque"), necesita el doble de conexiones, ya que los procesos antiguos todavía se están ejecutando durante algún tiempo
- mantenga al menos una conexión libre para la depuración de emergencia, ya que es posible que desee poder conectarse desde la consola/directamente y ver qué datos hay dentro cuando se produzca una carga alta inesperada
