मैं किसी प्रोजेक्ट में डेटा एक्सेस के लिए PHP की पीडीओ परत का उपयोग कर रहा हूं, और मैं इसे पढ़ रहा हूं और देख रहा हूं कि इसमें लगातार डीबी कनेक्शन के लिए अच्छा सहज समर्थन है। मैं सोच रहा हूं कि/अगर मुझे उनका उपयोग करना चाहिए। क्या मैं एक सीआरयूडी-भारी ऐप में प्रदर्शन लाभ देख सकता हूं? क्या सुरक्षा के संबंध में शायद विचार करने के लिए डाउनसाइड्स हैं?लगातार डीबी कनेक्शन - हाँ या नहीं?
यदि यह आपके लिए महत्वपूर्ण है, तो मैं MySQL 5.x का उपयोग कर रहा हूं।
आप एक किसी न किसी "नियम-सेट" के रूप में उपयोग कर सकते हैं:
हाँ, लगातार कनेक्शन का उपयोग, अगर:
नहीं, लगातार कनेक्शन का उपयोग नहीं करते हैं, यदि:
लगातार कनेक्शन का उपयोग करना काफी तेज़ है, खासकर यदि आप किसी नेटवर्क पर डेटाबेस तक पहुंच रहे हैं। यदि डेटाबेस एक ही मशीन पर चल रहा है तो यह इतना अंतर नहीं करता है, लेकिन यह अभी भी थोड़ा तेज़ है। हालांकि - जैसा कि नाम कहता है - कनेक्शन लगातार है, यानी यह खुला रहता है, भले ही इसका उपयोग न किया जाए।
समस्या यह है कि "डिफ़ॉल्ट कॉन्फ़िगरेशन" में, MySQL केवल 1000 समांतर "खुले चैनल" की अनुमति देता है। उसके बाद, नए कनेक्शन अस्वीकार कर दिए जाते हैं (आप इस सेटिंग को ट्विक कर सकते हैं)। तो यदि आपके पास - प्रत्येक 100 ग्राहक के साथ 20 वेबसर्वर हैं, और उनमें से प्रत्येक में प्रति घंटे केवल एक पृष्ठ पहुंच है, तो सरल गणित आपको दिखाएगा कि आपको डेटाबेस के लिए 2000 समानांतर कनेक्शन की आवश्यकता होगी। वह काम नहीं करेगा।
एर्गो: केवल अनुरोधों के लिए इसे बहुत से अनुरोधों के साथ उपयोग करें।
डेटाबेस में कनेक्शन बनाना एक काफी महंगा ऑपरेशन है। लगातार कनेक्शन एक अच्छा विचार है। एएसपी.Net और जावा दुनिया में, हमारे पास "कनेक्शन पूलिंग" है, जो मोटे तौर पर एक ही चीज़ है, और यह भी एक अच्छा विचार है।
आईएमओ, इस प्रश्न का वास्तविक उत्तर जो भी आपके लिए सबसे अच्छा काम करता है। मैं आपको लगातार और गैर-लगातार कनेक्शन दोनों का उपयोग करके अपने ऐप को बेंचमार्क करने की सलाह दूंगा।
मैगी नेल्सन @Objectively Oriented अगस्त में इस बारे में पोस्ट किया गया और Robert Swarthout कुछ कठिन संख्याओं के साथ एक साथ पोस्ट किया गया। दोनों बहुत अच्छे पढ़ रहे हैं।
"ऑब्जेक्टिव ओरिएंटेड" लिंक डाउन है। – Pacerier
मुझे इस उत्तर को नापसंद है क्योंकि बेंचमार्किंग अक्सर एक बहुत ही गलत तरीके से किया जाता है। यह आपके कंप्यूटर के साथ "वास्तविक दुनिया पहुंच पैटर्न के अलावा" (जो परीक्षणों की विशिष्ट है) में इसे एक्सेस करने के साथ बहुत अच्छा लग सकता है। समय बहुत अधिक महत्वपूर्ण है क्योंकि वास्तविक जीवन में अक्सर होने वाली कई अन्य "प्रतिलिपि बनाने की कठिनाई" स्थितियां होती हैं। मैं इसे सोचने और इसे टालने का सुझाव दूंगा जबतक कि आपको निश्चित रूप से इसकी आवश्यकता नहीं है। प्री-ऑप्टिमाइज़ेशन पहला पाप है। –
मेरी विनम्र राय में:
वेब विकास के लिए PHP का उपयोग करते हैं, तो आपके कनेक्शन की सबसे जाएगा पेज के जीवन के लिए केवल "लाइव" को क्रियान्वित। एक लगातार कनेक्शन आपको बहुत अधिक खर्च करने जा रहा है क्योंकि आपको इसे सत्र या कुछ ऐसी चीज में रखना होगा।
99% उस समय एक गैर-निरंतर कनेक्शन जो पेज निष्पादन के अंत में मर जाता है, ठीक काम करेगा।
अन्य 1% समय, आपको शायद ऐप के लिए PHP का उपयोग नहीं करना चाहिए, और आपके लिए कोई सही समाधान नहीं है।
मैं वही प्रश्न पूछने जा रहा था लेकिन एक ही प्रश्न पूछने के बजाय मैं कुछ जानकारी जो मुझे मिली है उसे जोड़ दूंगा।
यह भी ध्यान देने योग्य बात है कि नए mysqli विस्तार भी लगातार डेटाबेस कनेक्शन का उपयोग करने के विकल्प शामिल नहीं है लायक है।
मैं अभी भी इस समय लगातार कनेक्शन का उपयोग कर रहा हूं लेकिन निकट भविष्य में गैर-निरंतर स्विच करने की योजना बना रहा हूं।
यह उत्तर के बजाय एक टिप्पणी होना चाहिए। – Pacerier
सामान्यतः, आपको कभी-कभी गैर-लगातार कनेक्शन का उपयोग करने की आवश्यकता होगी, और डीबी कनेक्शन डिज़ाइन पर लागू होने के लिए एक ही पैटर्न होना अच्छा है (जब तक आपके संदर्भ में लगातार कनेक्शन का उपयोग करने के लिए अपेक्षाकृत कम उछाल हो।)
संक्षेप में, मेरा अनुभव कहता है कि जहां तक संभव हो सके लगातार कनेक्शन से बचा जाना चाहिए।
ध्यान दें कि mysql_close mysql_pconnect का उपयोग करके बनाए गए कनेक्शन के लिए एक नो-ऑपरेशन (नो-ऑप) है। इसका मतलब क्लाइंट द्वारा लगातार कनेक्शन बंद नहीं किया जा सकता है। इस कनेक्शन को mysqldb सर्वर द्वारा बंद कर दिया जाएगा जब से अधिक अवधि के कनेक्शन पर कोई गतिविधि नहीं होती है wait_timeout। यदि wait_timeout बड़ा मान है (30 मिनट कहें) तो mysql डीबी सर्वर आसानी से max_connections सीमा तक पहुंच सकता है। ऐसे मामले में, MySQL डीबी भविष्य के कनेक्शन अनुरोध को स्वीकार नहीं करेगा। यह तब होता है जब आपका पेजर बीपिंग शुरू करता है।
आदेश max_connections तक पहुँचने सीमा से बचने के लिए, लगातार कनेक्शन का उपयोग निम्न चर से सावधान संतुलन की आवश्यकता है ...
1. Number of apache processes on one host
2. Total number of hosts running apache
3. wait_timout variable in mysql db server
4. max_connections variable in mysql db server
5. Number of requests served by one apache process before it is re-spawned
तो, pl पर्याप्त विचार-विमर्श के बाद लगातार कनेक्शन का उपयोग करें। आप निरंतर कनेक्शन से प्राप्त होने वाले छोटे लाभ के लिए जटिल रनटाइम समस्याओं को आमंत्रित नहीं करना चाहेंगे।
"mysql_close" के लिए जरूरी उद्धरण mysql_pconnect का उपयोग कर बनाए गए कनेक्शन के लिए एक नो-ऑपरेशन (नो-ऑप) है "। Mysqli के लिए, यह निश्चित रूप से नो-ऑप नहीं है: http://php.net/manual/en/mysqli.persistconns.php – Pacerier
इसके अलावा, अगर आप प्रीफेर्क मोड में अपाचे का उपयोग कर रहे हैं तो लगातार कनेक्शन का उपयोग न करें।यह प्रत्येक बच्चे की प्रक्रिया के लिए एक कनेक्शन का उपयोग करता है, जो काफी तेजी से रैंप कर सकता है। – Powerlord
@BlaM, मुझे आपका अंतिम पैराग्राफ नहीं मिल रहा है। क्या लगातार कनेक्शन आपको उनका पुन: उपयोग करने की अनुमति नहीं देता है (यह पूरा बिंदु है?) तो आपको 2000 कनेक्शन की आवश्यकता नहीं है क्योंकि उनका पुन: उपयोग किया जाएगा? या आपका मतलब है ** प्रत्येक ग्राहक ** का एक अद्वितीय उपयोगकर्ता नाम है? फिर भी, पुराने कनेक्शन लगातार नए कनेक्शन के लिए रास्ता बनाने के लिए किए जाने पर बंद नहीं होंगे? – Pacerier
@Pacerier: मेरा मतलब क्लाइंट प्रत्येक के अपने उपयोगकर्ता नाम के साथ था। उस मामले में पुराने कनेक्शन ** ** ** नए कनेक्शन संभव बनाने के करीब नहीं होंगे, क्योंकि स्वीकृत कनेक्शन की ** सीमा ** को MySQL द्वारा प्रबंधित किया जाता है और कनेक्शन की दृढ़ता PHP पक्ष से प्रबंधित की जाती है - इसलिए PHP के अंत से डेटाबेस बस कनेक्ट करने की अनुमति नहीं देता है। यह नहीं जानता कि सीमा तक पहुंच गई थी और पुराने कनेक्शन बंद होने से मदद मिलेगी। – BlaM