वेब सर्वर में प्रोएक्टर पैटर्न और सिंक्रोनस मॉडल के बीच अंतर

Question

सिंक्रोनस मॉडल में, जब कोई क्लाइंट सर्वर से कनेक्ट होता है, तो क्लाइंट और सर्वर दोनों को कुछ ऑपरेशन समाप्त करने के लिए एक दूसरे के साथ सिंक करना पड़ता है।

इस बीच, एसिंक्रोनस मॉडल क्लाइंट और सर्वर को अलग-अलग और स्वतंत्र रूप से काम करने की अनुमति देता है। ग्राहक एक कनेक्शन स्थापित करने और कुछ करने का अनुरोध भेजता है। जबकि सर्वर अनुरोध संसाधित कर रहा है, क्लाइंट कुछ और कर सकता है। एक ऑपरेशन पूरा होने पर, समापन घटना को एक ईवेंट डेमल्टीप्लेक्सर में एक कतार में रखा जाता है, अनुरोध को वापस भेजने और एक पूर्ण हैंडलर (क्लाइंट पर) का आह्वान करने के लिए प्रोएक्टर (जैसे HTTP हैंडलर) की प्रतीक्षा कर रहा है। शब्दों को बूस्ट :: एएसओ दस्तावेज़ The Proactor Design Pattern: Concurrency Without Threads में उपयोग किया जाता है।

इस तरह से काम करके, एसिंक्रोनस मॉडल प्रति कनेक्शन धागा बनाने के बिना एक साथ कनेक्शन स्वीकार कर सकता है, इस प्रकार समग्र प्रदर्शन में सुधार होता है। एसिंक्रोनस मॉडल के समान प्रभाव को प्राप्त करने के लिए, पहला मॉडल (तुल्यकालिक) बहु-थ्रेडेड होना चाहिए। अधिक जानकारी के लिए, देखें: Proactor Pattern (मैं वास्तव में प्रोक्टर पैटर्न सीखता हूं जिसका उपयोग उस दस्तावेज़ से एसिंक्रोनस मॉडल के लिए किया जाता है। यहां इसमें एक विशिष्ट सिंक्रोनस I/O वेब सर्वर पर विवरण है)।

क्या इस विषय पर मेरी समझ सही है? यदि ऐसा है, जिसका अर्थ है कि एसिंक्रोनस सर्वर अनुरोध स्वीकार कर सकता है और परिणामों को असीमित रूप से वापस कर सकता है (वेब ​​कनेक्शन पर सेवा के पहले कनेक्शन अनुरोध को जवाब देने वाले पहले व्यक्ति होने की आवश्यकता नहीं है)? संक्षेप में, एसिंक्रोनस मॉडल थ्रेडिंग का उपयोग नहीं करता है (या थ्रेडिंग का उपयोग अलग-अलग घटकों में किया जाता है, जैसे प्रोक्टर, असिंक्रोनस इवेंट मल्टीप्लेक्सर (बूस्ट :: एएसओ दस्तावेज़) घटक, संपूर्ण क्लाइंट-सर्वर एप्लिकेशन स्टैक बनाकर नहीं, जो वर्णन करता है प्रोक्टर पैटर्न दस्तावेज़ में बहु-थ्रेडेड मॉडल में, सेक्शन 2.2 - परंपरागत Concurrency मॉडल के सामान्य जाल और नुकसान)।

Answer 1

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

पूर्ण Proactor फायदे:

• प्रदर्शन काम "आउटसोर्सिंग" की वजह से बढ़ाया है। उदाहरण के लिए, आप DNS को रिज़ॉल्यूशन अनुरोध भेज सकते हैं और उत्तर देने के लिए 5 मिनट तक प्रतीक्षा कर सकते हैं (रिएक्टर) - या प्रतीक्षा करते समय आप अन्य सामान कर सकते हैं (प्रोक्टर)।

पूर्ण Proactor नुकसान:

• प्रदर्शन कार्य स्विचिंग, जिसका अर्थ है कि एक सत्र के लिए आप और अधिक कोड (Proactor) की तुलना में यह होना चाहिए (रिएक्टर) पर अमल की वजह से कमी आई है।

लेकिन समग्र प्रदर्शन आमतौर पर प्रति समय अवधि के "संतुष्ट" ग्राहकों में मापा जाता है। तो, प्रोक्टर बनाम रिएक्टर के फायदे स्थिति पर निर्भर करते हैं। यहां कुछ उदाहरण दिए गए हैं।

1. HTTP सर्वर। ग्राहक अपनी ब्राउज़र विंडो में कुछ देखना चाहता है। पाठ के पहले टुकड़े देखने के लिए पूरे पृष्ठ को लोड करने से पहले उसे प्रतीक्षा करने की आवश्यकता नहीं है। प्रोएक्टर प्रभावी है, क्योंकि आंशिक पृष्ठ लोडिंग पूरे पृष्ठ लोडिंग से तेज़ है। फिर भी पूरे पृष्ठ को रिएक्टर मॉडल में एक ही समय में लोड किया जाता है।

2. कम विलंबता गेम सर्वर। ग्राहक जितनी जल्दी हो सके अपने आदेश का पूरा परिणाम प्राप्त करना चाहता है। रिएक्टर प्रभावी है, क्योंकि आंशिक पढ़ने या लिखने जैसी कोई उप-कार्य नहीं है - जब तक वह पूर्ण प्रतिक्रिया नहीं पढ़ता तब तक क्लाइंट कुछ भी नहीं देखेगा। तो, रिएक्टर subtasks के बीच अतिरिक्त स्विच नहीं करेगा और प्रत्येक पल में यह गारंटी है कि कुछ ग्राहक अपने आदेश पर प्रगति हो जाते हैं, जबकि प्रोएक्टर सभी ग्राहकों को एक-दूसरे के अप्रत्याशित समय की प्रतीक्षा करने के लिए मजबूर करेगा।

बहु-थ्रेडिंग आपको दोनों मामलों में एक रैखिक त्वरण दे सकता है।