एएसपी.नेट एमवीसी सत्र राज्य राज्य विभाजन, मोंगोडीबी या मेमकैच या ... का उपयोग कर?

Question

मेरी टीम वर्तमान में हमारी कंपनी (Amilia.com) के लिए एक नया सास एप्लिकेशन बना रही है। हम "अल्फा" रिलीज में हैं और एप्लिकेशन को वेब फार्म पर तैनात करने के लिए बनाया गया था।

हमारे सत्र प्रदाता के लिए, हम एसक्यूएल सर्वर मोड (डीवी और टेस्ट में) का उपयोग कर रहे हैं और ऐसा लगता है कि यह "स्केलेबल" नहीं है, इसलिए हम एएसपीनेट में सत्रों को संभालने के लिए सबसे अच्छा समाधान ढूंढ रहे हैं (एमवीसी 3 हमारे मामला)। हम वर्तमान में एसक्यूएल सर्वर का उपयोग कर रहे हैं लेकिन हम लाइसेंस लागत के कारण किसी अन्य प्रणाली पर स्विच करना चाहते हैं।

हम समवर्ती उपयोगकर्ताओं के 20 000 [संपादित, 100k पहले] लक्षित करते हैं। सत्र में, हम एक GUID, एक स्ट्रिंग और कार्ट ऑब्जेक्ट स्टोर करते हैं (हम इसे जितना संभव हो उतना छोटा रखने की कोशिश करते हैं, यह ऑब्जेक्ट हमें प्रत्येक अनुरोध पर 3 प्रश्नों को सहेजने की अनुमति देता है)। हमारे मामले (सफाया)

में प्रोक मोड में असंभव:

ASP.NET में निर्मित समाधान:

कोई सत्र

यहां विभिन्न समाधान मैंने पाया हैं कर सकते हैं एक वेबफर्म में इस्तेमाल नहीं किया जाएगा। (समाप्त)

स्टेटसर्वर मोड: वेबफर्म में उपयोग किया जा सकता है लेकिन यदि सर्वर नीचे चला जाता है, तो मैं अपने सभी सत्र खो देता हूं। (हटाया गया)

एकाधिक सर्वर (http://msdn.microsoft.com/en-ca/magazine/cc163730.aspx#S8) का उपयोग करके विभाजन सर्वर के साथ स्टेटसर्वर मोड (यदि मैं इन सर्वरों में से कोई एक नीचे जाता हूं, तो मेरे उपयोगकर्ताओं का केवल एक हिस्सा ही अपना सत्र खो देगा।

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

एकाधिक सर्वर (http://www.bulletproofideas.net/2011/01/true-scale-out-model-for-aspnet-session.html) का उपयोग करके विभाजन विभाजन के साथ एसक्यूएल सर्वर मोड: यदि इनमें से कोई एक सर्वर नीचे चला जाता है, तो मेरे उपयोगकर्ताओं का केवल एक हिस्सा ही अपना सत्र खो देगा। यदि उपयोगकर्ता डाउनटाइम के बीच कुछ भी नहीं कर रहा था, तो वह अपने पिछले सत्र को पुनर्प्राप्त करेगा अन्यथा उसे साइनइन स्क्रीन पर रीडायरेक्ट कर दिया जाएगा।

कस्टम समाधान:

उपयोग सत्र भंडारण (http://www.adathedev.co.uk/2011/05/mongodb-aspnet-session-state-store.html) के रूप में MongoDB यह एक अच्छा तालमेल हो रहा है लेकिन NoSQL में मेरी जानकारी काफी अल्पविकसित है तो मैं विपक्ष नहीं देख सकता।

मेमकैड का उपयोग करें: समस्या स्टेटसर्वर मोड के समान होगी और यदि memcached सर्वर नीचे चला जाता है, तो मेरे सभी सत्र खो जाते हैं। इसके अलावा, मुझे लगता है कि मेमकैड सत्र सत्र को स्टोर करने के लिए समर्पित नहीं है?

स्केलऑट (http://highscalability.com/product-scaleout-stateserver-memcached-steroids) जैसे वितरित memcached का उपयोग करें: सबसे अच्छा समाधान प्रतीत होता है लेकिन यह पैसे खर्च करता है।

repcached और memcached (http://repcached.lab.klab.org/) का उपयोग करें, मैंने कभी भी उस समाधान के कार्यान्वयन को नहीं देखा है।

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

तो, सबसे अच्छा तरीका क्या है या कम से कम इस बारे में आपकी राय क्या है?

Answer 1

SQL सर्वर सत्र बहुत अच्छा है। चूंकि आपके पास पहले से ही आपके प्राथमिक डेटा को स्टोर करने के लिए SQL सर्वर डेटाबेस है, इसलिए आप केवल एक और डेटाबेस बना सकते हैं और एएसपी.NET सत्र को स्टोर कर सकते हैं।

स्केलेबिलिटी के बारे में, मैं कहूंगा कि आपके पास 100,000 समवर्ती उपयोगकर्ता हैं, तो आपका उपयोगकर्ताबेस 10 लाख या उससे अधिक होना चाहिए। आपको कुछ व्यावहारिक अनुमान करना चाहिए कि वास्तव में इस तरह के एक समवर्ती उपयोगकर्ता लोड तक पहुंचने में कितना समय लगेगा। मेरे पिछले स्टार्टअप में, हमारे पास दुनिया भर के लाखों उपयोगकर्ता थे, 24x7, लेकिन हम शायद ही कभी 10 के समवर्ती उपयोगकर्ताओं तक पहुंचे, भले ही लोग रोज़ाना हमारी साइट का इस्तेमाल करते थे।

यदि आपके पास वास्तव में 100,000 समवर्ती उपयोगकर्ता हैं, तो लाइसेंस लागत आपकी चिंता का सबसे कम होगा। सही व्यापार मॉडल के साथ, 100 के समवर्ती उपयोगकर्ताओं का मतलब है कि आपके पास कम से कम $ 10M राजस्व/वर्ष है।

मैंने myoffice.bt.com बनाया है जो एक SQL सर्वर सत्र और SQL सर्वर आवृत्ति पर सभी प्राथमिक डेटा का उपयोग करता है, लेकिन दो डेटाबेस में। 8 पूर्वाह्न से 10 बजे के बीच, लाखों उपयोगकर्ताओं ने हमारी साइट पर हमला किया। हमारे पास शायद ही कोई प्रदर्शन मुद्दा है। एक दोहरी कोर सर्वर के साथ, 8 जीबी रैम के साथ, आप खुशी से SQL सर्वर इंस्टेंस चला सकते हैं और जब तक आप इसे सही कोड करते हैं तब तक इस तरह के लोड का समर्थन कर सकते हैं। यह सब इस बात पर निर्भर करता है कि आपने कोड कैसे किया है। यदि आपने प्रदर्शन सर्वोत्तम प्रथाओं का पालन किया है, तो आप आसानी से एक डेटाबेस सर्वर पर लाखों उपयोगकर्ताओं को स्केल कर सकते हैं।

से मेरा प्रदर्शन सुझाव पर एक नज़र डालें: http://omaralzabir.com/tag/performance/

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

मैं हमेशा सत्र का उपयोग न करने के समर्थन में हूं। डेवलपर हर समय सत्र का दुरुपयोग करते हैं। जब भी वे एक पृष्ठ से दूसरे पृष्ठ पर डेटा पास करना चाहते हैं, तो वे इसे सत्र में डाल दें। यह खराब डिजाइन में परिणाम। यदि आप वास्तव में 100K समवर्ती उपयोगकर्ता आधार पर स्केल करना चाहते हैं, तो अपने ऐप को सत्र का उपयोग न करने के लिए डिज़ाइन करें। किसी भी लेनदेन डेटा डेटाबेस में संग्रहीत किया जाना चाहिए। कार्ट एक लेनदेन वस्तु है और इस प्रकार यह सत्र पर पकड़ने के लिए उपयुक्त नहीं है। किसी बिंदु पर आपको यह जानना होगा कि कितने गाड़ियां शुरू हो गई हैं लेकिन कभी नहीं रखी जाती है। तो, आपको उन्हें स्थायी रूप से डेटाबेस में स्टोर करने की आवश्यकता होगी।

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

स्थायी रिलेशनल स्टोरेज के साथ, मेमकैड जैसे उच्च प्रदर्शन कैश के सामने, आपके पास बड़े उपयोगकर्ता आधार का समर्थन करने के लिए बहुत बेहतर डिज़ाइन है।

आशा है कि इससे आपकी चिंताओं में मदद मिलेगी।