धाराओं या घटनाओं

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

दो दृष्टिकोणों में से एक को चुनने के लिए, आपको सर्वर के लोड प्रोफाइल को निर्धारित करना होगा।

मान लें कि प्रत्येक अनुरोध के लिए सीपीयू के सी मिलीसेकंड और प्रक्रिया के लिए वास्तविक समय के मिलीसेकंड की आवश्यकता होती है। सीपीयू समय सक्रिय कंप्यूटिंग पर खर्च किया जाता है, और वास्तविक समय में बाहरी संसाधनों के सभी अनुरोध शामिल हैं। उदाहरण के लिए, डेटाबेस से प्रतिक्रिया की प्रतीक्षा करने के लिए सीपीयू और 95 एमएस से 5 अनुरोध समय की आवश्यकता होती है। परिणाम 100ms है। चलो यह भी मानते हैं कि एक सर्वर का स्ट्रीमिंग संस्करण शेड्यूलिंग और संदर्भ स्विचिंग शुरू होने की समस्याओं से पहले टी थ्रेड तक का समर्थन कर सकता है।

यदि प्रत्येक अनुरोध को संसाधित करने के लिए केवल CPU समय की आवश्यकता होती है, तो सर्वर प्रति सेकंड 1000 / c अनुरोधों पर प्रतिक्रिया देने में सक्षम होता है। उदाहरण के लिए, यदि प्रत्येक अनुरोध में CPU के 2 मिलीसेकंड का समय लगता है, तो आपको प्रति सेकंड 1000/2 = 500 अनुरोध मिलते हैं।

सामान्य तौर पर, एक बहु-थ्रेडेड सर्वर प्रति सेकंड t * 1000 / w अनुरोधों को संसाधित करने में सक्षम होता है।

स्ट्रीमिंग सर्वर की बैंडविड्थ इन अभिव्यक्तियों में न्यूनतम है (1000 / c और t * 1000 / w )। ईवेंट सर्वर केवल CPU प्रदर्शन (1000 / c ) द्वारा सीमित है, क्योंकि यह केवल एक थ्रेड का उपयोग करता है। ऊपर वर्णित सब कुछ निम्नानुसार व्यक्त किया जा सकता है:

def max_request_rate(t, c, w): cpu_bound = 1000. / c thread_bound = t * 1000. / w print 'threaded: %d\nevented: %d' % (min(cpu_bound, thread_bound), cpu_bound) 

अब हम विभिन्न प्रकार के सर्वरों पर विचार करेंगे और देखेंगे कि वे विभिन्न कार्यान्वयनों में खुद को कैसे प्रदर्शित करेंगे।

उदाहरण के लिए, मैं t = 100 का उपयोग करूंगा।

आइए क्लासिक उदाहरण से शुरू करें: HTTP प्रॉक्सी सर्वर। इस प्रकार के सर्वर के लिए लगभग कोई CPU समय की आवश्यकता नहीं होती है, इसलिए मान लीजिए c = 0.1 ms। मान लीजिए कि उनके आगे के सर्वरों को देरी हो रही है, तो w = 50 ms कहें। फिर हमें मिलता है:

 >>> max_request_rate(100, 0.1, 50) threaded: 2000 evented: 10000 

हमारी गणना से पता चलता है कि एक स्ट्रीमिंग सर्वर प्रति सेकंड 2,000 अनुरोधों को संसाधित करने में सक्षम होगा, और एक इवेंट सर्वर 10,000। इवेंट सर्वर का उच्च प्रदर्शन हमें बताता है कि स्ट्रीमिंग सर्वर के लिए थ्रेड्स की संख्या एक अड़चन बन गई।

एक अन्य उदाहरण एक वेब अनुप्रयोग सर्वर है। सबसे पहले, एक ऐसे आवेदन के मामले पर विचार करें जिसमें किसी भी बाहरी संसाधनों की आवश्यकता नहीं है, लेकिन कुछ गणना करता है। प्रसंस्करण समय होगा, कहते हैं 5 एमएस। क्योंकि कोई अवरोधक कॉल नहीं किया जाता है, समय w भी 5 एमएस होगा। तब:

 >>> max_request_rate(100, 5, 5) threaded: 200 evented: 200 

इस स्थिति में, CPU प्रदर्शन एक अड़चन बन गया।

अब कल्पना करें कि एप्लिकेशन को बाहरी संसाधन से डेटा का अनुरोध करने की आवश्यकता है और सीपीयू समय 0.5 एमएस होगा, और कुल समय डब्ल्यू = 100 एमएस।

 >>> max_request_rate(100, 0.5, 100) threaded: 1000 evented: 2000 

जैसा कि सरल गणना से देखा जा सकता है, और वास्तव में गणित से, एक तुल्यकालिक स्ट्रीमिंग कार्यान्वयन में अतुल्यकालिक घटना कार्यान्वयन से अधिक प्रदर्शन नहीं होगा।

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

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

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

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