Förutom att spara omkostnader för att ansluta och koppla från där detta annars görs på varje begäran, kan en anslutningspoolare kanalisera ett stort antal klientanslutningar till ett litet antal faktiska databasanslutningar. I PostgreSQL är det optimala antalet aktiva databasanslutningar vanligtvis någonstans runt ((2 * core_count) + effective_spindle_count) . Över detta antal blir både genomströmning och latens sämre.
Ibland kommer folk att säga "Jag vill stödja 2000 användare, med snabb svarstid." Det är ganska garanterat att om du försöker göra det med 2000 faktiska databasanslutningar, kommer prestandan att bli hemsk. Om du har en maskin med fyra fyrkärniga processorer och den aktiva datamängden är helt cachad, kommer du att se mycket bättre prestanda för dessa 2000 användare genom att kanalisera förfrågningarna genom cirka 35 databasanslutningar.
För att förstå varför det är sant bör detta tankeexperiment hjälpa. Tänk på en hypotetisk databasservermaskin med bara en resurs att dela -- en enda kärna. Denna kärna kommer att dela upp lika mycket mellan alla samtidiga förfrågningar utan omkostnader. Låt oss säga att 100 förfrågningar alla kommer in i samma ögonblick, som var och en behöver en sekunds CPU-tid. Kärnan fungerar på dem alla och delar upp dem tills de alla slutar 100 sekunder senare. Tänk nu på vad som händer om du sätter en anslutningspool framför som accepterar 100 klientanslutningar men gör bara en begäran åt gången till databasservern, och lägger alla förfrågningar som kommer när anslutningen är upptagen i en kö. Nu när 100 förfrågningar kommer samtidigt, får en klient ett svar på 1 sekund; en annan får ett svar på 2 sekunder, och den sista klienten får ett svar på 100 sekunder. Ingen behövde vänta längre för att få ett svar, genomströmningen är densamma, men den genomsnittliga latensen är 50,5 sekunder istället för 100 sekunder.
En riktig databasserver har fler resurser som kan användas parallellt, men samma princip gäller, när de väl är mättade skadar du bara saker genom att lägga till fler samtidiga databasförfrågningar. Det är faktiskt värre än exemplet, för med fler uppgifter har du fler uppgiftsväxlar, ökat innehåll för lås och cache, L2 och L3 cachelinjekonflikt och många andra problem som skär in i både genomströmning och latens. Utöver det, medan en hög work_mem inställningen kan hjälpa en fråga på ett antal sätt, den inställningen är gränsen per plannod för varje anslutning , så med ett stort antal anslutningar måste du lämna detta mycket litet för att undvika att tömma cachen eller till och med leda till byte, vilket leder till långsammare planer eller sådana saker som hashtabeller som spills till disken.
Vissa databasprodukter bygger effektivt in en anslutningspool i servern, men PostgreSQL-communityt har tagit ståndpunkten att eftersom den bästa anslutningspoolningen görs närmare klientprogramvaran kommer de att överlåta till användarna att hantera detta. De flesta poolare kommer att ha något sätt att begränsa databasanslutningarna till ett fast antal, samtidigt som de tillåter fler samtidiga klientförfrågningar än så, och ställer dem i kö vid behov. Detta är vad du vill, och det bör göras på en transaktions grund, inte per påstående eller anslutning.