मैं तर्क दूंगा कि यह एक अर्थशास्त्र का सवाल है। हालाँकि, यह एक निर्णय कॉल है जो इंजीनियरों को करने में सक्षम होना चाहिए। इसलिए, मैं जवाब दे रहा हूं।
मैं अपने उत्तर को चार भागों में विभाजित कर रहा हूं:
- जोखिम प्रबंधन
- रणनीतियाँ
- लागत
- सहज बोध
जोखिम प्रबंधन
तो, कभी-कभी आपका क्लाइंट सर्वर से प्रतिक्रिया प्राप्त करने में विफल रहता है। मुझे लगता है कि यह एक प्रोग्रामेटिक त्रुटि के कारण नहीं है (अन्यथा समाधान इसे ठीक करना है, इसलिए ऐसा करें)। इसके बजाय, यह आपके नियंत्रण से परे एक भाग्यशाली स्थिति के कारण होना चाहिए ...
लेकिन अपने ज्ञान से परे नहीं। आपको पता होना चाहिए:
- कितनी बार होता है
- इसका क्या प्रभाव पड़ता है।
उदाहरण के लिए, यदि विफल और पुन: प्रयास केवल 2% समय के लिए होता है, तो संभवतः इसे संबोधित करने के लायक नहीं है। यदि यह समय का लगभग 80% होता है, तो अच्छी तरह से ... निर्भर करता है ...
ग्राहक को कितना समय इंतजार करना पड़ता है? और यह कैसे लागतों में तब्दील होता है ... आप देखते हैं, आपके पास एक नियमित आवेदन में थोड़ी देरी है, यह शायद एक बड़ी बात नहीं है। यदि यह महत्वपूर्ण है, और आपके पास वास्तविक समय एप्लिकेशन या ऑनलाइन वीडियो गेम है, तो यह उपयोगकर्ताओं को दूर कर देगा, और आप शायद अधिक या बेहतर सर्वर में निवेश करने से बेहतर हैं। अन्यथा, आप शायद "लोडिंग" या "सर्वर के लिए प्रतीक्षा" संदेश डाल सकते हैं। जब तक, विलंब वास्तव में बड़ा होता है (दसियों सेकंड के क्रम में), तब नियमित आवेदन के लिए यह बहुत अधिक हो सकता है।
रणनीतियाँ
जैसा कि मैंने ऊपर कहा, इस समस्या पर जाने के लिए एक से अधिक तरीके हैं। मुझे लगता है कि आप पहले से ही कोशिश-विफल-पुनर्प्रयास लूप लागू करेंगे। तो, हम देखते हैं ...
- एक लोडिंग संदेश डालें। यह सस्ता है, उपयोगकर्ता को बनाए रखने में मदद करता है।
- समानांतर में क्वेरी। तेजी से हो सकता है, अभी भी विफल हो सकता है। अनावश्यक सर्वर की आवश्यकता होगी (महंगा हो सकता है), सर्वर समय और नेटवर्क ट्रैफ़िक को बर्बाद करेगा।
- समानांतर में क्वेरी तेजी से सर्वर को स्टैब्लिश करने के लिए और वहां से उपयोग करने के लिए। तेजी से हो सकता है, अभी भी विफल हो सकता है। अनावश्यक सर्वर की आवश्यकता होगी (महंगा हो सकता है), ज्यादा सर्वर समय और नेटवर्क यातायात को बर्बाद नहीं करेगा।
अब, ध्यान दें, मैं कहता हूं कि ये अभी भी विफल हो सकते हैं। अगर हम मानते हैं कि किसी सर्वर की क्वेरी में विफलता का 80% मौका है, तो दो सर्वरों के समानांतर क्वेरी में विफलता का 64% मौका है। इस प्रकार, आपको अभी भी पीछे हटना पड़ सकता है।
तेजी से सर्वर को चुनने और इसका उपयोग करने का एक बोनस लाभ यह है कि नेटवर्क समस्याओं के कारण तेजी से सर्वर भी विफल होने की कम संभावना है।
जो मुझे याद दिलाता है, यदि आप यह पता लगा सकते हैं कि अनुरोध विफल क्यों है, तो ऐसा करें। यह आपको स्थिति को बेहतर ढंग से प्रबंधित करने में मदद कर सकता है, भले ही आप असफलताओं को रोक न सकें। उदाहरण के लिए, क्या आपको सर्वर की तरफ अधिक स्थानांतरण गति की आवश्यकता है?
कुछ और:
- दुनिया भर में कई सर्वरों को तैनात करें, और जियोलोकेशन द्वारा सर्वर चुनें।
- सर्वर साइड पर बैलेंसिंग लोड करें (एक समर्पित मशीन सभी अनुरोधों को ले जाएगी, और उन्हें अपने सर्वर पर पुनः स्थापित करें, आप वहां अपनी समानता या बेहतर संतुलन रणनीति बना सकते हैं)।
और किसने कहा कि आपको इनमें से केवल एक करना है? आप एक लोडिंग संदेश डाल सकते हैं, कई सर्वरों को क्वेरी कर सकते हैं जो व्रल्ड में फैले हुए हैं ताकि तेजी से उठा जा सके और केवल उसी का उपयोग करें जिससे विफलता पर, लूप पर पुन: प्रयास करें, और उन सर्वरों में से प्रत्येक में लोड संतुलन के साथ मशीनों का एक समूह हो। । क्यों नहीं? खैर, लागत ...
लागत
चार लागतें हैं:
- विकास की लागत (आमतौर पर बहुत सस्ती)
- तैनाती की लागत (आमतौर पर उच्च)
- लागत रनटाइम (अनुप्रयोग के प्रकार और व्यवसाय मॉडल पर निर्भर करता है)
- विफलता की लागत (शायद कम है, लेकिन बहुत कम नहीं)
आपको उन्हें संतुलित करना होगा।
उदाहरण के लिए, हम कहें कि आप प्रति संतुष्ट उपयोगकर्ता के बारे में एक डॉलर कमाते हैं। कि आपके पास प्रतिदिन 3000 उपयोगकर्ता हैं। यह अनुरोध लगभग 50% समय विफल रहता है। और यह कि 2% उपयोगकर्ता अनुरोध के विफल होने पर भुगतान किए बिना छोड़ देते हैं। इसका मतलब है कि आप हार रहे हैं (3000 * 50% * 2%) प्रति दिन 30 डॉलर। अब, हम कहते हैं कि नई सुविधा को विकसित करने में आपको 100 डॉलर का खर्च आएगा और सर्वर को तैनात करने में आपको 800 डॉलर का खर्च आएगा - और रनटाइम की लागत को अनदेखा करना - इसका मतलब है कि आपके पास (100 + 800) / 30 में निवेश की वापसी होगी ) तीस दिन। अब, आप अपना बजट देख सकते हैं और निर्णय ले सकते हैं।
इन मूल्यों को वास्तविकता का प्रतिनिधि न मानें, मैंने उन्हें गणित के लिए चुना।
परिशिष्टों:
- याद रखें कि मैं विवरणों को भी अनदेखा कर रहा हूं। उदाहरण के लिए, आपके पास बहुत कम लागत हो सकती है लेकिन सीपीयू समय के लिए भुगतान करना होगा और आपको इस पर विचार करने की आवश्यकता है।
- कुछ ग्राहक सराहना कर सकते हैं यदि आप अनावश्यक अनुरोधों में उनके डेटा पैकेज को बर्बाद नहीं करते हैं।
- अपने उत्पाद को बेहतर बनाने से प्राकृतिक विज्ञापन लाने में मदद मिल सकती है।
- अवसर लागत मत भूलना। क्या आपको कुछ और विकसित करना चाहिए?
बात यह है, कि यदि आप लागत को कम करने के संदर्भ में समस्या पर विचार करते हैं, तो आप जिन रणनीतियों पर विचार करते हैं, उनके लिए लागत का अनुमान लगा सकते हैं और निर्णय लेने के लिए इस विश्लेषण का उपयोग कर सकते हैं।
सहज बोध
अनुभव द्वारा बढ़ावा अगर अंतर्ज्ञान। मैं हर बार इस तरह का विश्लेषण करने का सुझाव नहीं दे रहा हूं। कुछ लोग करते हैं, और यह ठीक है। मैं आपको इसके बारे में कुछ समझने और इसके लिए एक अंतर्ज्ञान विकसित करने का सुझाव दे रहा हूं।
फ़ुथर्मोर, इंजीनियरिंग में, वास्तविक ज्ञान से प्राप्त ज्ञान से अलग, हम अभ्यास में भी सीखते हैं कि क्या काम करता है और क्या नहीं करता है। इसलिए, यह देखने के लिए अक्सर बुद्धिमान होता है कि कला की स्थिति क्या है ... हालांकि, कभी-कभी आपको अपने क्षेत्र के बाहर देखने की आवश्यकता होती है।
इस मामले में, मैं ऑनलाइन वीडियो गेम देखूंगा। उनके पास लोड स्क्रीन है, उनके पास कई सर्वर हैं, वे विलंबता के आधार पर एक सर्वर चुनेंगे, और वे उपयोगकर्ता को सर्वर स्विच करने की अनुमति भी दे सकते हैं। हम जानते हैं कि काम करता है।
मैं यह सुझाव देना चाहूंगा कि हर अनुरोध पर नेटवर्क ट्रैफ़िक और सर्वर का समय बर्बाद करने के बजाय, यह भी ध्यान रखें कि अनावश्यक सर्वर के साथ भी विफलता हो सकती है।