क्या डेटाबेस प्रक्रिया को कई बार एप्लिकेशन से कॉल करने पर प्रदर्शन प्रभावित होगा?

आपकी सलाह सही है, सभी डेटाबेस कार्यों को एक साथ करना बेहतर होगा। आपके परिदृश्य में 2 प्रमुख प्रदर्शन प्रभाव हैं

1. आपके थ्रेड को कई बार चलाने के लिए SQL इंजन और PL/SQL इंजन के बीच pro*c का संदर्भ स्विचिंग। क्लाइंट एप्लिकेशन से कई PL/SQL कॉल में आमतौर पर सबसे बड़ी समस्या होती है।
2. आपके प्रो*सी ऐप और डेटाबेस इंजन के बीच संचार में नेटवर्क स्टैक ओवरहेड (टीएनएस) - खासकर यदि आपका ऐप एक अलग भौतिक होस्ट पर है।

ऐसा कहने के बाद, आप एप्लिकेशन के अंत में एक कनेक्शन पूल बना रहे हैं, टीएनएस श्रोता के पास प्रत्येक नेटवर्क कनेक्शन की प्रतीक्षा में वसीयत सर्वर छाया प्रक्रियाओं का एक पूल होना चाहिए (यह श्रोता.ओरा पर सेटअप है)।

OCI लॉगिन/लॉगऑफ़ जब शैडो प्रक्रिया पहले से ही कनेक्ट होने की प्रतीक्षा कर रही है, बहुत तेज़ है और विलंबता में एक बड़ा कारक नहीं है - मुझे इस बारे में तब तक चिंता नहीं है जब तक कि सर्वर पर एक नई छाया प्रक्रिया शुरू नहीं हो जाती है - तब यह एक हो सकता है बहुत महंगी कॉल। चूंकि आप क्लाइंट साइड पर कनेक्शन पूलिंग का उपयोग कर रहे हैं, यह आमतौर पर कोई समस्या नहीं है बल्कि आपकी कॉल में थ्रेडिंग के कारण विचार करने के लिए कुछ है। एक बार जब आप सर्वर शैडो प्रक्रियाओं के पूल को समाप्त कर देते हैं, तो आप देखेंगे कि यदि TNS श्रोता को अधिक सर्वर शैडो प्रक्रिया शुरू करनी है तो आप एक बड़ी गिरावट देखेंगे।

नए प्रश्नों के उत्तर में संपादित करें:

1. यह बहुत संबंधित है। जैसा कि पहले बताया गया है, आपको अपने सी ++ ऐप के भीतर plsql और sql कॉल की मात्रा को कम करना चाहिए। आपके सी ++ ऐप कॉल के भीतर प्रत्येक पीएलएसक्यूएल कॉल एसक्यूएल इंजन को आमंत्रित करता है जो प्रक्रिया कॉल के लिए पीएलएसक्यूएल इंजन को आमंत्रित करता है। इसलिए यदि आप अपनी प्रक्रिया को 2 में विभाजित करते हैं - आप SQL को PLSQL संदर्भ स्विच में दोगुना कर रहे हैं जो कि टॉम काइट लेख और मेरे अपने व्यक्तिगत अनुभव द्वारा उल्लिखित अधिक महंगा स्विच है।

2. 1 में उत्तर दिया गया है। लेकिन जैसा कि मैंने पहले कहा था कि संचार ओवरहेड दूसरा है जब तक कि आपके होस्ट विभिन्न भौतिक नेटवर्क और आपके द्वारा स्थानांतरित किए जा रहे डेटा के प्रकार पर न हों। उदाहरण के लिए बड़े सी ++ ऑब्जेक्ट पैरामीटर और कई कॉल के साथ बड़े ओरेकल परिणाम सेट स्पष्ट रूप से राउंड ट्रिप के साथ संचार विलंबता को प्रभावित करेंगे। याद रखें कि अधिक PLSQL कॉल के साथ आप प्रत्येक कनेक्शन और परिणाम सेट के लिए सेटअप के लिए अधिक SQLNET ट्रैफ़िक भी जोड़ रहे हैं।

3. कोई 3. प्रश्न नहीं है

4. पीएलएसक्यूएल इंजन के भीतर पीएलएसक्यूएल से एसक्यूएल नगण्य है इसलिए इसे लटकाओ मत। अधिकतम प्रदर्शन थ्रूपुट के लिए अपने सभी SQL कॉल को 1 PLSQL कॉल के भीतर रखें। प्रदर्शन के महंगे होने पर अधिक वाक्पटु होने के लिए कॉल को विभाजित न करें।