Освен че спестява режийните разходи за свързване и прекъсване, когато това се прави при всяка заявка, пулърът за връзки може да прехвърли голям брой клиентски връзки до малък брой действителни връзки към базата данни. В PostgreSQL оптималният брой активни връзки към базата данни обикновено е някъде около ((2 * core_count) +effective_spindle_count) . Над това число и пропускателната способност, и забавянето се влошават.
Понякога хората ще кажат „Искам да подкрепя 2000 потребители с бързо време за реакция“. До голяма степен е гарантирано, че ако се опитате да направите това с 2000 действителни връзки към базата данни, производителността ще бъде ужасна. Ако имате машина с четири четириядрени процесора и активният набор от данни е напълно кеширан, ще видите много по-добра производителност за тези 2000 потребители, като насочвате заявките през около 35 връзки към базата данни.
За да разберем защо това е вярно, този мисловен експеримент трябва да помогне. Помислете за хипотетична машина за сървър на база данни със само един ресурс за споделяне - едно ядро. Това ядро ще разделя еднакво време между всички едновременни заявки без допълнителни разходи. Да кажем, че 100 заявки идват в един и същи момент, всяка от които се нуждае от една секунда време на процесора. Ядрото работи върху всички тях, като разделя времето между тях, докато всички завършат 100 секунди по-късно. Сега помислете какво се случва, ако поставите пул за връзки отпред, който ще приема 100 клиентски връзки, но прави само една заявка в даден момент към сървъра на базата данни, поставяйки всички заявки, които пристигат, докато връзката е заета, в опашка. Сега, когато 100 заявки пристигат едновременно, един клиент получава отговор за 1 секунда; друг получава отговор за 2 секунди, а последният клиент получава отговор за 100 секунди. Никой не трябваше да чака повече, за да получи отговор, пропускателната способност е същата, но средната латентност е 50,5 секунди, а не 100 секунди.
Истинският сървър на база данни има повече ресурси, които могат да се използват паралелно, но важи същият принцип, след като те са наситени, вие само наранявате нещата, като добавяте повече едновременни заявки за база данни. Това всъщност е по-лошо от примера, защото с повече задачи имате повече превключватели на задачи, повишена конкуренция за заключвания и кеш, конкуренция за L2 и L3 кеш редове и много други проблеми, които намаляват както пропускателната способност, така и латентността. На всичкото отгоре, докато висок work_mem настройката може да помогне на заявка по няколко начина, тази настройка е ограничението на възел на плана за всяка връзка , така че при голям брой връзки трябва да оставите този много малък, за да избегнете прочистване на кеша или дори да доведе до размяна, което води до по-бавни планове или такива неща като хеш таблици, които се разливат на диск.
Някои продукти за бази данни ефективно изграждат пул за връзки в сървъра, но общността на PostgreSQL зае позицията, че тъй като най-доброто обединяване на връзки се прави по-близо до клиентския софтуер, те ще оставят на потребителите да управляват това. Повечето пулери ще имат някакъв начин да ограничат връзките към базата данни до твърд номер, като същевременно позволяват повече едновременни клиентски заявки от това, като ги поставят на опашка, ако е необходимо. Това е, което искате и трябва да се направи на транзакция база, а не за изявление или връзка.
