बेहतर एक संग्रहीत प्रक्रिया का उपयोग करें या इसे एक कनेक्शन स्ट्रिंग और जो कुछ अच्छी चीजें साथ पुराने तरीके से करने के लिए है? हमारी प्रणाली हाल ही में धीमी गति से चल रही है और हमारा प्रबंधक चाहता है कि हम यह देखने की कोशिश करें कि क्या हम चीजों को थोड़ा तेज कर सकते हैं और हम संग्रहित प्रक्रियाओं में पुराने डेटाबेस कॉल को बदलने के बारे में सोच रहे थे। यह इसके लायक है?संग्रहित प्रक्रियाओं का उपयोग कर एक बड़ा प्रदर्शन लाभ है?
करने के लिए पहली बात यह है डेटाबेस के लिए सभी आवश्यक अनुक्रमित की स्थापना की है की जाँच है। विश्लेषण करें कि आपका कोड धीमा है, और संबंधित एसक्यूएल कथन और उससे संबंधित इंडेक्स की जांच करें। देखें कि क्या आप अधिक कुशल होने के लिए SQL कथन को फिर से लिख सकते हैं। जांचें कि आप एक बार इसके बाहर एक लूप में प्रत्येक पुनरावृत्ति के लिए एक SQL (तैयार) कथन का पुन: संकलन नहीं कर रहे हैं।
एक संग्रहीत प्रक्रिया में एक SQL कथन को स्थानांतरित करना मदद नहीं करेगा यदि यह कार्यान्वयन में पूरी तरह से अक्षम है। हालांकि डेटाबेस को पता चलेगा कि एसक्यूएल को सबसे अच्छा कैसे अनुकूलित किया जाए और इसे बार-बार करने की आवश्यकता नहीं होगी। यह जटिल एसक्यूएल कथन को एक साधारण प्रक्रिया कॉल में बदलकर क्लाइंट साइड कोड क्लीनर भी बना सकता है।
जब तक आपकी कॉल सुसंगत रहेगी तो डेटाबेस निष्पादन योजना (एमएस एसक्यूएल वैसे भी) स्टोर करेगा। संग्रहीत प्रक्रियाओं का उपयोग करने का सबसे मजबूत शेष कारण आसान और निश्चित सुरक्षा प्रबंधन के लिए है।
मैं पहली बार सूचकांक जहां आवश्यक जोड़ने के लिए विचार करना होता अगर मैं तुम्हें थे। इसके अलावा जांच करने के लिए क्या समय ले रहा है एक रूपरेखा उपकरण चलाने के लिए और अगर है कि एसक्यूएल बदल गया है, उदाहरण के लिए की जरूरत है अधिक जोड़ना जहां परिणाम सेट क्लॉज या प्रतिबंधित है।
आपको कैशिंग पर विचार करना चाहिए जहां आप कर सकते हैं।
महत्वपूर्ण कीवर्ड को बोल्ड करने के लिए वोट दिया गया। अच्छा स्पर्श। :) –
आप पहले से कहते हैं कि कभी नहीं कर सकते हैं। आपको यह करना होगा और अंतर को मापना चाहिए क्योंकि 10 में से 9 मामलों में, बाधा नहीं है जहां आप सोचते हैं।
यदि आप संग्रहीत प्रक्रिया का उपयोग करते हैं, तो आपको डेटा संचारित करने की आवश्यकता नहीं है। डीबी आमतौर पर लूप, उच्च गणित, आदि के साथ [EDIT] जटिल [/ EDIT] संग्रहित प्रक्रियाओं [संपादित करें] निष्पादित करने में धीमी होती हैं [/ EDIT]। तो यह वास्तव में इस बात पर निर्भर करता है कि आपको कितना काम करना होगा, आपका नेटवर्क कितना धीमा है, डीबी इस विशेष कोड को कितनी तेज़ी से निष्पादित करता है, आदि
मैं Stored Procedures are EVIL पर एक त्वरित नज़र डालेगा।
मेरी इच्छा है कि मैं इस लिंक में 10 अंक जोड़ सकता हूं। डेटाबेस परत में तर्क संग्रहीत करने पर बिल्कुल मेरे विचार बताता है। –
मेरी इच्छा है कि आप भी कर सकें! =) – mattruma
हालांकि, मुझे लेखक के बिंदुओं में से किसी एक को अपवाद लेना होगा। यह अंतिम निष्कर्ष पर असर नहीं डालता है, लेकिन उनका बयान है कि "एसक्यूएल में आप कुछ भी नहीं कर सकते हैं जो आप ऐप कोड में भी नहीं कर सकते हैं" सेट-आधारित तर्क और इसकी क्षमताओं को समझने की एक आम कमी दिखाता है। – GalacticCowboy
संग्रहित प्रक्रियाओं बातें तेजी से नहीं होगा।
हालांकि, अपने तर्क उलटफेर एक बहुत बड़ा प्रभाव पड़ेगा। संग्रहीत प्रक्रियाओं के बारे में सोचते समय आपके द्वारा डिजाइन किए गए साफ-सुथरे, केंद्रित लेन-देन बेहद फायदेमंद होते हैं।
इसके अलावा, संग्रहीत प्रक्रियाएं बाध्य चर का उपयोग करती हैं, जहां अन्य प्रोग्रामिंग भाषाएं कभी-कभी एसक्यूएल स्टेटमेंट्स ऑन द फ्लाई बनाने पर भरोसा करती हैं। एसक्यूएल स्टेटमेंट्स और बाइंड वैरिएबल का एक छोटा, निश्चित सेट तेज़ है। गतिशील एसक्यूएल स्टेटमेंट धीमे हैं।
एक एप्लिकेशन जो "हाल ही में धीमी गति से चल रहा है" को कोडिंग परिवर्तनों की आवश्यकता नहीं है।
माप। का आकलन करें। का आकलन करें। जब प्रदर्शन ट्यूनिंग की बात आती है तो "धीमी" का मतलब बहुत अधिक नहीं होता है। धीमा क्या है? कौन सा सटीक लेनदेन धीमा है? कौन सी टेबल धीमी है? ध्यान दें।
सभी परिवर्तनों को नियंत्रित करें। सब। किया बदल गया? ओएस पैच? आरडीबीएमएस बदल गया? आवेदन परिवर्तन? चीजों को धीमा करने के लिए कुछ बदल गया।
पैमाने पर बाधाओं की जांच करें। क्या एक टेबल धीमा हो रहा है क्योंकि 80% डेटा इतिहास है जिसका उपयोग आप साल में एक बार रिपोर्टिंग के लिए करते हैं?
संग्रहित प्रक्रियाओं प्रदर्शन समस्याओं का हल जब तक आप पूरी तरह से कोड की एक विशिष्ट ब्लॉक जो provably तेजी से एक संग्रहीत प्रक्रिया के रूप में है को इंगित कर सकते हैं कभी नहीं कर रहे हैं।
मुख्य कारण है कि हम धीमी गति से चल रहे हैं क्योंकि हम अपने व्यस्त मौसम में हैं, लेकिन यह पहले से कहीं धीमा चल रहा है (यहां तक कि पिछले व्यस्त मौसमों में भी)। इसलिए, हम इसे थोड़ा तेज करने के लिए अपनी पूरी कोशिश करने की कोशिश कर रहे हैं। धन्यवाद –
"पहले से धीमा" शुरू हो गया है, लेकिन यह काफी व्यापक है। अगला कदम एक विशिष्ट तालिका, लेनदेन, दिनचर्या, प्रक्रिया, नौकरी या कार्य पर ध्यान केंद्रित करना है। फोकस के बिना, आप यह साबित नहीं कर सकते कि एसपी में आपका परिवर्तन सकारात्मक प्रभाव डालता है। –
हमें लगता है कि यह हमारी नौकरी की मेज और इसकी संबंधित सारणी है क्योंकि वह वही है जिसे साल के सबसे अधिक समय कहा जाता है, यही वह है जिसे हम ध्यान केंद्रित करने जा रहे हैं। –
हां, संग्रहीत प्रोसेस अच्छा प्रदर्शन करने की दिशा में एक कदम आगे है। मुख्य कारण यह है कि संग्रहीत प्रक्रियाओं को पूर्व संकलित किया जा सकता है और उनकी निष्पादन योजना कैश्ड की जा सकती है।
हालांकि आपको पहले विश्लेषण करना होगा कि आपकी प्रदर्शन बाधा वास्तव में कहां है - ताकि आप इस अभ्यास को संरचित तरीके से देख सकें।
यह प्रतिक्रियाओं में से एक में सुझाव दिया गया है के रूप में, एक प्रोफाइलर उपकरण जहां समस्या है का उपयोग करते हुए विश्लेषण की कोशिश - जैसे आप अनुक्रमणिका बनाने के लिए की जरूरत है ...
चीयर्स
अधिकांश आधुनिक आरडीबीएमएस किसी भी तरह से तैयार बयान के लिए पूर्व-संकलन और कैश निष्पादन योजनाओं को कैश करेंगे। –
आपके सेवक को तो आपके व्यस्त मौसम में उल्लेखनीय रूप से धीमा यह डेटाबेस में अक्षम किसी भी चीज़ के बजाय संतृप्ति के कारण हो सकता है। बेसिक queuing theory हमें बताता है कि एक सर्वर अतिसंवेदनशील रूप से धीमा हो जाता है क्योंकि यह संतृप्ति तक पहुंचता है।
मूल संबंध 1/(1-X) है जहां एक्स लोड का अनुपात है। यह सेवा देने से पहले प्रतीक्षा करने के लिए औसत कतार लंबाई या समय का वर्णन करता है। इसलिए लोड होने वाले सर्वर को संतृप्त होने पर बहुत धीमा हो जाएगा।
25% लोड होने वाला एक सर्वर कुछ निरंतर के लिए 1.333K का औसत सेवा समय होगा (संक्षेप में, के लिए मशीन एक लेनदेन करने का समय है)। 50% लोड होने वाला सर्वर 2K का औसत सेवा समय होगा और 90% लोड होने वाला सर्वर 10K का औसत सेवा समय होगा। यह देखते हुए कि मंदी प्रकृति में हाइपरबॉलिक है, यह अक्सर प्रतिक्रिया समय में एक महत्वपूर्ण गिरावट पैदा करने के लिए समग्र भार में एक बड़ा बदलाव नहीं लेता है।
जाहिर है यह कुछ हद तक साधारण है के रूप में सर्वर से अधिक अनुरोध प्रसंस्करण हो जाएगा समवर्ती (इस स्थिति के लिए और अधिक व्यापक कतार मॉडल हैं), लेकिन व्यापक सिद्धांत अभी भी लागू होता है।
तो, यदि आपका सर्वर क्षणिक भार का अनुभव कर रहा है जो इसे संतृप्त कर रहा है, तो आपको ध्यान देने योग्य धीमी गति के पैच का अनुभव होगा। ध्यान दें कि इन धीमी गति को पूरी प्रक्रिया को धीमा करने के लिए सिस्टम के एक बाधित क्षेत्र में होना चाहिए। यदि आप केवल व्यस्त मौसम में इसका अनुभव कर रहे हैं तो संभावना है कि आपके सर्वर ने विशेष रूप से धीमी या अक्षम होने की बजाय संसाधन पर बाधा डाली है।
ध्यान दें कि यह संभावना कोड में अक्षमता की संभावना के प्रति विरोधी नहीं है। आप पाते हैं कि बाधा को कम करने का तरीका आपके कुछ प्रश्नों को ट्यून करना है।
यह बताने के लिए कि सिस्टम को बाधित किया गया है, प्रोफाइलिंग जानकारी एकत्र करना शुरू करें। यदि आप बड़ी संख्या में संसाधनों के साथ संसाधन पा सकते हैं, तो यह आपको एक अच्छा प्रारंभिक बिंदु देना चाहिए।
अंतिम संभावना यह है कि आपको अपने सर्वर को अपग्रेड करना होगा। यदि कोड में कोई बड़ी अक्षमता नहीं है (यह तब भी हो सकता है जब प्रोफाइलिंग किसी भी समान रूप से बड़ी बाधाओं का संकेत न दे) तो आपको बस बड़े हार्डवेयर की आवश्यकता हो सकती है।मुझे नहीं पता कि आपके वॉल्यूम क्या हैं, लेकिन संभावना है कि आप अपने सर्वर को बढ़ा चुके हैं।
संग्रहित प्रक्रियाएं वास्तव में मदद कर सकती हैं अगर वे बड़ी मात्रा में डेटा भेजने से बचें और/या सर्वर पर राउंडट्रिप्स करने से बचें, इसलिए यदि आपके एप्लिकेशन में इनमें से कोई एक समस्या है तो वे मूल्यवान हो सकते हैं।
अपने शोध को पूरा करने के बाद आपको पता चलेगा कि स्पेक्ट्रम के विपरीत तरफ दो चरम दृश्य हैं। ऐतिहासिक रूप से जावा समुदाय स्टोर प्रोसेस के खिलाफ है, जैसे कि हाइबरनेट जैसे ढांचे की उपलब्धता, इसके विपरीत .NET समुदाय ने अधिक संग्रहित प्रोसेस का उपयोग किया है और यह विरासत vb5/6 दिनों तक जाती है। इस सारी जानकारी को संदर्भ में रखें और सिक्का के दोनों तरफ चरम राय से दूर रहें।
स्पीड संग्रहित प्रोसेस के पक्ष में या उसके पक्ष में निर्णय लेने का प्राथमिक कारक नहीं होना चाहिए। आप इनलाइन एसक्यूएल का उपयोग हाइबरनेट और अन्य ढांचे के साथ एसपी प्रदर्शन प्राप्त कर सकते हैं। रखरखाव पर विचार करें और रिपोर्ट जैसे अन्य कार्यक्रम, स्क्रिप्ट आपके आवेदन द्वारा उपयोग की जाने वाली समान संग्रहित प्रोसेस का उपयोग कर सकती हैं। यदि आपके परिदृश्य को एक ही SQL कोड के लिए एकाधिक उपभोक्ताओं की आवश्यकता है, तो संग्रहित प्रक्रियाएं एक अच्छे उम्मीदवार हैं, रखरखाव आसान होगा। यदि यह मामला नहीं है, और आप इनलाइन एसक्यूएल का उपयोग करने का निर्णय लेते हैं, तो रखरखाव की सुविधा के लिए इसे कॉन्फ़िगरेशन फ़ाइलों में बाहरी करने पर विचार करें।
दिन के अंत में, क्या मायने रखता है कि आपके विशेष परिदृश्य को आपके हितधारकों के लिए सफलता मिलेगी।
उपरोक्त सभी पदों की तरह सुझाव देते हैं, आप पहले अपने एसक्यूएल स्टेटमेंट को साफ करना चाहते हैं, उचित इंडेक्स रखना चाहते हैं। कैशिंग मुश्किल हो सकती है, मैं तब तक टिप्पणी नहीं कर सकता जब तक कि आप जो कुछ हासिल करने की कोशिश कर रहे हैं उस पर अधिक जानकारी न दें।
लेकिन sprocs के बारे में एक बात है, सुनिश्चित करें कि आप यह गतिशील SQL कथन
उत्पन्न क्योंकि एक के लिए, यह व्यर्थ हो जाएगा और यह SQL इंजेक्शन के लिए हमलों अधीन किया जा सकता है न करना ... यह है मैंने देखा परियोजनाओं में से एक में हुआ।
मैं मुख्य रूप से अपडेट के लिए स्पॉक्स की अनुशंसा करता हूं, और फिर कथन का चयन करता हूं। शुभकामनाएं :)
"इसे कनेक्शन स्ट्रिंग के साथ पुराना तरीका कर रहा है" गतिशील एसक्यूएल या संग्रहीत प्रक्रियाओं का उपयोग करके आपको कनेक्शन स्ट्रिंग का उपयोग करने की आवश्यकता होती है! – fretje
संक्षिप्त उत्तर: कोई – BlackTigerX