Redis jest jednowątkowy, ale napisany w czystym C, wykorzystuje pętlę zdarzeń wewnątrz i obsługuje połączenia asynchronicznie, więc liczba połączeń nie ma na nią wpływu przy takiej samej liczbie żądań. Jest w stanie obsłużyć żądania szybciej niż Twoja aplikacja może je wygenerować z powodu opóźnień w sieci, ruby jest wolniejszy niż skompilowany i zoptymalizowany C itp., więc nie musisz się martwić, że jest jednowątkowy.
Rosnąca liczba połączeń jest korzystna dla równoczesnych żądań z różnych wątków, ponieważ nie trzeba czekać na odpowiedź przez sieć, aby odblokować połączenie, a ruby może wykonywać równoległe operacje IO.
Możesz również stwierdzić, czy pula jest zbyt mała, gdy czasy sprawdzania połączenia stają się gorsze niż oczekiwałeś/tolerujesz, a odpowiedni wątek/pracownik jest bezczynny podczas oczekiwania na to, więc porównaj swój kod i dobrze przyjrzyj się swoim rzeczywistym wzorcom użytkowania i zachowania.
Z drugiej strony odradzałbym używanie całego limitu liczby połączeń, są chwile, kiedy możesz potrzebować tych dodatkowych połączeń. Na przykład:
- dla łagodnego/"zero przestojów" restartów dyno ("preboot") potrzebujesz dwa razy więcej połączeń, ponieważ stare procesy wciąż działają przez jakiś czas
- zachowaj co najmniej jedno wolne połączenie do awaryjnego debugowania, ponieważ możesz chcieć połączyć się z konsoli/bezpośrednio i zobaczyć, jakie dane są w środku, gdy pojawi się nieoczekiwane duże obciążenie
