प्रदर्शन में सुधार करने के लिए सबसे अच्छा तरीका (और किसी भी तरह की विफलता शामिल करें)

Question

हमारे पास एक ऐसा एप्लिकेशन है जहां आईआईएस और एसक्यूएल एक ही मशीन पर हैं। यह विंडोज़ 33 मानक सर्वर है, जिसमें वीजी पर 4 गीगा रैम चल रहा है।

अब उपयोगकर्ताओं की संख्या लगातार बढ़ रही है। कुछ बड़े आंकड़े भी हैं, जिन्हें उपयोगकर्ताओं द्वारा चलाया जा सकता है लेकिन अन्य उपयोगकर्ताओं के प्रदर्शन के बहुत अधिक प्रभाव पड़ते हैं। तो हमें किसी भी तरह प्रदर्शन को बेहतर बनाने की जरूरत है।

मैंने आईआईएस और एसक्यूएल को 2 अलग मशीनों पर विंडोज 2008 64 बिट और प्रत्येक मशीन के लिए कम से कम 6 गीगा रैम से अलग करने का विचार किया, लेकिन इसमें एक फेलओवर समाधान भी होना चाहिए।

क्या आप प्रदर्शन और विफलता समस्या को हल करने के लिए कुछ परिदृश्यों की अनुशंसा कर सकते हैं?

धन्यवाद

पुनश्च:

बस जानकारी के लिए: हम अब IIS में राज्य प्रबंधन inproc उपयोग कर रहे हैं, लेकिन मुझे लगता है कि यह बेहतर होगा sqlstatemanagement को बदलने के लिए।

संपादित

मैं विफलता की बात करने के सवाल चौड़ी है। चूंकि हमारा ग्राहक सर्वर और एसक्यूएल लाइसेंस पर ज्यादा पैसा खर्च नहीं करना चाहता है। क्या यह एक दूसरे SQL सर्वर पर प्रतिकृति के लिए "ठीक" होगा और इसे एक विफलता के रूप में उपयोग करें? क्या आप कुछ बेहतर "सस्ते" समाधान जानते हैं?

आवेदन केवल आंतरिक उपयोग के लिए है, लेकिन अब इस परियोजना में अधिक से अधिक विभाग शामिल हैं।

Answer 1

है वीएम पर बिट ओएस मुझे लगता है। चूंकि मानक संस्करण AWE दो सर्वर (आईआईएस और एसक्यूएल) की अनुमति नहीं देता है, तो SQL सर्वर अधिकतम 1.8 जीबी तक लोड करेगा और आईआईएस और ओएस को बहुत सी रैम छोड़ देगा। लेकिन एक बार जब आप 64 बिट ओएस चीजों पर जाते हैं तो बदलेगा क्योंकि SQL सर्वर अपने बफर पूल (~ 5 जीबी उपलब्ध होने पर 5 जीबी) के लिए सभी रैम लेगा और फिर इसे notified पर ओएस पर वापस देना शुरू कर देगा। यह व्यवहार SQL सर्वर memory options को कॉन्फ़िगर करके tweaked किया जा सकता है। आईआईएस और एसक्यूएल को अलग-अलग वीएम पर विभाजित करके आप अपने बफर पूल के लिए एसक्यूएल वीएम पर सभी मेमोरी छोड़ देते हैं, और यह अच्छा है। आदर्श रूप से आपके पास पर्याप्त रैम होना चाहिए ताकि एसक्यूएल पूरे डेटाबेस को स्मृति में (tempdb सहित) लोड कर सके और केवल लॉग लिखने के लिए डिस्क को स्पर्श कर सके और जब इसे डेटाबेस को चेकपॉइंट करना होगा। दूसरे शब्दों में, अधिक रैम का अर्थ है तेज़ एसक्यूएल। यह अब तक का सबसे महत्वपूर्ण हार्डवेयर संसाधन एसक्यूएल प्रदर्शन के लिए आवश्यक है और हिरन के लिए सबसे बड़ी धमाके देगा।

अब 'विफलता' पर व्यापक प्रश्न पर वापस जाएं। SQL सर्वर में high availability दो श्रेणियों में विभाजित: स्वचालित और मैनुअल के लिए समाधान।

• Clustering: स्वचालित विफलता के लिए आप वास्तव में केवल कुछ ही समाधान है। परंपरागत रूप से यह क्लस्टरिंग का समर्थन करने वाले हार्डवेयर की उच्च लागत के कारण लागू करने के लिए महंगा है, लेकिन वीएम के साथ यह एक अलग कहानी है। मानक संस्करण एसक्यूएल दो नोड क्लस्टर का समर्थन करता है। क्लस्टरिंग तैनाती करने में थोड़ा मुश्किल है, लेकिन यह काफी आसान काम है और समर्थन के लिए कोई एप्लिकेशन परिवर्तन की आवश्यकता नहीं है। फेलओवर की इकाई क्लस्टरिंग के साथ एक संपूर्ण SQL सर्वर उदाहरण है (यानी मास्टर/tempdb/मॉडल और एमएसडीबी सहित सभी डेटाबेस, सभी लॉग इन, सभी एसक्यूएल एजेंट नौकरियां इत्यादि)। एक क्लस्टर एक प्रदर्शन समाधान नहीं है, क्योंकि स्टैंड-बाय सर्वर केवल मुख्य क्रैश होने पर निष्क्रिय रहता है। आप तथाकथित 'सक्रिय-सक्रिय' क्लस्टर को तैनात करके स्टैंड-बाय वीएम का लाभ उठा सकते हैं। इसका मतलब यह है कि आप दो क्लस्टर, वीएम 1 पर सक्रिय और वीएम 2 पर स्टैंड-बाय, अन्य वीएम 2 पर सक्रिय और वीएम 1 पर खड़े हैं। विफलता के मामले में वीएम में से एक को दोनों उदाहरणों का भार लेना होगा, और यही कारण है कि सक्रिय-सक्रिय तैनाती कभी-कभी डूब जाती है। यह देखते हुए कि आप वीएम पर तैनात करने की योजना नहीं बना रहे हैं (महंगे) धातु पर, मैं इसके खिलाफ अनुशंसा करता हूं क्योंकि 'ammortize' के लिए कोई बड़ी लागत नहीं है।
• Mirroring। यह आपके डेटाबेस (उदाहरण के लिए नहीं) का एक गर्म स्टैंड-दर्पण दर्पण रखेगा। कम लागत की तैनाती (कोई विशेष हार्डवेयर), कम विफलता समय (क्लस्टरिंग में मिनटों के विपरीत सेकंड) और भूगर्भीकरण क्षमताओं के कारण मिररिंग को क्लस्टरिंग के लिए प्राथमिकता दी जाती है (मिररिंग अलग-अलग महाद्वीपों पर नोड्स के वितरण का समर्थन करती है, क्लस्टरिंग केवल कुछ ही दूरी का समर्थन करती है नोड्स के बीच सौ मीटर)। लेकिन क्योंकि फेलओवर की इकाई डेटाबेस है, मिररिंग क्लस्टरिंग के उपयोग की आसानी प्रदान नहीं करती है। किसी एप्लिकेशन द्वारा आवश्यक संसाधनों को डेटाबेस में रहते हैं: लॉग इन, एजेंट नौकरियां, रखरखाव योजनाएं, डेटाबेस मेल संदेश आदि। चूंकि केवल डेटाबेस विफल हो जाता है, इसलिए विफलता सावधानीपूर्वक योजनाबद्ध होती है ताकि एप्लिकेशन विफलता के बाद काम जारी रखे (उदाहरण के लिए लॉग इन को स्थानांतरित करना होगा)।एप्लिकेशन को मिररिंग परिनियोजन के बारे में भी जागरूक होना चाहिए ताकि यह connects properly हो। मानक संस्करण के साथ आप केवल high-safety mode में मिररिंग को तैनात करने में सक्षम होंगे।
• हार्डवेयर मिररिंग। मैं इस पर विवरण में प्रवेश नहीं कर रहा हूं, इसके लिए डिस्क स्तर मिररिंग में सक्षम विशेष SAN हार्डवेयर की आवश्यकता है।

  • Log Shipping:

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

• प्रतिकृति। यह वास्तव में एक उच्च उपलब्धता समाधान नहीं है। प्रतिकृति डेटा प्रतियां प्रदान करने और/या साइटों के बीच डेटा अपडेट का आदान-प्रदान करने का एक समाधान है। हालांकि इसका उपयोग किसी प्रकार की उच्च-उपलब्धता मेक-शिफ्ट 'समाधान' को तैनात करने के लिए किया जा सकता है, इसके साथ कई समस्याएं हैं और मूल रूप से कोई फायदा नहीं है। लॉग शिपिंग और मिररिंग दोनों की तुलना में, इसमें अतिरिक्त नुकसान हैं क्योंकि विफलता की इकाई डेटाबेस भी नहीं है, केवल डेटाबेस (कुछ तालिकाओं) के भीतर डेटा का स्लाइस है। उपयोगकर्ता और सुरक्षा अनुमतियों जैसे मेटाडेटा विफल नहीं हैं, स्कीमा परिवर्तन replication aware mode में किया जाना चाहिए और कुछ परिवर्तनों को भी दोहराया नहीं जा सकता है। अनुबंध से दोनों मिररिंग और लॉग शिपिंग उत्पादन डेटाबेस के समान स्टैंड-बाय प्रतिलिपि प्रदान करते हैं जो किसी भी डेटाबेस में किए गए परिवर्तन को स्वचालित रूप से कवर करता है।

आप उल्लेख है कि आप लाइसेंस की लागत के बारे में चिंतित हैं: आप वास्तव में प्रतिकृति को छोड़कर इन प्रौद्योगिकियों से किसी के साथ passive सर्वर से किसी के लिए एक लाइसेंस की जरूरत नहीं है। स्टैंड-बाय सर्वरों को केवल तभी लाइसेंस की आवश्यकता होती है जब वे सक्रिय हो जाएं और 30 दिनों से अधिक समय तक डेटाबेस चलाएं।

आपको वीएम पर तैनात करने की योजना रखने पर विचार करना मेरी पसंद क्लस्टरिंग होगी। यदि आप धातु पर तैनात करेंगे, तो मैं क्लस्टरिंग हार्डवेयर की लागत के बजाय मिररिंग की सिफारिश करता हूं।

Answer 2

एसक्यूएल सर्वर हमेशा काम करता है अगर यह मशीन पर चलने वाली "केवल" चीज है। ऐसा करने से आपको एक त्वरित, आसान और अच्छा लाभ होगा। ऐसा लगता है कि यह सब कुछ नियंत्रित करना पसंद करता है और यह हमेशा खुश रहता है :)

Answer 3

ऐसा लगता है कि आप वास्तव में पूछते हैं कि आप डीबी को एक अलग मशीन पर रखना चाहिए। यह प्रदर्शन में सुधार नहीं कर सकता है (यह वास्तव में विलंबता के रूप में घट जाएगा) लेकिन स्केलेबिलिटी में सुधार होगा (जो मुझे लगता है कि आपको वास्तव में क्या चाहिए)।

प्रदर्शन <> मापनीयता।

हालांकि अधिक समस्याएं खेलती हैं- यदि आपके पास पर्याप्त RAM प्रदर्शन नहीं है तो उसी बॉक्स पर डीबी होने से कम हो सकता है- SQL सर्वर रैम का उपयोग करना पसंद करता है।

यही कारण है कि टीएफएस जैसी चीजों के लिए जो SQL सर्वर का उपयोग करते हैं, कम संख्या में उपयोगकर्ताओं के लिए माइक्रोसॉफ्ट अनुशंसा करता है कि यह सभी 1 मशीन पर स्थापित है, लेकिन उपयोगकर्ताओं की एक बड़ी संख्या के लिए माइक्रोसॉफ्ट की सिफारिश है कि डीबी एक अलग सर्वर पर स्थित है।

आप read about the deployment options for TFS here कर सकते हैं।

एसक्यूएल सर्वर राज्य प्रबंधन स्विचिंग प्रदर्शन में वृद्धि नहीं करेगा- इससे इसकी संभावना कम हो जाएगी, लेकिन आपको अन्य लाभ (विश्वसनीयता जैसे) प्राप्त होंगे।

ऐसा लगता है कि आपको वास्तव में यह पता लगाना होगा कि प्रदर्शन की बाधा क्या है। मेरे अनुभव में यह आम तौर पर डीबी में होता है।

क्या आपने मानक एएसपी.NET अनुकूलन तकनीकों को कैशिंग जैसे देखा है? माइक्रोसॉफ्ट guidance on application tuning प्रदान करता है जो आपके लिए उपयोगी भी हो सकता है।

जब आप किसी वेब अनुप्रयोग परिदृश्य में SQL सर्वर का उपयोग करते हैं, तो यदि आप SQL Server 2005 और ऊपर का उपयोग कर रहे हैं तो आप Snapshot isolation को पढ़ना चाहेंगे। कभी-कभी इसका उपयोग नहीं करना वेब अनुप्रयोगों में प्रदर्शन समस्याओं का एक कारण है।

Answer 4

परतों का पृथक्करण मदद कर सकता है। अक्सर डीबी के लिए मशीन की ट्यूनिंग काफी विशिष्ट होती है, इसलिए यह एक उचित पहला प्रयास है।

हालांकि यदि आपके पास दो प्रकार की उपयोगकर्ता गतिविधियां हैं, जिनमें से एक बहुत भारी है तो आप हमेशा कुछ भारी उपयोगकर्ताओं को आबादी को चोट पहुंचाने का जोखिम चलाने जा रहे हैं।

दो बातें आप विचार कर सकते हैं:

1. आप एक "DataWarehouse" दृष्टिकोण को अपनाने कर सकते हैं? पहले से एक दूसरा डीबी ट्रिकल-फेड लें। नया डीबी जहां भारी उपयोगकर्ता अपना काम करते हैं। निश्चित रूप से उनके आंकड़े थोड़ा पुराना हो जाएंगे, लेकिन यह अवधारणात्मक रूप से हमेशा सत्य होने जा रहा है - जब तक वे जवाबों को देखते हैं तो दुनिया चली जाएगी।
2. किसी भी समय अनुमति देने वाले आंकड़ों की संख्या नियंत्रित करें। शायद उन्हें एक कतार में "नौकरी" के रूप में जमा किया गया है। उन्हें कम प्राथमिकता के रूप में चलाएं।

Answer 5

आप ASP.Net प्रदर्शन ट्यूनिंग

1. http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx
2. http://www.codeproject.com/KB/aspnet/aspnetPerformance.aspx

मैं व्यक्तिगत रूप से मेरे asp.net में इन तकनीकों को लागू किया है के लिए codeproject पर इन 2 लेख का संदर्भ देना चाहिए ऐप्स और 30% से अधिक प्रदर्शन सुधार प्राप्त किया।

इसके अतिरिक्त आप अपने आवेदन के लिए 99.99% अपटाइम के लिए this आलेख देख सकते हैं।

3. http://www.codeproject.com/KB/aspnet/ProdArch.aspx

Answer 6

स्वाभाविक रूप से आईआईएस को अलग करने और एसक्यूएल सर्वर पहला कदम है। एसक्यूएल सर्वर वास्तव में अपने लिए एक पूरी मशीन बनाना चाहता है।

दूसरी बात यह है कि आवेदन करना विश्लेषण के रूप में महत्वपूर्ण है। वास्तविक उपयोग डेटा के बिना अपने एप्लिकेशन के प्रदर्शन को अनुकूलित करने का कभी भी प्रयास न करें, क्योंकि आप संभवतः केवल उन चीज़ों को अनुकूलित करने में समय व्यतीत करते हैं जिन्हें शायद ही कभी बुलाया जाता है। एक तकनीक मैंने पहले भी सफलता के साथ इस्तेमाल किया है Global.asax में Request_Begin में एक System.Diagnostics.Stopwatch बनाते हैं, तो एक संदर्भ चर में संग्रहीत करना

var sw = new Stopwatch(); 
sw.Start() 
HttpContext.Current.Items["stopwatch"] = sw; 

Request_End में, आप स्टॉपवॉच लिए पुन: प्राप्त है

sw = HttpContext.Current.Items["stopwatch"]; 
sw.Stop(); 
Timespan ts = sw.Elapsed; 

और फिर लॉग तालिका में लिखें कि अनुरोध को संसाधित करने में कितना समय लगेगा। यूआरएल को लॉग इन करें (क्वेरी स्ट्रिंग पैरामीटर के साथ और बिना दोनों) और सभी प्रकार की चीजें जो आपको प्रदर्शन का विश्लेषण करने में मदद करेंगी।

फिर आप अपने आवेदन का विश्लेषण कर सकते हैं और पता लगा सकते हैं कि कौन से ऑपरेशन सबसे लंबे समय तक लेते हैं, जिन्हें सबसे अधिक कहा जाता है, आदि। इससे आपको यह देखने की अनुमति मिल जाएगी कि एक पृष्ठ है जो बहुत से अनुरोध किया गया है, और आमतौर पर इसे लंबा लगता है पूरा करने का समय, यह आपके लिए जो भी टूल्स है, उसका उपयोग करके ऑप्टिमाइज़ेशन का लक्ष्य होना चाहिए, दोनों .NET और SQL प्रोफाइलर्स।

अन्य सामान जो मैं सामान्य रूप से लॉग इन करता हूं, आईपी पते और उपयोगकर्ताओं में लॉग इन करने के लिए उपयोगकर्ता आईडी। जब त्रुटियां उत्पन्न होती हैं तो यह मुझे एक अमूल्य डीबगिंग टूल भी देता है।

एक कारण किसी तालिका में यह डाल करने के लिए, के रूप में एक लॉग फ़ाइल के लिए इसे लिखने के लिए विरोध किया है कि आप SQL सिंटैक्स को फ़िल्टर करने, समूह, आदि अभी आप 32 है का उपयोग कर सकते औसत बार की गणना,