कनेक्ट और डिस्कनेक्ट के ऊपरी हिस्से को बचाने के अलावा, जहां यह अन्यथा प्रत्येक अनुरोध पर किया जाता है, एक कनेक्शन पूलर बड़ी संख्या में क्लाइंट कनेक्शन को वास्तविक डेटाबेस कनेक्शन की एक छोटी संख्या में फ़नल कर सकता है। PostgreSQL में, सक्रिय डेटाबेस कनेक्शन की इष्टतम संख्या आमतौर पर ((2 * core_count) + effect_spindle_count) के आसपास होती है। . इस संख्या से ऊपर, थ्रूपुट और विलंबता दोनों खराब हो जाते हैं।
कभी-कभी लोग कहेंगे "मैं 2000 उपयोगकर्ताओं का समर्थन करना चाहता हूं, तेजी से प्रतिक्रिया समय के साथ।" यह बहुत अधिक गारंटी है कि यदि आप 2000 वास्तविक डेटाबेस कनेक्शन के साथ ऐसा करने का प्रयास करते हैं, तो प्रदर्शन भयानक होगा। यदि आपके पास चार क्वाड-कोर प्रोसेसर वाली मशीन है और सक्रिय डेटा सेट पूरी तरह से कैश्ड है, तो आप लगभग 35 डेटाबेस कनेक्शन के माध्यम से अनुरोधों को फ़नल करके उन 2000 उपयोगकर्ताओं के लिए बेहतर प्रदर्शन देखेंगे।
यह समझने के लिए कि यह सच क्यों है, इस विचार प्रयोग से मदद मिलनी चाहिए। साझा करने के लिए केवल एक संसाधन के साथ एक काल्पनिक डेटाबेस सर्वर मशीन पर विचार करें - एक एकल कोर। यह कोर बिना किसी ओवरहेड के सभी समवर्ती अनुरोधों के बीच समान रूप से टाइम-स्लाइस करेगा। मान लीजिए कि 100 अनुरोध एक ही समय में आते हैं, जिनमें से प्रत्येक को एक सेकंड के CPU समय की आवश्यकता होती है। कोर उन सभी पर काम करता है, उनके बीच टाइम-स्लाइसिंग जब तक वे सभी 100 सेकंड बाद में समाप्त नहीं हो जाते। अब विचार करें कि क्या होता है यदि आप एक कनेक्शन पूल सामने रखते हैं जो 100 क्लाइंट कनेक्शन स्वीकार करेगा लेकिन डेटाबेस सर्वर से एक समय में केवल एक अनुरोध करेगा, कनेक्शन कतार में व्यस्त होने पर आने वाले किसी भी अनुरोध को डाल देगा। अब जब एक ही समय में 100 अनुरोध आते हैं, तो एक ग्राहक को 1 सेकंड में प्रतिक्रिया मिलती है; दूसरे को 2 सेकंड में प्रतिक्रिया मिलती है, और अंतिम ग्राहक को 100 सेकंड में प्रतिक्रिया मिलती है। प्रतिक्रिया प्राप्त करने के लिए किसी को अधिक प्रतीक्षा नहीं करनी पड़ी, थ्रूपुट समान है, लेकिन औसत विलंबता 100 सेकंड के बजाय 50.5 सेकंड है।
एक वास्तविक डेटाबेस सर्वर में अधिक संसाधन होते हैं जिनका उपयोग समानांतर में किया जा सकता है, लेकिन एक ही सिद्धांत है, एक बार जब वे संतृप्त हो जाते हैं, तो आप केवल समवर्ती डेटाबेस अनुरोधों को जोड़कर चीजों को नुकसान पहुंचाते हैं। यह वास्तव में उदाहरण से भी बदतर है, क्योंकि अधिक कार्यों के साथ आपके पास अधिक कार्य स्विच होते हैं, ताले और कैश के लिए विवाद बढ़ जाता है, एल 2 और एल 3 कैश लाइन विवाद, और कई अन्य मुद्दे जो थ्रूपुट और विलंबता दोनों में कटौती करते हैं। उसके ऊपर, जबकि एक उच्च work_mem सेटिंग कई तरह से क्वेरी में मदद कर सकती है, यह सेटिंग प्रत्येक कनेक्शन के लिए प्रति प्लान नोड की सीमा है , इसलिए बड़ी संख्या में कनेक्शन के साथ आपको कैश को फ्लश करने या यहां तक कि स्वैपिंग से बचने के लिए इसे बहुत छोटा छोड़ना होगा, जिससे धीमी योजनाएं या ऐसी चीजें होती हैं जैसे हैश टेबल डिस्क पर फैलती हैं।
कुछ डेटाबेस उत्पाद प्रभावी रूप से सर्वर में एक कनेक्शन पूल का निर्माण करते हैं, लेकिन PostgreSQL समुदाय ने यह स्थिति ले ली है कि चूंकि क्लाइंट सॉफ़्टवेयर के करीब सबसे अच्छा कनेक्शन पूलिंग किया जाता है, इसलिए वे इसे प्रबंधित करने के लिए इसे उपयोगकर्ताओं पर छोड़ देंगे। अधिकांश पूलर्स के पास डेटाबेस कनेक्शन को हार्ड नंबर तक सीमित करने का कोई तरीका होगा, जबकि उससे अधिक समवर्ती क्लाइंट अनुरोधों को आवश्यक रूप से कतारबद्ध करने की अनुमति होगी। आप यही चाहते हैं, और इसे लेन-देन . पर किया जाना चाहिए आधार, प्रति कथन या कनेक्शन के अनुसार नहीं।
