O Redis é single-threaded, mas escrito em C puro, usa um loop de eventos dentro e manipula as conexões de forma assíncrona, portanto, a contagem de conexões não o afeta muito, desde que o mesmo número de solicitações. Ele é capaz de lidar com solicitações mais rapidamente do que seu aplicativo pode gerá-las devido ao atraso da rede, Ruby sendo mais lento que compilado e otimizado C, etc., então você não precisa se preocupar com o fato de ser single-thread.

O aumento do número de conexões é benéfico para solicitações simultâneas de diferentes threads porque não há necessidade de esperar que a resposta seja entregue pela rede para desbloquear a conexão, além do Ruby poder fazer E/S paralelas.

Além disso, você pode dizer se o pool é muito pequeno quando os tempos de check-out da conexão se tornam piores do que você espera/tolera e o thread/worker correspondente está ocioso enquanto espera por ele, então compare seu código e dê uma boa olhada em seu uso real e padrões de comportamento.

Por outro lado, eu desaconselho o uso de todo o limite de contagem de conexões, há momentos em que você pode precisar dessas conexões extras. Por exemplo:

• para reiniciar o dyno gracioso/"zero downtime" ("pré-inicialização"), você precisa do dobro das conexões, pois os processos antigos ainda estão em execução por algum tempo
• mantenha pelo menos uma conexão livre para depuração de emergência, pois você pode querer se conectar do console/diretamente e ver quais dados estão dentro quando ocorrer algum carregamento inesperado