2012-03-26 23 views
11

के प्रदर्शन में वृद्धि का इंतजार है, मैंने हाल ही में c#-5 और नई & अच्छी एसिंक्रोनस प्रोग्रामिंग सुविधाओं के बारे में एक लेख पढ़ा है। मुझे लगता है कि यह विंडोज़ एप्लिकेशन में गेटेट काम करता है। सवाल यह हुआ कि क्या यह सुविधा एएसपी.Net प्रदर्शन को बढ़ा सकती है?एसिंक और एएसपी.Net अनुप्रयोग

public T GetData() 
{ 
    var d = GetSomeData(); 
    return d; 
} 

और

public async T GetData2() 
{ 
    var d = await GetSomeData(); 
    return d; 
} 

एक ASP.Net appication कि दोनों कोड अंतर में है:

इस दो psudo कोड पर विचार?

धन्यवाद

उत्तर

14

ठीक है शुरुआत के लिए कोड का दूसरा भाग T के बजाय वापस करेगा। अंतिम जवाब "यह निर्भर करता है"।

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

इसके अतिरिक्त, असीमित सिग्नल का उपयोग छोटी संख्या में थ्रेड पर लंबे समय से चलने वाले अनुरोधों को संभालने के लिए किया जा सकता है, यदि उनमें से अधिकतर अनुरोध बहुत समय के लिए निष्क्रिय होंगे - उदाहरण के लिए एक लंबे समय तक मतदान परिदृश्य में । मैं कुछ परिदृश्यों में SignalR के विकल्प के रूप में उपयोग की जा रही एसिंक क्षमताओं को देख सकता हूं।

सर्वर पक्ष पर एसिंक का लाभ क्लाइंट पक्ष की तुलना में पिन करना कठिन होता है क्योंकि अलग-अलग तरीके हैं जिनसे यह मदद करता है - जबकि "यूआई थ्रेड पर काम करने से बचें" पक्ष इतना स्पष्ट है, लाभ देखना आसान है।

यह न भूलें कि केवल सामने वाले अंत की तुलना में सर्वर-साइड कोडिंग के लिए बहुत कुछ हो सकता है। मेरे अनुभव में, एपीआईएनसी आरपीसी सेवाओं को लागू करते समय उपयोगी होने की संभावना है, खासकर जो अन्य आरपीसी सेवाओं से बात करते हैं।

जैसा कि पासी कहता है, यह सिर्फ वाक्य रचनात्मक चीनी है - लेकिन मेरा मानना ​​है कि यह पर्याप्त मीठा चीनी है कि यह उचित असिंक्रोनस हैंडलिंग के बीच अंतर को संभव बना सकता है और यह बहुत अधिक प्रयास और जटिलता है।

1

के बाद से कोड सर्वर पर निष्पादित किया जाता है और उपयोगकर्ता अभी भी प्रतिक्रिया के लिए प्रतीक्षा करनी होगी, प्रश्न की तरह है - फोन async सिंक कॉल की तुलना में तेजी से जाना है।

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

देखने का एक तरीका है कोशिश करना।

1

नहीं। ये पूरी तरह से वाक्य रचनात्मक चीनी हैं और सरल काम लिखने की अनुमति देकर प्रोग्रामर के रूप में अपना काम आसान बनाते हैं और जब आप बग को ठीक करते हैं तो कोड को आसानी से पढ़ते हैं।

यह UI को अवरुद्ध किए बिना डेटा लोड करने के लिए सरल दृष्टिकोण की अनुमति देता है, इसलिए वास्तव में हाँ, लेकिन वास्तव में नहीं।

+2

उस बिंदु पर जहां यह "एसिंक्रोनि बहुत कठिन है" के बीच का अंतर बनाता है; चलो प्रति अनुरोध एक थ्रेड का उपयोग करें "और" एसिंक्रोनि आसान है - चलो चीजों को और अधिक कुशलता से करें "यह * प्रभाव होगा। सिर्फ इसलिए कि यह * मैन्युअल रूप से किया जा सकता है इसका मतलब यह नहीं है कि इसका उपयोग प्रदर्शन पर * व्यावहारिक * प्रभाव के लिए नहीं किया जा सकता है। –

5

'प्रदर्शन' को परिभाषित करें।

आखिरकार यह एप्लिकेशन समान मात्रा में काम करने जा रहा है क्योंकि यह सिंक्रनाइज़ किया होगा, यह केवल इतना है कि एसिंक्रोनस संस्करण में कॉलिंग थ्रेड ऑपरेशन के लिए दूसरे पर पूरा होने की प्रतीक्षा करेगा, जबकि सिंक्रोनस मॉडल में कार्य करने के लिए एक ही धागा।

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

यदि वेब अनुरोध को एसिंक्रोनस हैंडलर के माध्यम से संभाला जा रहा है, तो फिर, प्रतिक्रिया फिर भी लौटने के लिए समान समय लेगी - हालांकि, आप थ्रेड पूल पर दबाव कम कर सकते हैं, जिससे वेबसर्वर स्वयं और अधिक हो जाता है में उत्तरदायी अनुरोधों को स्वीकार करते हुए - see this other SO उस पर अधिक जानकारी के लिए।

1

यदि आपको कई चीजें करने की आवश्यकता होती है तो यह केवल प्रदर्शन को बढ़ाएगी, जो कि किसी भी अन्य जानकारी की आवश्यकता के बिना किया जा सकता है। अन्यथा आप अनुक्रम में भी कर सकते हैं।

आपके उदाहरण के संदर्भ में, उत्तर नहीं है। पेज को प्रत्येक पर ध्यान दिए बिना इंतजार करना होगा।

+0

मान लीजिए कि "चीज़" आपको चैट संदेश के लिए 5 मिनट तक प्रतीक्षा करनी है। क्या आप चाहते हैं कि प्रत्येक अनुरोध उस धागे को लंबे समय तक बांध दे? आप एक सर्वर पर कितने उपयोगकर्ता का समर्थन करने में सक्षम होना चाहते हैं? (एक लंबे मतदान वाले AJAX अनुरोध के बारे में सोचें।) –

+0

चैट संदेश के लिए मतदान नहीं करना होगा केवल क्लाइंट पोल की आवश्यकता है, संदेश जांचें, फिर हाँ या नहीं के साथ वापस आएं। मैं नहीं देख सका कि कैसे धागा इसके इंतजार में बैठेगा। मैं इसे टाइमर पर आधारित करूंगा। जब तक मैंने आपके प्रश्न को गलत समझा नहीं? –

+2

लंबी-मतदान का बिंदु एक अनुरोध जारी करना है जो डेटा के समय * तुरंत * लौटा सकता है - इसलिए ग्राहक को हर 30 सेकंड या उससे भी ज्यादा मतदान करने की आवश्यकता नहीं होती है। आपको त्वरित प्रतिक्रिया मिलती है, कम अनुरोध, लेकिन आपको बहुत लंबे, लगातार कनेक्शन को संभालने में सक्षम होना चाहिए। –

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