मैं जावा के लिए काफी नया हूं और मेरा अनुभव वेब कंटेनर (मेरे मामले में Jboss) पर चलने वाले वेब आधारित अनुप्रयोगों तक सीमित है।
क्या मैं यह कहने में सही हूं कि वेब एप्लिकेशन के लिए वेब कंटेनर मल्टी-थ्रेडिंग का ध्यान रखता है? यदि हां, तो क्या मैं एक वेब आधारित अनुप्रयोगों में नए धागे पेश कर सकता हूं? क्या ऐसा करने में कोई फायदा है और किस परिदृश्य में ऐसा करने की आवश्यकता होगी?
जवाबों:
क्या मैं यह कहने में सही हूं कि वेब एप्लिकेशन के लिए वेब कंटेनर मल्टी-थ्रेडिंग का ध्यान रखता है?
अधिकांश वेबसर्वर (जावा और अन्यथा, JBoss सहित) "एक अनुरोध प्रति एक धागा" मॉडल का पालन करते हैं, अर्थात प्रत्येक HTTP अनुरोध पूरी तरह से एक धागा द्वारा संसाधित होता है। यह धागा अक्सर DB अनुरोध जैसी चीजों के इंतजार में ज्यादातर समय बिताएगा। वेब कंटेनर आवश्यकतानुसार नए थ्रेड बनाएगा।
कुछ सर्वर (जावा इकोसिस्टम में मुख्य रूप से नेट्टी ) असिंक्रोनस रिक्वेस्ट हैंडलिंग करते हैं, या तो "एक धागा सब कुछ करता है" मॉडल, या कुछ और जटिल। मूल विचार यह है कि बहुत सारे प्रतीक्षित धागे संसाधनों को बर्बाद करते हैं, इसलिए अतुल्यकालिक रूप से काम करना अधिक कुशल हो सकता है।
यदि हां, तो क्या मैं एक वेब आधारित अनुप्रयोगों में नए धागे पेश कर सकता हूं?
यह संभव है, लेकिन बहुत सावधानी से किया जाना चाहिए, क्योंकि त्रुटियां (जैसे मेमोरी लीक या लापता सिंक्रनाइज़ेशन) उन बगों का कारण बन सकती हैं जो पुन: पेश करने में बहुत कठिन हैं, या पूरे सर्वर को नीचे लाते हैं।
क्या ऐसा करने में कोई फायदा है और किस परिदृश्य में ऐसा करने की आवश्यकता होगी?
ठीक है, लाभ यह है कि आप सामानांतर में कर सकते हैं। शुद्ध कम्प्यूटेशनल गति में सुधार के लिए थ्रेड्स का उपयोग करना ऐसा कुछ है जो आपको वेबसर्वर पर नहीं करना चाहिए , क्योंकि यह अन्य अनुरोधों की हैंडलिंग को धीमा कर देगा। इस तरह की बात एक अलग सर्वर पर की जानी चाहिए, शायद किसी प्रकार की नौकरी कतार का उपयोग करके।
एक HTTP अनुरोध को संभालने के संदर्भ में मल्टीथ्रेडिंग के लिए एक वैध परिदृश्य हो सकता है यदि आपको अन्य नेटवर्क संसाधनों तक पहुंचने की आवश्यकता है, जैसे कि कई अन्य वेब सेवाओं को कॉल करें। यदि आप इसे एक ही थ्रेड में करते हैं, तो आपको बारी-बारी से प्रत्येक कॉल के समाप्त होने का इंतजार करना होगा। लेकिन यदि आप कई थ्रेड का उपयोग करते हैं, तो कुल प्रतीक्षा समय केवल सबसे धीमी कॉल की देरी है।
आपके सवाल के जवाब में:
जावा आधारित वेब एप्लीकेशन बनाम स्टैंड-अलोन जावा एप्लीकेशन में मल्टी-थ्रेडिंग अलग कैसे है
यह अलग नहीं है। आमतौर पर सॉफ्टवेयर वेब अनुप्रयोगों का निर्माण किया जाता है जो प्रत्येक नए अनुरोध को एक थ्रेड बनाकर पहले से ही कुछ मल्टी-थ्रेडिंग प्रदान करेगा। जैसे आप किसी अन्य एप्लिकेशन को उपयोग कर सकते हैं वैसे ही आप थ्रेड का उपयोग / निर्माण कर सकते हैं।
यदि आप इसे सही उपयोग करते हैं तो वास्तव में मल्टी-थ्रेडिंग आपको कठोर प्रदर्शन बढ़ा सकती है। I / O सघन कार्यों के लिए जैसे नेटवर्क पहुंच और डिस्क ड्राइव पहुंच प्रदर्शन वृद्धि लगभग हमेशा गारंटी है। कम्प्यूटेशनल रूप से गहन कार्यों के लिए आपको सर्वर में एक थ्रेड प्रति कोर के नियम से चिपकना चाहिए। उदाहरण के लिए यदि आपके कोर में i7 प्रोसेसर है तो आपको कम्प्यूटेशनल कार्यों को करने के लिए 7 थ्रेड्स से चिपके रहना चाहिए।
आपके सवाल के जवाब में:
क्या ऐसा करने में कोई फायदा है और किस परिदृश्य में ऐसा करने की आवश्यकता होगी?
माइकल बोर्गवर्ट का कहना है कि कम्प्यूटेशनल गति में सुधार के लिए आपको ऐसा नहीं करना चाहिए। मैं असहमत हूं, क्योंकि यह आलेख बताता है कि जब उपयोगकर्ता कम्प्यूटेशनल रूप से भारी कार्य करने की आवश्यकता होती है तो मल्टी-थ्रेडिंग जवाबदेही प्रदान करने में मदद कर सकता है। सादे अंग्रेजी में, उपयोगकर्ताओं को बहु-थ्रेडिंग के साथ कम्प्यूटेशनल रूप से भारी कार्यों को पूरा करने के लिए लंबे समय तक इंतजार नहीं करना पड़ता है।
यदि आप थ्रेड्स का उपयोग करने का इरादा रखते हैं, तो मेरा सुझाव है कि थ्रेड पूल का उपयोग करें। यह धागे बनाने के ओवरहेड को कम करेगा।
वैसे यह एक अच्छा सवाल है और मुझे लगता है कि वेब अनुप्रयोग विकास में काम करने वाले अधिकांश डेवलपर्स स्पष्ट रूप से मल्टीथ्रेडिंग का उपयोग नहीं करते हैं। कारण काफी स्पष्ट है क्योंकि आप अपने एप्लिकेशन को लागू करने के लिए एप्लिकेशन सर्वर का उपयोग कर रहे हैं, एप्लिकेशन सर्वर आंतरिक रूप से आने वाले अनुरोधों के लिए थ्रेड पूल का प्रबंधन करता है।
फिर स्पष्ट रूप से मल्टीथ्रेडिंग का उपयोग क्यों करें? एक वेब एप्लिकेशन डेवलपर को मल्टीथ्रेडिंग के लिए खुद को उजागर करने की क्या आवश्यकता है?
जब आप बड़े पैमाने पर एप्लिकेशन पर काम करते हैं, जहां आपको कई अनुरोधों को सर्वर से करना होता है, तो हर तरह के अनुरोध को सिंक्रोनाइज़ करना मुश्किल होता है क्योंकि विशेष प्रकार का अनुरोध बहुत अधिक प्रोसेसिंग कर सकता था जो आपके एप्लिकेशन के प्रदर्शन को नीचे ला सकता था।
चलो एक उदाहरण लेते हैं जहां एक विशेष प्रकार के अनुरोध की सेवा के बाद एक वेब एप्लिकेशन को उपयोगकर्ताओं को ईमेल और एसएमएस के माध्यम से सूचित करना पड़ता है। अनुरोध थ्रेड के साथ इसे सिंक्रोनाइज़ करने से आपके वेब एप्लिकेशन का प्रदर्शन नीचे आ सकता है। तो यहाँ उत्परिवर्तन की भूमिका आती है। ऐसे मामलों में नेटवर्क पर एक अकेले मल्टीथ्रेडेड एप्लिकेशन विकसित करना उचित है, जो केवल ईमेल और एसएमएस भेजने के लिए जिम्मेदार है।
Concurrency Utilities।