इस श्रृंखला में हमारे पिछले पोस्ट में, हमने PgBouncer और Pgpool-II, कनेक्शन पूल आर्किटेक्चर और एक का लाभ उठाने के पेशेवरों और विपक्षों का उपयोग करने के बारे में विस्तार से बात की थी। आपके PostgreSQL परिनियोजन के लिए। अपनी अंतिम पोस्ट में, हम उन्हें विस्तृत फीचर तुलना में आमने-सामने रखेंगे और आपके PostgreSQL होस्टिंग के लिए PgBouncer बनाम Pgpool-II प्रदर्शन के परिणामों की तुलना करेंगे!
सुविधाएं कैसे ढेर हो जाती हैं?
आइए, PgBouncer बनाम Pgpool-II सुविधाओं की तुलना करके शुरू करते हैं:
| <वें शैली ="चौड़ाई:38%; पृष्ठभूमि-रंग:# def5fe; पैडिंग:10px;"> | ||
|---|---|---|
| संसाधन की खपत | यह केवल एक प्रक्रिया का उपयोग करता है जो इसे बहुत हल्का बनाता है। बड़े डेटासेट के साथ काम करते समय भी PgBouncer एक छोटी मेमोरी फ़ुटप्रिंट की गारंटी देता है। विजेता! | अगर हमें N समानांतर कनेक्शन की आवश्यकता है, तो यह N चाइल्ड प्रोसेस को फोर्क करता है। डिफ़ॉल्ट रूप से, 32 चाइल्ड प्रोसेस हैं जो फोर्क की गई हैं। |
| कनेक्शन का पुन:उपयोग कब किया जाता है? | PgBouncer प्रति उपयोगकर्ता एक पूल+डेटाबेस संयोजन को परिभाषित करता है। यह सभी क्लाइंट के बीच साझा किया जाता है, इसलिए सभी क्लाइंट के लिए एक पूल्ड कनेक्शन उपलब्ध है। विजेता! | Pgpool-II प्रति चाइल्ड प्रोसेस एक प्रोसेस को परिभाषित करता है। हम यह नियंत्रित नहीं कर सकते कि क्लाइंट किस चाइल्ड प्रोसेस से जुड़ता है। क्लाइंट को पूल किए गए कनेक्शन से तभी लाभ होता है, जब वह किसी ऐसे बच्चे से जुड़ता है, जिसने पहले इस डेटाबेस+उपयोगकर्ता संयोजन के लिए कनेक्शन दिया है। |
| पूलिंग मोड | PgBouncer तीन अलग-अलग मोड का समर्थन करता है:सेशन (क्लाइंट डिस्कनेक्ट होने पर कनेक्शन पूल में वापस आ जाता है), ट्रांजेक्शन (क्लाइंट के आने या रोलबैक होने पर पूल में वापस आ जाता है) या स्टेटमेंट ( कनेक्शन प्रत्येक कथन के निष्पादन के बाद पूल में वापस आ गया)। विजेता! | Pgpool-II केवल सेशन पूलिंग मोड का समर्थन करता है - पूलिंग की प्रभावकारिता क्लाइंट के अच्छे व्यवहार पर निर्भर करती है। |
| उच्च उपलब्धता | समर्थित नहीं है। | Pgpool-II इन-बिल्ट वॉचर प्रक्रियाओं के माध्यम से PostgreSQL उच्च उपलब्धता समर्थित है। विजेता! |
| लोड बैलेंसिंग | समर्थित नहीं - PgBouncer उच्च उपलब्धता और लोड संतुलन के लिए HAProxy के उपयोग की अनुशंसा करता है। | स्वचालित लोड संतुलन का समर्थन करता है - यहां तक कि पढ़ने के अनुरोधों को स्टैंडबाय पर पुनर्निर्देशित करने के लिए पर्याप्त बुद्धिमान है, और मास्टर्स को लिखता है। विजेता! |
| मल्टी-क्लस्टर सपोर्ट | एक PgBouncer इंस्टेंस कई PostgreSQL क्लस्टर्स (एक-नोड या रेप्लिका-सेट) के सामने आ सकता है। यह कई PostgreSQL क्लस्टर का उपयोग करते समय मिडलवेयर की लागत को कम कर सकता है। विजेता! (नोट – यह लाभ केवल विशिष्ट परिदृश्यों के लिए है) | Pgpool-II में मल्टी-क्लस्टर सपोर्ट नहीं है। |
| कनेक्शन कंट्रोल | PgBouncer प्रति-पूल, प्रति-डेटाबेस, प्रति-उपयोगकर्ता या प्रति-क्लाइंट कनेक्शन सीमित करने की अनुमति देता है। विजेता! | Pgpool-II केवल कनेक्शन की कुल संख्या को सीमित करने की अनुमति देता है। |
| कनेक्शन कतार | PgBouncer एप्लिकेशन स्तर पर क्यूइंग का समर्थन करता है (यानी PgBouncer क्यू को मेंटेन करता है)। विजेता! | Pgpool-II कर्नेल स्तर पर क्यूइंग का समर्थन करता है - इससे CentOS 6 पर pg_bench फ़्रीज़ हो सकता है। |
| प्रमाणीकरण | पास-थ्रू प्रमाणीकरण PgBouncer द्वारा समर्थित है। विजेता! | Pgpool-II पास-थ्रू प्रमाणीकरण का समर्थन नहीं करता - उपयोगकर्ताओं और उनके md5 एन्क्रिप्टेड पासवर्ड को एक फ़ाइल में सूचीबद्ध किया जाना चाहिए और हर बार उपयोगकर्ता द्वारा अपडेट किए जाने पर मैन्युअल रूप से अपडेट किया जाना चाहिए। उनका पासवर्ड। पीजीपूल-द्वितीय पीएएम या एसएसएल-प्रमाणपत्रों के माध्यम से पासवर्ड रहित प्रमाणीकरण का समर्थन करता है। हालाँकि, इन्हें PostgreSQL सिस्टम के बाहर स्थापित किया जाना चाहिए, जबकि PgBouncer इसे PostgreSQL सर्वर पर लोड कर सकता है। |
| प्रशासन | PgBouncer एक वर्चुअल डेटाबेस प्रदान करता है जो विभिन्न उपयोगी आंकड़ों की रिपोर्ट करता है। | Pgpool-II GUI सहित एक विस्तृत व्यवस्थापन इंटरफ़ेस प्रदान करता है। विजेता! |
| होस्ट-आधारित प्रमाणीकरण | समर्थित। बंधे हुए! | समर्थित। बंधे हुए! |
| SSL सपोर्ट | पूर्ण समर्थन। बंधे हुए! | पूर्ण समर्थन। बंधे हुए! |
| तार्किक प्रतिकृति | PgBouncer द्वारा समर्थित नहीं है। बंधे हुए! | Pgpool-II के माध्यम से समर्थित, लेकिन यह सभी नोड्स को लिखित क्वेरी भेजकर किया जाता है, और आमतौर पर इसकी अनुशंसा नहीं की जाती है। बंधे हुए! |
| लाइसेंस | ISC - बहुत अनुमेय, मूल रूप से सभी उपयोग की अनुमति देता है। बंधे हुए! | कस्टम लाइसेंस - समान रूप से अनुमेय। बंधे हुए! |
नीचे की रेखा - अगर आपको लोड-बैलेंसिंग और उच्च उपलब्धता की आवश्यकता है तो Pgpool-II एक बेहतरीन टूल है। कनेक्शन पूलिंग लगभग एक बोनस है जो आपको मिलता है। PgBouncer केवल एक ही काम करता है, लेकिन वह वास्तव में अच्छा करता है। यदि उद्देश्य कनेक्शनों की संख्या को सीमित करना और संसाधन की खपत को कम करना है, तो PgBouncer हाथ से जीत जाता है।
एक श्रृंखला में PgBouncer और Pgpool-II दोनों का उपयोग करना भी पूरी तरह से ठीक है - आपके पास कनेक्शन पूलिंग प्रदान करने के लिए एक PgBouncer हो सकता है, जो एक से बात करता है Pgpool-II उदाहरण जो उच्च उपलब्धता और लोड संतुलन प्रदान करता है। यह आपको दोनों दुनियाओं में सर्वश्रेष्ठ देता है!
प्रदर्शन परीक्षण
जबकि PgBouncer सैद्धांतिक रूप से बेहतर विकल्प प्रतीत हो सकता है, सिद्धांत अक्सर भ्रामक हो सकता है। इसलिए, हमने मानक पीजीबेंच टूल का उपयोग करते हुए दो कनेक्शन पूलर्स को आमने-सामने रखा, यह देखने के लिए कि कौन सा बेंचमार्क टेस्ट के माध्यम से प्रति सेकंड थ्रूपुट बेहतर लेनदेन प्रदान करता है। अच्छे उपाय के लिए, हमने बिना कनेक्शन पूलर के भी वही परीक्षण चलाए।
जांच की शर्तें
सभी PostgreSQL बेंचमार्क परीक्षण निम्नलिखित परिस्थितियों में चलाए गए:
- 100 के स्केल फ़ैक्टर का उपयोग करके pgbench को इनिशियलाइज़ किया गया।
- हस्तक्षेप को रोकने के लिए PostgreSQL इंस्टेंस पर ऑटो-वैक्यूमिंग अक्षम करें।
- उस समय कोई अन्य कार्यभार काम नहीं कर रहा था।
- परीक्षण चलाने के लिए डिफ़ॉल्ट pgbench स्क्रिप्ट का उपयोग किया।
- PgBouncer और Pgpool-II दोनों के लिए डिफ़ॉल्ट सेटिंग्स का उपयोग किया, max_children को छोड़कर *. सभी PostgreSQL सीमाएं भी उनके डिफ़ॉल्ट पर सेट की गई थीं।
- सभी परीक्षण 5 मिनट की अवधि के लिए सिंगल-सीपीयू, 2-कोर मशीन पर सिंगल थ्रेड के रूप में चले।
- -C विकल्प का उपयोग करके प्रत्येक लेनदेन के लिए एक नया कनेक्शन बनाने के लिए pgbench को बाध्य किया। यह आधुनिक वेब एप्लिकेशन वर्कलोड का अनुकरण करता है और पूलर का उपयोग करने का पूरा कारण है!
हमने प्रत्येक पुनरावृत्ति को 5 मिनट तक चलाया ताकि यह सुनिश्चित हो सके कि कोई शोर औसत हो। यहां बताया गया है कि मिडलवेयर कैसे स्थापित किया गया था:
- PgBouncer के लिए, हमने इसे उसी बॉक्स पर स्थापित किया है जिस पर PostgreSQL सर्वर (सर्वर) हैं। यह वह कॉन्फ़िगरेशन है जिसका उपयोग हम अपने प्रबंधित PostgreSQL क्लस्टर में करते हैं। चूंकि PgBouncer एक बहुत ही हल्की-फुल्की प्रक्रिया है, इसलिए इसे बॉक्स पर स्थापित करने से समग्र प्रदर्शन पर कोई प्रभाव नहीं पड़ता है।
- Pgpool-II के लिए, हमने दोनों का परीक्षण किया जब Pgpool-II इंस्टेंस को उसी मशीन पर PostgreSQL (बॉक्स कॉलम पर) के रूप में स्थापित किया गया था, और जब यह एक अलग मशीन पर स्थापित किया गया था। (ऑफ बॉक्स कॉलम)। जैसा कि अपेक्षित था, प्रदर्शन बहुत बेहतर होता है जब Pgpool-II बॉक्स से बाहर होता है क्योंकि इसे संसाधनों के लिए PostgreSQL सर्वर से प्रतिस्पर्धा करने की आवश्यकता नहीं होती है।
थ्रूपुट बेंचमार्क
यहां विभिन्न प्रकार के ग्राहकों के लिए प्रत्येक परिदृश्य के लिए लेनदेन प्रति सेकंड (TPS) परिणाम दिए गए हैं:
| क्लाइंट की संख्या | बिना पूलिंग के | PgBouncer | पगपूल-द्वितीय (बॉक्स पर) | पगपूल-द्वितीय (ऑफ बॉक्स) |
|---|---|---|---|---|
| 10 | 16.96 | 26.86 | 15.52 | 18.22 |
| 20 | 16.97 | 27.19 | 15.67 | 18.28 |
| 40 | 16.73 | 26.77 | 15.33 | 18.3 |
| 80 | 16.75 | 26.64 | 15.53 | 18.13 |
| 100 | 16.51 | 26.73 | 15.66 | 18.45 |
| 200 | कनेक्शन निरस्त किया गया। | 26.93 | जब मैक्स-चिल्ड्रन> 200 हो तो कनेक्शन निरस्त हो जाते हैं, अगर <=100 हो तो pgbench मैक्स-चिल्ड्रन वैल्यू पर हैंग हो जाता है। | जब मैक्स-चिल्ड्रन> 200 हो तो कनेक्शन निरस्त हो जाते हैं, अगर <=100 हो तो pgbench मैक्स-चिल्ड्रन वैल्यू पर हैंग हो जाता है। |
Pgpool-II हैंग हो जाता है जब pg_bench को max_children से अधिक क्लाइंट के साथ चलाया जाता है। इसलिए, हमने प्रत्येक परीक्षण चलाने के लिए ग्राहकों की संख्या से मेल खाने के लिए max_children में वृद्धि की।
यदि हम कनेक्शन पूलर का उपयोग करते समय टीपीएस में प्रतिशत वृद्धि की गणना करते हैं, तो हमें यह मिलता है:
| क्लाइंट की संख्या | <वें शैली="चौड़ाई:28%; पृष्ठभूमि-रंग:#def5fe; पैडिंग:10px;">PgBouncerPgpool-II (बॉक्स पर) | Pgpool-II (ऑफ बॉक्स) | |
|---|---|---|---|
| 10 | 58.37% | -8.49% | 7.43% |
| 20 | 60.22% | -7.66% | 7.72% |
| 40 | 60.01% | -8.37% | 9.38% |
| 80 | 59.04% | -7.28% | 8.24% |
| 100 | 61.90% | -5.15% | 11.75% |
* इम्प्रूवमेंट एल्गोरिथम =(पूलर के साथ - बिना)/बिना
अंतिम शब्द
जैसा कि आप प्रदर्शन परीक्षण के परिणामों से देख सकते हैं, एक अच्छी तरह से कॉन्फ़िगर किया गया कनेक्शन और अच्छी तरह से अनुकूल कनेक्शन पूलर ग्राहकों की एक काफी कम संख्या के साथ भी लेनदेन थ्रूपुट को काफी बढ़ा सकता है। कनेक्शन पूलर उनके कतार समर्थन के लिए विशेष रूप से उपयोगी होते हैं - जब ग्राहकों की संख्या PostgreSQL सर्वर द्वारा समर्थित अधिकतम-क्लाइंट से अधिक हो जाती है, तब भी PgBouncer लेनदेन दर को बनाए रखने में सक्षम होता है, जबकि PostgreSQL से सीधे कनेक्शन निरस्त कर दिए जाते हैं।
हालांकि, एक बुरी तरह से कॉन्फ़िगर किया गया कनेक्शन पूलर वास्तव में कम कर सकता है जैसा प्रदर्शन हमने यहां Pgpool-II सेटअप के साथ देखा। समस्या का एक हिस्सा है, Pgpool-II doubles . का उपयोग करना एक ही सर्वर पर चलने वाली प्रक्रियाओं की संख्या - हमें चाहिए अच्छा प्रदर्शन प्राप्त करने के लिए एक अलग सर्वर पर Pgpool-II चलाएँ। लेकिन फिर भी, PgBouncer इन अपेक्षाकृत कम संख्या में ग्राहकों के लिए बेहतर प्रदर्शन प्रदान करने का प्रबंधन करता है।
इसके अलावा, ध्यान दें कि यहां परीक्षण वास्तव में पूरी तरह से Pgpool-II के लिए तैयार किया गया था - जब से N> 32, क्लाइंट की संख्या और बच्चों की प्रक्रियाओं की संख्या समान थी, और इसलिए, कैश्ड प्रक्रिया को खोजने के लिए प्रत्येक पुन:कनेक्शन की गारंटी दी गई थी। तब भी, PgBouncer सबसे तेज़ विकल्प था।
इसलिए, हमारा परीक्षण इंगित करता है कि PgBouncer कनेक्शन पूलिंग के लिए कहीं बेहतर विकल्प है। लेकिन, यह याद रखना महत्वपूर्ण है कि अधिकांश यथार्थवादी वर्कलोड के लिए एक कनेक्शन पूलर बिल्कुल अनिवार्य है, चाहे आप क्लाइंट-साइड पूल या मिडलवेयर जैसे PgBouncer का उपयोग करके अधिक लाभ प्राप्त करें, यह आपके आवेदन पर निर्भर करता है। डेटा एक्सेस के पैटर्न एक भूमिका निभाएंगे, जैसा कि आपके आर्किटेक्चर के आधार पर शामिल विलंबता होगा। हम अनुशंसा करते हैं कि आप दोनों के खिलाफ अपने कार्यभार का परीक्षण करें, और फिर कार्रवाई का सर्वोत्तम तरीका तय करें - प्रयोग का कोई बेहतर विकल्प नहीं है!
