2009-11-19 7 views
5

मैं एएसपी.नेट के साथ काम करता हूं। आईएमएचओ, एएसपी.नेट में असीमित प्रोग्रामिंग समर्थन सुंदर है। यही है, हम संसाधन गहन कार्य के लिए स्केलेबिलिटी में सुधार करने के लिए BeginXXXX/EndXXXX जोड़ी विधि प्राप्त कर सकते हैं।क्यों केवल एएसपी.नेट में एसिंक्रोनस प्रोग्रामिंग मॉडल है?

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

यह असीमित प्रोग्रामिंग मॉडल पूरी तरह से थ्रेडिंग संसाधनों का लाभ उठा सकता है। भले ही थ्रेडपूल की सीमा है, यह वास्तव में अधिक अनुरोधों को संभाल सकता है। हालांकि, अगर हम सिंक्रोनस तरीके से प्रोग्राम करते हैं, और प्रत्येक अनुरोध को लंबे समय तक I/O की आवश्यकता होती है, तो समवर्ती अनुरोध थ्रेड पूल के आकार से अधिक नहीं होंगे।

हाल ही में, मुझे रेल पर PHP और रूबी जैसे अन्य वेब विकास समाधान का पता लगाने का मौका मिला है। मेरे आश्चर्य के लिए, इन समाधानों में एसिंक्रोनस प्रोग्रामिंग मॉडल का समकक्ष नहीं है। प्रत्येक अनुरोध को पूरे जीवन चक्र के लिए एक थ्रेड या प्रक्रिया द्वारा संभाला जाता है। यही है, प्रतिक्रिया के आखिरी बिट भेजने से पहले धागा या प्रक्रिया पर कब्जा कर लिया जाता है।

एसिंक्रोनस (http://netevil.org/blog/2005/may/guru-multiplexing) के समान कुछ है, लेकिन बेसलाइन यह है कि अनुरोध के लिए हमेशा एक थ्रेड या प्रक्रिया पर कब्जा होता है। यह एएसपी.नेट की तरह नहीं है।

तो, मैं सोच रहा हूं: इन लोकप्रिय वेब समाधान में एएसपी.NET जैसे असीमित प्रोग्रामिंग मॉडल क्यों नहीं हैं? क्यों एएसपी.NET एसिंक्रोनस दृष्टिकोण का उपयोग करने के लिए विकसित होता है?

क्या ऐसा इसलिए है क्योंकि PHP और रूबी-ऑन-रेल ज्यादातर लिनक्स में तैनात हैं? और लिनक्स माइक्रोसॉफ्ट विंडोज की तरह प्रक्रिया/धागा प्रदर्शन जुर्माना पीड़ित नहीं है?

या, वास्तव में PHP और रूबी-ऑन-रेल के लिए असीमित समाधान है जो मुझे नहीं मिला है?

धन्यवाद।

+0

मैं एक ही स्थिति में एक ही स्थिति में सोच रहा हूं। एक फेसबुक ऐप की तरह कुछ के लिए, जहां ऐप के कई अनुरोध बाहरी सेवा कॉल करते हैं, असीमित पृष्ठ प्रसंस्करण ऐसा लगता है जैसे यह बहुत बेहतर थ्रूपुट की अनुमति देगा। मैं उत्सुक हूं कि रेल पर रूबी की तुलना कैसे की जाएगी। –

+0

PHP अन्य सेवाओं के लिए एसिंक्रोनस अनुरोध कर सकता है, लेकिन वर्तमान अनुरोध को संभालने वाला धागा/प्रक्रिया हमेशा कब्जा कर लिया जाता है। इसलिए, यह केवल कई बाहरी सेवा कॉल के लिए लाभान्वित है। –

उत्तर

4

मेरे पास आपके प्रश्न का एक निश्चित उत्तर नहीं है, लेकिन मैं एक शिक्षित अनुमान लगा सकता हूं।

PHP और रूबी जैसे सिस्टम बहुत मंच-स्वतंत्र होने के लिए डिज़ाइन किए गए हैं, जबकि एएसपी.नेट को विंडोज प्लेटफ़ॉर्म में गहराई से एकीकृत किया गया है। इसके अलावा, PHP एक रैखिक, स्टार्ट-टू-फिनिश प्रवाह के साथ पुरानी शैली एएसपी की तरह है।

पूर्ण एएसपी.नेट-शैली एसिंक पृष्ठों को न केवल धागे की आवश्यकता होती है, लेकिन देशी एसिंक I/O को उनके अधिकतम प्रभाव में उपयोग किया जाना चाहिए। Async I/O एक ओएस-विशिष्ट क्षमता है। Async पेज भी पृष्ठ जीवन चक्र की अवधारणा पर भरोसा करते हैं, जो रैखिक प्रवाह शैली के लिए अनाथाश्रम है। एक पृष्ठ जीवन चक्र के बिना, आपके शेष पृष्ठ के साथ एसिंक कॉल के परिणामों को एकीकृत करना अधिक कठिन हो जाता है।

बस मेरे दो सेंट, वाईएमएमवी।

संबंधित मुद्दे