यह एक बहुत अच्छा सवाल है, और समझना महत्वपूर्ण है कि एसिंक्रोनस आईओ इतना महत्वपूर्ण क्यों है। कारण सी # 5.0 में नई async/प्रतीक्षा सुविधा को जोड़ा गया है कारण लेखन एसिंक्रोनस कोड को सरल बनाना है। सर्वर पर एसिंक्रोनस प्रोसेसिंग के लिए समर्थन नया नहीं है, हालांकि यह एएसपी.नेट 2.0 के बाद से मौजूद है।
स्टीव की तरह आपको सिंक्रोनस प्रोसेसिंग के साथ दिखाया गया है, एएसपी.नेट (और डब्ल्यूसीएफ) में प्रत्येक अनुरोध थ्रेड पूल से एक थ्रेड लेता है। जिस मुद्दे पर उन्होंने प्रदर्शन किया वह एक प्रसिद्ध मुद्दा है जिसे "थ्रेड पूल भुखमरी" कहा जाता है। यदि आप अपने सर्वर पर सिंक्रोनस आईओ बनाते हैं, तो आईओ की अवधि के लिए थ्रेड पूल थ्रेड अवरुद्ध रहेगा (कुछ नहीं कर रहा है)।चूंकि लोड के तहत थ्रेड पूल में धागे की संख्या में एक सीमा है, इसलिए यह ऐसी परिस्थिति में हो सकता है जहां सभी धागे पूल धागे को आईओ के लिए इंतजार कर रहे हैं, और अनुरोध कतार में शुरू होने लगते हैं, जिससे प्रतिक्रिया समय में वृद्धि होती है। चूंकि सभी धागे एक आईओ को पूरा करने की प्रतीक्षा कर रहे हैं, इसलिए आप एक सीपीयू व्यवसाय 0% के करीब देखेंगे (भले ही प्रतिक्रिया समय छत के माध्यम से जाएं)।
आप क्या पूछ रहे हैं (हम एक बड़े थ्रेडपूल का उपयोग क्यों नहीं कर सकते?) एक बहुत अच्छा सवाल है। वास्तव में, इस प्रकार अधिकांश लोग थ्रेड पूल भुखमरी की समस्या को हल कर रहे हैं: अभी थ्रेड पूल पर अधिक धागे हैं। माइक्रोसॉफ्ट के कुछ दस्तावेज यह भी इंगित करते हैं कि थ्रेड पूल भुखमरी होने पर स्थितियों के लिए एक फिक्स के रूप में। यह एक स्वीकार्य समाधान है, और सी # 5.0 तक, यह करना बहुत आसान था, अपने कोड को पूरी तरह से असीमित होने के लिए पुनः लिखने से।
वहाँ दृष्टिकोण के साथ कुछ समस्याएं हालांकि इस प्रकार हैं:
कोई मूल्य है कि सभी परिस्थितियों में काम करता है: थ्रेड पूल धागे आप की जरूरत करने जा रहे हैं की संख्या रैखिक की अवधि पर निर्भर करता है आईओ, और आपके सर्वर पर लोड। दुर्भाग्य से, आईओ विलंबता ज्यादातर अप्रत्याशित है। यहां एक उदाहरण है: मान लीजिए कि आप अपने एएसपी.NET एप्लिकेशन में किसी तृतीय पक्ष वेब सेवा पर HTTP अनुरोध करते हैं, जो पूर्ण होने में लगभग 2 सेकंड लगते हैं। आपको थ्रेड पूल भुखमरी का सामना करना पड़ता है, इसलिए आप थ्रेड पूल आकार को बढ़ाने का फैसला करते हैं, मान लें, 200 धागे, और फिर यह फिर से ठीक काम करना शुरू कर देता है। समस्या यह है कि शायद अगले हफ्ते, वेब सेवा में तकनीकी समस्याएं होंगी जो उनके प्रतिक्रिया समय को 10 सेकंड तक बढ़ा देती हैं। अचानक, थ्रेड पूल भुखमरी वापस आ गई है, क्योंकि थ्रेड 5 गुना अधिक अवरुद्ध हैं, इसलिए अब आपको संख्या 5 गुणा, 1,000 धागे तक बढ़ाने की जरूरत है।
स्केलेबिलिटी और प्रदर्शन: दूसरी समस्या यह है कि यदि आप ऐसा करते हैं, तो भी आप प्रति अनुरोध एक थ्रेड का उपयोग करेंगे। धागे एक महंगे संसाधन हैं। .NET में प्रत्येक प्रबंधित थ्रेड को स्टैक के लिए 1 एमबी की मेमोरी आवंटन की आवश्यकता होती है। पिछले 5 सेकंड में आईओ बनाने वाले वेबपेज के लिए, और प्रति सेकंड 500 अनुरोधों के भार के साथ, आपको अपने थ्रेड पूल में 2,500 धागे की आवश्यकता होगी, जिसका अर्थ है थ्रेड के ढेर के लिए 2.5 जीबी मेमोरी जो कुछ भी नहीं कर पाएगी। फिर आपके पास संदर्भ स्विचिंग का मुद्दा है, जो आपकी मशीन के प्रदर्शन पर भारी टोल लेगा (मशीन पर सभी सेवाओं को प्रभावित करेगा, न केवल आपके वेब एप्लिकेशन)। भले ही विंडोज प्रतीक्षा थ्रेड को अनदेखा करने में काफी अच्छा काम करता है, लेकिन यह इतनी बड़ी संख्या में धागे को संभालने के लिए डिज़ाइन नहीं किया गया है। याद रखें कि उच्चतम दक्षता प्राप्त की जाती है जब थ्रेड की संख्या मशीन पर लॉजिकल सीपीयू की संख्या के बराबर होती है (आमतौर पर 16 से अधिक नहीं)।
तो थ्रेड पूल के आकार में वृद्धि एक समाधान है, और लोगों को एक दशक (माइक्रोसॉफ्ट के स्वयं के उत्पादों में भी) के लिए है कि कर रहे हैं, यह सिर्फ कम स्केलेबल और कुशल है, स्मृति और CPU के मामले में उपयोग, और आप हमेशा आईओ विलंबता की अचानक वृद्धि की दया पर हैं जो भुखमरी का कारण बनता है। सी # 5.0 तक, असीमित कोड की जटिलता कई लोगों के लिए परेशानी के लायक नहीं थी। async/प्रतीक्षा अब सबकुछ बदलता है, आप एसिंक्रोनस आईओ की स्केलेबिलिटी से लाभ उठा सकते हैं, और एक ही समय में सरल कोड लिख सकते हैं।
अधिक विवरण:। वेब सेवाओं या दूरस्थ वस्तुओं को उत्पन्न करने के लिए अतिरिक्त समानांतर प्रसंस्करण प्रदर्शन करने के लिए, जबकि वेब सेवा कॉल प्राप्त आय जहां संभव हो, तुल्यकालिक (अवरुद्ध) से बचने के लिए एक अवसर है जब वहाँ http://msdn.microsoft.com/en-us/library/ff647787.aspx "अतुल्यकालिक कॉल उपयोग वेब सेवाओं के लिए कॉल क्योंकि आउटगोइंग वेब सेवा कॉल एएसपी.नेट थ्रेड पूल से धागे का उपयोग करके बनाई जाती हैं। कॉलिंग कॉल अन्य आने वाले अनुरोधों को संसाधित करने के लिए उपलब्ध धागे की संख्या को कम करते हैं। "
यह उत्तर प्रश्न के दूसरे भाग का उत्तर नहीं देता है। – nunespascal
एसिंक पैटर्न पर जाने के लिए अच्छा तर्कसंगत। – eduncan911
मुझे नहीं लगता कि यह इस तथ्य को संबोधित करता है कि I/O अप्रत्याशित होने के बावजूद और जो कुछ भी निर्धारित किया गया है, उपयोगकर्ता को अभी भी प्रतिक्रिया प्राप्त करने से पहले सबकुछ करने की प्रतीक्षा करनी है। तथ्य यह है कि http/Web सर्वर स्वयं अधिक भार संभाल सकता है इसका मतलब यह नहीं है कि यह अनुरोध को पूरी तरह से संसाधित करने में सक्षम है। मैं नहीं देखता कि एसिंक इस बात को बदलने के अलावा कैसे हल करता है कि चीज़ों को कैसे वितरित किया जाता है और संभावित रूप से अधिक महंगा संदर्भ स्विचिंग शुरू किया जाता है। – nilskp