SQL प्रदर्शन, नेट अनुकूलन बनाम उत्तम आचरण

Question

मैं तुम्हें पेशेवरों/निम्नलिखित के साथ गुरुओं से पुष्टि/स्पष्टीकरण की जरूरत है क्योंकि मेरी टीम ने मुझे कह रहा है "यह कोई बात नहीं" और यह मेरे :)

पृष्ठभूमि fustrating है : हमारे पास एक SQL Server 2008 है जिसका उपयोग हमारे मुख्य MVC3/.Net4 वेब ऐप द्वारा किया जा रहा है। हमारे पास किसी दिए गए बिंदु पर लगभग 200+ समवर्ती उपयोगकर्ता हैं। सर्वर को बहुत मुश्किल से मारा जा रहा है (ताले, टाइमआउट, समग्र धीमेपन) और मैं अपने पूरे करियर में और मेरे आखिरी एमएस प्रमाणन वर्ग में जो कुछ सीखा, उसे लागू करने की कोशिश कर रहा हूं। वे चीजें हैं जिन पर हम सभी को ड्रिल किया गया है ("एसक्यूएल एसक्यूएल कनेक्शन स्टेटस") और मैं अपनी टीम को यह बताने की कोशिश कर रहा हूं कि इन 'छोटी चीजें ", हालांकि अकेले अकेले कोई फर्क नहीं पड़ता है, अंत में जोड़ता है।

मुझे पता है कि अगर निम्न एक प्रदर्शन प्रभाव है की जरूरत है या यह सिर्फ 'सबसे अच्छा अभ्यास'

1. का उपयोग करके कीवर्ड "का उपयोग" अगर उनके कोड के अधिकांश इस तरह है:।

public string SomeMethod(string x, string y) { 
    SomethingDataContext dc = new SomethingDataContext(); 
    var x = dc.StoredProcedure(x, y); 
} 

जबकि मैं उन्हें यह बताने की कोशिश कर रहा हूं कि संसाधनों को तेजी से बंद/मुक्त कर देता है:

using (SomethingDataContext dc = new SomethingDataContext()) { 
    var x = dc.StoredProcedure(x, y); 
} 

उनका तर्क यह है कि जीसी कोड निष्पादित करने के बाद पर्याप्त नौकरी की सफाई करता है, इसलिए इसका उपयोग बहुत बड़ा असर नहीं पड़ता है। सच या गलत और क्यों?

2. कनेक्शन ताल

मैं हमेशा कनेक्शन पूल की स्थापना काफी किसी भी वेबसाइट (कम से कम नेट डब्ल्यू/MSSQL) में तेजी लाने के कर सकते हैं के बारे में सुना। मैं हम web.config में हमारे ConnectionStrings के लिए निम्न जोड़ने की सिफारिश की:

... "पूलिंग = सच; मिन पूल आकार = 3; अधिकतम पूल आकार = 100; कनेक्शन समय समाप्त = 10,"। ..

उनका तर्क यह है कि .NET/MSSQL दृश्यों के पीछे कनेक्शन पूल सेट कर चुका है और हमारे web.config में रखना आवश्यक नहीं है। सही या गलत? क्यों हर दूसरी साइट का कहना है कि पूलिंग को इष्टतम प्रदर्शन के लिए जोड़ा जाना चाहिए यदि यह पहले से ही सेटअप हो रहा है?

3. कम से कम कॉल की #

डीबी भूमिका/सदस्यता प्रदाता कि डिफ़ॉल्ट नेट MVC परियोजना अच्छा है के साथ आता है - यह आसान है और आप के लिए शेष काम के सबसे करता है। लेकिन ये लोग UsersInRoles() का गंभीर उपयोग कर रहे हैं और इसे वैश्विक चर की तरह स्वतंत्र रूप से उपयोग करते हैं (यह हर बार इस विधि को डीबी हिट करता है)। मैंने एक "उपयोगकर्ता ऑब्जेक्ट" बनाया है जो प्रत्येक पगेलोड (कुछ अन्य उपयोगकर्ता सामग्री, जैसे कि GUID, आदि) के साथ सभी भूमिकाओं को आगे बढ़ाता है और फिर उपयोगकर्ता के पास भूमिका के लिए इस ऑब्जेक्ट से पूछताछ करता है।

वेबसाइट के अन्य हिस्सों में बयान के लिए 200 गुना अधिक लूप है और प्रत्येक पास = 4,000 डेटाबेस कॉल से 20-30 वर्ग प्रश्न पूछता है। यह किसी भी तरह से सेकंड के मामले में करता है, लेकिन मैं जो करना चाहता हूं वह 20-30 डीबी कॉल को एक में समेकित करता है, ताकि यह 200 बार कॉल (प्रत्येक लूप) को कॉल कर सके। लेकिन चूंकि एसक्यूएल प्रोफाइलर का कहना है कि क्वेरी ने "0 सेकंड" लिया, तो वे तर्क दे रहे हैं कि यह इतना तेज और छोटा है कि सर्वर इन उच्च संख्या में डीबी प्रश्नों को संभाल सकते हैं।

मेरी सोच है "हाँ, ये प्रश्न तेजी से चल रहे हैं, लेकिन वे समग्र SQL सर्वर के प्रदर्शन को मार रहे हैं।" क्या यह एक योगदान कारक हो सकता है? क्या मैं कुछ भी करने की चिंता नहीं कर रहा हूं, या यह सर्वर के समग्र प्रदर्शन मुद्दों के लिए एक महत्वपूर्ण (महत्वपूर्ण) योगदान कारक है?

4. अन्य कोड अनुकूलन

पहले एक जो मन में आता StringBuilder बनाम एक सरल स्ट्रिंग चर का उपयोग कर रहा है। मैं समझता हूं कि मुझे StringBuilder (विशेष रूप से लूप में) का उपयोग क्यों करना चाहिए, लेकिन वे कहते हैं कि इससे कोई फर्क नहीं पड़ता - भले ही उन्हें 10k + लाइनें लिखने की आवश्यकता हो, उनका तर्क यह है कि प्रदर्शन लाभ कोई फर्क नहीं पड़ता।

तो सब कुछ हम सब कुछ सीखते हैं और हमें ड्रिल करते हैं ("स्कोप को कम करें!") वास्तविक प्रदर्शन लाभ के साथ बस 'सर्वोत्तम अभ्यास' या वे सभी वास्तविक/मापनीय प्रदर्शन में योगदान करते हैं नुकसान?

संपादित *** अपने सभी सवालों के जवाब के लिए धन्यवाद लोग! मेरे पास आपके उत्तरों के आधार पर एक नया (5 वां) प्रश्न है: वास्तव में वे "उपयोग" का उपयोग नहीं करते हैं, तो इसका क्या अर्थ हो रहा है? यदि कनेक्शन पूलिंग स्वचालित रूप से हो रही है, तो क्या यह पूल से कनेक्शन को तब तक जोड़ रहा है जब तक कि जीसी न आए? क्या यह संभव है कि SQL सर्वर के लिए प्रत्येक खुले कनेक्शन सर्वर पर थोड़ा अधिक बोझ जोड़ रहा है और इसे धीमा कर रहा है?

आपके सुझावों के आधार पर, मैं कनेक्शन समय के कुछ गंभीर बेंचमार्किंग/लॉगिंग करने की योजना बना रहा हूं क्योंकि मुझे संदेह है कि ए) सर्वर धीमा है, बी) वे कनेक्शन बंद नहीं कर रहे हैं और सी) प्रोफाइलर कह रहा है कि यह 0 में चला गया सेकंड, कनेक्शन से धीमा हो सकता है।

मैं वास्तव में आपकी सहायता लोगों की सराहना करता हूं। एक बार फिर धन्यवाद

Answer 1

कोड को ब्रांच करें, अपने परिवर्तन & बेंचमार्क + वर्तमान कोडबेस के खिलाफ प्रोफाइल करें। फिर आपके दावों का बैक अप लेने के लिए आपके पास कुछ सबूत होगा।

अपने प्रश्नों के लिए के रूप में, यहाँ जाता है:

1. आप हमेशा मैन्युअल वर्ग है जो IDisposable लागू के निपटान करना चाहिए, जीसी वास्तव में हालांकि निपटाने फोन नहीं होगा अगर वर्ग भी एक finalizer लागू करता है तो यह फोन करेगा फाइनलर हालांकि अधिकांश कार्यान्वयन में वे केवल अप्रबंधित संसाधनों को साफ करते हैं।

2. यह सच है कि .NET ढांचा पहले से ही कनेक्शन पूलिंग करता है, मुझे यकीन नहीं है कि डिफ़ॉल्ट क्या हैं लेकिन कनेक्शन स्ट्रिंग मान केवल उनको बदलने के लिए होंगे।

3. एसक्यूएल कथन का निष्पादन समय एसक्यूएल प्रोफाइलर में कहानी का केवल एक हिस्सा है, आप देखेंगे कि डेटाबेस इंजन ने क्वेरी को निष्पादित करने में कितना समय लगाया है, आप जो खो रहे हैं वह समय है वेब सर्वर से डेटाबेस सर्वर से परिणामों को कनेक्ट करने और प्राप्त करने के लिए, ताकि क्वेरी त्वरित हो, आप बैचिंग क्वेरी द्वारा कई आईओ & नेटवर्क विलंबता पर सहेज सकते हैं।

4. यह स्ट्रिंग बिल्डरों पर संयम द्वारा उपयोग की जाने वाली अतिरिक्त मेमोरी साबित करने के लिए कुछ प्रोफाइलिंग करने के लिए एक अच्छा है।

Answer 2

1. वस्तुओं कि IDisposable को लागू करने और inmanaged संसाधनों पर पकड़ भी एक finilizer यह सुनिश्चित करेंगे कि कि निपटाने जीसी दौरान कहा जाता है को लागू, समस्या यह है जब यह कहा जाता है, जीसी बहुत समय ले करने के लिए कर सकते हैं यह और आप migth उस से पहले उन संसाधनों की जरूरत है। जैसे ही आप इसके साथ काम करते हैं, निपटान को कॉल करने का उपयोग करता है।

2. आप मापदंडों webconfig में पूलिंग की डिफ़ॉल्ट रूप से अपने पर अब संशोधित कर सकते हैं लेकिन, ताकि आप कोई कुछ भी

   प्राप्त कर रहे हैं यदि आप डिफ़ॉल्ट पैरामीटर छोड़

3. आप केवल यह कितना समय लगता है के बारे में सोचना नहीं है निष्पादित करने के लिए क्वेरी, लेकिन अनुप्रयोग सर्वर और डेटाबेस के बीच कनेक्शन समय भी, भले ही यह उसी कंप्यूटर पर हो, तो यह एक ओवरहेड जोड़ता है।

4. StringBuilder अभ्यस्त को प्रभावित सबसे वेब अनुप्रयोगों में प्रदर्शन, यह केवल महत्वपूर्ण हो सकता है अगर आप एक ही स्ट्रिंग के लिए 2 कई बार श्रृंखलाबद्ध कर रहे हैं, लेकिन मैं अपने एक अच्छा विचार है अपने पढ़ने में आसान है, क्योंकि यह उपयोग करने के लिए लगता है।

Answer 3

ठीक है, मैं एक गुरु नहीं हूँ, लेकिन मैं एक सुझाव है कार्य करें: यदि वे कहते हैं कि तुम गलत हो, उन्हें बता "यह साबित मुझे एक परीक्षण लिखें मुझे दिखाओ कि 4000 कॉल बस कर रहे हैं!! 200 कॉल जितनी तेजी से और सर्वर पर एक ही प्रभाव पड़ता है! "

अन्य चीजों के लिए। यदि आप उन्हें सही साबित करने की स्थिति में नहीं हैं, तो स्पष्ट, अच्छी तरह से प्रलेखित परीक्षणों के साथ उन्हें गलत साबित करें जो दिखाते हैं कि आप जो कह रहे हैं वह सही है।

यदि वे कठोर सबूत के लिए भी खुले नहीं हैं, तो अपने सर्वर से एकत्र हुए, कोड के साथ वे देख सकते हैं और निरीक्षण कर सकते हैं, तो आप उस टीम पर अपना समय बर्बाद कर सकते हैं।

Answer 4

खंड का उपयोग कर बस वाक्यात्मक चीनी, आप अनिवार्य रूप से कर रहे हैं है

try 
{ 
    resouce.DoStuff(); 
} 
finally 
{ 
    resource.Dispose() 
} 

निपटान शायद जब वस्तु कचरा एकत्र किया जाता है वैसे भी कहा जाता है करने के लिए जा रहा है, लेकिन ढांचे प्रोग्रामर एक अच्छा किया ही अगर the disposable pattern लागू करने का काम। तो यहां आपके सहयोगियों के खिलाफ तर्क हैं:

i) अगर हम उपयोग करने की आदत में आते हैं तो हम अप्रबंधित संसाधनों को मुक्त करना सुनिश्चित करते हैं क्योंकि सभी ढांचे प्रोग्रामर डिस्पोजेबल पैटर्न को लागू करने के लिए स्मार्ट नहीं हैं।

ii) हां, जीसी अंततः उस वस्तु को साफ कर देगा, लेकिन उस वस्तु के बारे में कितना पुराना है, इसमें कुछ समय लग सकता है। एक जीन 2 जीसी सफाई प्रति सेकंड केवल एक बार किया जाता है।

कम पर

तो:

1. ऊपर

2. हाँ, पूलिंग 100

3. आप सही हैं के लिए सही और अधिकतम पूल आकार के लिए सेट किया जाता है देखते हैं, निश्चित रूप से सबसे अच्छा क्षेत्र सुधार के लिए धक्का देना।

4. समयपूर्व अनुकूलन सभी बुराइयों की जड़ है। पहले # 1 और # 3 प्राप्त करें। एसक्यूएल प्रोफाइलर और डीबी विशिष्ट विधियों का उपयोग करें (इंडेक्स जोड़ें, उन्हें डिफ्रैगमेंट करें, डेडलॉक्स आदि की निगरानी करें)।

5. हाँ, हो सकता है।इसे मापने का सबसे अच्छा तरीका है - परफ काउंटर एसक्यूएल सर्वर देखें: सामान्य सांख्यिकी - उपयोगकर्ता कनेक्शन; here एक लेख है जो वर्णन करता है कि यह कैसे करें।

हमेशा अपने सुधारों को मापें, सबूत के बिना कोड को न बदलें!

Answer 5

मुझे लगता है कि आपके यहां दो अलग-अलग मुद्दे हैं।

अपने कोड की

1. प्रदर्शन SQL सर्वर डाटाबेस की
2. प्रदर्शन

एसक्यूएल सर्वर

आप एसक्यूएल सर्वर के लिए जगह में किसी भी निगरानी है? क्या आप विशेष रूप से जानते हैं कि कौन से प्रश्न चल रहे हैं जो डेडलॉक्स का कारण बनते हैं?

मैं this article on deadlocks पढ़ूंगा और अपने SQL सर्वर में वास्तव में क्या चल रहा है यह जानने के लिए शानदार Who is active इंस्टॉल करने पर विचार करें। आप ब्रेंट ओज़र द्वारा sp_Blitz इंस्टॉल करने पर भी विचार कर सकते हैं। यह आपको अपने डेटाबेस में क्या हो रहा है और आपको उस समस्या को ठीक करने के लिए टूल देने का एक उत्कृष्ट विचार देना चाहिए।

अन्य कोड

मैं वास्तव में मेरे सिर के ऊपर से अन्य कोड मुद्दों पर टिप्पणी नहीं कर सकता जारी करता है। तो मैं पहले एसक्यूएल सर्वर को देखता हूं।

1. मॉनिटर
2. याद रखें 1

Answer 6

ओए के लिए समस्याएं

प्रोफ़ाइल

फिक्स

जाओ पहचानें। निश्चित रूप से, आप जीसी को आपके लिए अपने डेटाबेस कनेक्शन बंद नहीं कर सकते हैं। जीसी लंबे समय तक नहीं हो सकता है ... कभी-कभी घंटों बाद। जैसे ही चर एक गुंजाइश से बाहर हो जाता है, यह तुरंत नहीं होता है। अधिकांश लोग() {} वाक्यविन्यास का उपयोग करके IDISposable का उपयोग करते हैं, जो कि बहुत अच्छा है, लेकिन कम से कम कुछ पर, कहीं कनेक्शन को कॉल करने की आवश्यकता है। बंद करें()

Answer 7

मैं हाल ही में हमारे वेब के बीच बातचीत में एक बग से निपट रहा था आवेदन और हमारे ईमेल प्रदाता। जब एक ईमेल भेजा गया था, एक प्रोटोकॉल त्रुटि आई। लेकिन अभी नहीं।

मैं यह निर्धारित करने में सक्षम था कि त्रुटि तब हुई जब SmtpClient उदाहरण बंद कर दिया गया था, जो तब हुआ था जब SmtpClient का निपटान किया गया था, जो केवल कचरा संग्रह के दौरान हो रहा था।

और मैंने देखा है कि इस बार दो मिनट के बाद "भेजें" बटन क्लिक किया गया था ले लिया ...

जरूरत नहीं कहने के लिए, कोड अब ठीक से दोनों SmtpClient और MailMessage उदाहरण के लिए using ब्लॉक लागू करता है।

बस बुद्धिमान के लिए एक शब्द ...

Answer 8

1 अच्छी तरह से ऊपर (मैं इसे अच्छी तरह से निपटाने हालांकि, से सहमत हैं, और यह एक अच्छा अभ्यास के रूप में मिल गया है) को संबोधित किया गया है।

2 ओडीबीसी के पिछले संस्करणों से होल्ड-ओवर का थोड़ा सा हिस्सा है जिसमें SQL सर्वर कनेक्शन पूलिंग के संबंध में स्वतंत्र रूप से कॉन्फ़िगर किए गए थे। यह गैर-डिफ़ॉल्ट होता था; अब यह डिफ़ॉल्ट है।

3 और 4 के रूप में, 4 आपके SQL सर्वर के प्रदर्शन को प्रभावित नहीं करेगा - StringBuilder UI के भीतर प्रक्रिया को गति देने में मदद कर सकता है, निश्चित रूप से, जो आपके SQL संसाधनों को तेज़ी से बंद करने का प्रभाव हो सकता है, लेकिन वे जीते SQL सर्वर पर लोड को कम नहीं करें।

3 मुझे ध्यान केंद्रित करने के लिए सबसे तार्किक स्थान की तरह लगता है। मैं जितनी जल्दी हो सके अपने डेटाबेस कनेक्शन को बंद करने की कोशिश करता हूं, और कम से कम कॉल को संभव बनाने के लिए। यदि आप LINQ का उपयोग कर रहे हैं, तो सबकुछ IQueryable या कुछ (सूची, सरणी, जो कुछ भी) में खींचें ताकि आप इसे किसी भी होकम से पहले कनेक्शन जारी करते समय & जो भी यूआई संरचनाओं की आवश्यकता हो, उसका उपयोग कर सकें।

उन सभी ने कहा, ऐसा लगता है जैसे आपको प्रोफाइलर के साथ कुछ और गुणवत्ता का समय बिताना होगा। प्रत्येक निष्पादन के समय की मात्रा को देखने के बजाय, प्रोसेसर & स्मृति उपयोग को देखें। सिर्फ इसलिए कि वे तेज़ हैं इसका मतलब यह नहीं है कि वे "भुखमरी" निष्पादन नहीं हैं।

Answer 9

सिर्फ दोहरा यहाँ क्या अन्य लोगों ने कहा के जोखिम पर, यहां इस मामले पर मेरी 2c है

सबसे पहले, आप अपनी लड़ाई ध्यान से चुनना चाहिए ... मैं सभी 4 पर अपने सहयोगियों के साथ युद्ध में जाने नहीं होगा अंक क्योंकि जैसे ही आप उनमें से एक साबित करने में विफल रहते हैं, यह खत्म हो गया है, और उनके परिप्रेक्ष्य से वे सही हैं और आप गलत हैं। यह भी ध्यान में रखें कि किसी को भी अपने प्यारे कोड को एक बदसूरत बच्चा नहीं बताया जाना चाहिए, इसलिए मुझे लगता है कि आप राजनयिक होंगे - यह मत कहें कि "यह धीमा है", कहें "मुझे इसे बनाने का एक तरीका भी मिला तेज़ ".... (निश्चित रूप से आपकी टीम पूरी तरह से उचित हो सकती है, इसलिए मैं अपने अनुभव पर भी आधार दे रहा हूं :) इसलिए आपको पहले निपटने के लिए उपरोक्त 4 क्षेत्रों में से एक को चुनना होगा।

मेरा पैसा # 3 पर है। 1, 2 और 4 एक अंतर बना सकते हैं, लेकिन मेरे अपने अनुभव में, इतना नहीं - लेकिन जो आपने # 3 में वर्णित किया है, वह पुराने पुराने सर्वर के लिए हजार पेपरकूट द्वारा मौत की तरह लगता है! प्रश्न शायद तेजी से निष्पादित होते हैं क्योंकि उन्हें पैरामीटर किया जाता है, इसलिए उन्हें कैश किया जाता है, लेकिन आपको यह ध्यान में रखना होगा कि प्रोफाइलर में "0 सेकंड" 900 मिलीसेकंड हो सकता है, यदि आप देखते हैं कि मेरा क्या मतलब है ... इसे कई लोगों के लिए जोड़ें और चीजें धीमी हो रही हैं; यह ताले का प्राथमिक स्रोत भी हो सकता है क्योंकि यदि इनमें से प्रत्येक नेस्टेड प्रश्न एक ही टेबल को मार रहे हैं, इससे कोई फर्क नहीं पड़ता कि आपके द्वारा उल्लिखित उपयोगकर्ताओं की संख्या के साथ, यह निश्चित है कि आपको विवाद होगा। एसक्यूएल को पकड़ें और इसे एसएसएमएस में चलाएं लेकिन क्लाइंट सांख्यिकी शामिल करें ताकि आप न केवल निष्पादन समय देख सकें बल्कि क्लाइंट को वापस भेजे जा रहे डेटा की मात्रा भी देख सकें; जो आपको शामिल करने के लिए किस तरह के ओवरहेड की एक स्पष्ट तस्वीर देगा।

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

अपने 5 वें प्रश्न को छूने के लिए - मुझे यकीन नहीं है, लेकिन मुझे लगता है कि कोई भी SQL कनेक्शन जो ऑटो-डिस्प्ले (उपयोग के माध्यम से) नहीं है, अभी भी "सक्रिय" के रूप में गिना जाता है और पूल से अब उपलब्ध नहीं है।ऐसा कहा जा रहा है - कनेक्शन ओवरहेड सर्वर पर बहुत कम है जब तक कि कनेक्शन वास्तव में कुछ भी नहीं कर रहा है - लेकिन आप फिर से SQL प्रदर्शन काउंटर का उपयोग करके इसे साबित कर सकते हैं।

इसके साथ सबसे अच्छी किस्मत, यह जानने के लिए इंतजार नहीं कर सकती कि आप कैसे प्राप्त करते हैं।