Oprócz zaoszczędzenia kosztów związanych z łączeniem i rozłączaniem, gdzie jest to wykonywane przy każdym żądaniu, pula połączeń może skierować dużą liczbę połączeń klientów do niewielkiej liczby rzeczywistych połączeń z bazą danych. W PostgreSQL optymalna liczba aktywnych połączeń z bazą danych wynosi zwykle około ((2 * liczba_rdzeni) + liczba_wrzecionów) . Powyżej tej liczby pogarsza się zarówno przepustowość, jak i opóźnienia.
Czasami ludzie powiedzą „Chcę obsłużyć 2000 użytkowników, z szybkim czasem reakcji”. Jest prawie pewne, że jeśli spróbujesz to zrobić przy 2000 rzeczywistych połączeniach z bazą danych, wydajność będzie straszna. Jeśli masz maszynę z czterema czterordzeniowymi procesorami, a aktywny zestaw danych jest w pełni buforowany, zobaczysz znacznie lepszą wydajność dla tych 2000 użytkowników, przesyłając żądania przez około 35 połączeń z bazą danych.
Aby zrozumieć, dlaczego tak jest, ten eksperyment myślowy powinien pomóc. Rozważmy hipotetyczną maszynę serwera bazy danych z tylko jednym zasobem do współużytkowania — pojedynczym rdzeniem. Ten rdzeń będzie równo dzielił czas na wszystkie współbieżne żądania bez narzutu. Powiedzmy, że w tym samym momencie przychodzi 100 żądań, z których każde wymaga jednej sekundy czasu procesora. Rdzeń działa na nich wszystkich, dzieląc czas między nimi, aż wszystkie skończą 100 sekund później. Teraz zastanów się, co się stanie, jeśli umieścisz na początku pulę połączeń, która zaakceptuje 100 połączeń klientów, ale jednocześnie wyśle do serwera bazy danych tylko jedno żądanie, umieszczając w kolejce wszystkie żądania, które przychodzą, gdy połączenie jest zajęte. Teraz, gdy w tym samym czasie nadejdzie 100 żądań, jeden klient otrzymuje odpowiedź w ciągu 1 sekundy; inny otrzymuje odpowiedź w ciągu 2 sekund, a ostatni klient otrzymuje odpowiedź w ciągu 100 sekund. Nikt nie musiał czekać dłużej na odpowiedź, przepustowość jest taka sama, ale średnie opóźnienie wynosi 50,5 sekundy, a nie 100 sekund.
Prawdziwy serwer bazy danych ma więcej zasobów, które mogą być używane równolegle, ale ta sama zasada obowiązuje, gdy zostaną one nasycone, szkodzi tylko dodaniu większej liczby jednoczesnych żądań do bazy danych. W rzeczywistości jest gorzej niż w przykładzie, ponieważ przy większej liczbie zadań masz więcej przełączników zadań, zwiększoną rywalizację o blokady i pamięć podręczną, rywalizację o linie pamięci podręcznej L2 i L3 oraz wiele innych problemów, które wpływają zarówno na przepustowość, jak i opóźnienia. Co więcej, podczas gdy wysoki work_mem ustawienie może pomóc w zapytaniu na wiele sposobów, to ustawienie to limit na węzeł planu dla każdego połączenia , więc przy dużej liczbie połączeń musisz pozostawić to bardzo małe, aby uniknąć opróżniania pamięci podręcznej lub nawet prowadzić do zamiany, co prowadzi do wolniejszych planów lub takich rzeczy, jak rozrzucanie tablic mieszających na dysk.
Niektóre produkty bazodanowe skutecznie budują pulę połączeń na serwerze, ale społeczność PostgreSQL przyjęła stanowisko, że ponieważ najlepsze łączenie połączeń odbywa się bliżej oprogramowania klienta, pozostawienie zarządzania tym użytkownikom. Większość poolerów będzie miała jakiś sposób na ograniczenie połączeń z bazą danych do stałej liczby, jednocześnie zezwalając na więcej jednoczesnych żądań klientów, ustawiając je w kolejce w razie potrzeby. To jest to, czego chcesz i należy to zrobić na transakcyjnej na podstawie, a nie za oświadczenie lub połączenie.
