मैं सॉकेट प्रोग्रामिंग में बहु-क्लाइंट सुविधा का समर्थन करने के लिए एकाधिक थ्रेड बना सकता हूं; यह ठीक काम कर रहा है। लेकिन अगर 10,000 ग्राहक कनेक्ट होना चाहते हैं, तो मेरा सर्वर इतने सारे धागे नहीं बना सकता है।जावा सॉकेट प्रोग्रामिंग 10,000 क्लाइंट्स के लिए काम नहीं करता
मैं धागे का प्रबंधन कैसे कर सकता हूं ताकि मैं इन सभी ग्राहकों को एक साथ सुन सकूं?
इसके अलावा, अगर इस मामले में सर्वर किसी विशेष ग्राहक को कुछ भेजना चाहता है, तो यह कैसे संभव है?
यह एक साधारण सवाल नहीं है, लेकिन एक के लिए बहुत गहराई में (क्षमा करें, जावा में नहीं है, हालांकि) जवाब यह देखें: http://www.kegel.com/c10k.html
संपादित
यहां तक कि NIO साथ, यह है अभी भी एक मुश्किल समस्या है। 10000 कनेक्शन मशीन पर एक जबरदस्त संसाधन बोझ है, भले ही आप गैर-अवरुद्ध सॉकेट का उपयोग कर रहे हों। यही कारण है कि बड़ी वेबसाइटों में सर्वर खेतों और लोड बैलेंसर्स हैं।
जावा में अत्यधिक स्केलेबल सॉकेट प्रोग्रामिंग को "नया I/O", या एनआईओ पैकेज में प्रदान किए गए selectable channels की आवश्यकता होती है। गैर-अवरुद्ध आईओ का उपयोग करके, एक धागा कई सॉकेट की सेवा कर सकता है, जो केवल उन सॉकेट को तैयार करता है जो तैयार हैं।
ग्लासफ़िश एप्लिकेशन सर्वर का Grizzly घटक अधिक स्केलेबल ओपन-सोर्स एनआईओ अनुप्रयोगों में से एक है। Jean-Francois Arcand ने परियोजना पर अपने काम के बारे में कई जानकारीपूर्ण, गहन ब्लॉग पोस्ट लिखे हैं, और एनआईओ के साथ इस तरह के सॉफ्टवेयर लिखने में कई सूक्ष्म नुकसान शामिल हैं।
यदि गैर-अवरुद्ध आईओ की अवधारणा आपके लिए नई है, तो मौजूदा सॉफ़्टवेयर का उपयोग करके ग्रिज़ली, या कम से कम इसे अपने अनुकूलन के लिए शुरुआती बिंदु के रूप में उपयोग करना, बहुत उपयोगी हो सकता है।
आपको गैर-अवरुद्ध नेटवर्क प्रोग्रामिंग के लिए जावा की एनआईओ ("नई आई/ओ") लाइब्रेरी की जांच करनी चाहिए। एनआईओ को ठीक सर्वर स्केलेबिलिटी समस्या का सामना करने के लिए डिज़ाइन किया गया था! NIO के बारे में
एक धागा प्रति कनेक्शन सूत्रण मॉडल (ब्लॉक कर रहा है सॉकेट आई/ओ) बहुत अच्छी तरह पैमाने पर नहीं होगा के कुछ अंशः। यहाँ जावा NIO एक परिचय जो आप जावा में गैर-अवरुद्ध सॉकेट कॉल का उपयोग करने की अनुमति देगा है: http://today.java.net/cs/user/print/a/350
लेख राज्यों के रूप में, वहाँ उपलब्ध ताकि आप अपने रोल करने की जरूरत नहीं है चौखटे के बहुत सारे हैं।
धन्यवाद पीटर, यह एक उपयोगी लिंक है।क्या आप इस तरह के लिंक के लिए मेरी मदद कर सकते हैं जहां मुझे अधिक जानकारी मिल सकती है। –
इस मॉडल के लिए जेडीके में नमूना कोड हैं। नोट: आप अपने सर्वर का समर्थन करने वाले उपयोगकर्ताओं की संख्या से अधिक नहीं हो सकते हैं। आपको अधिक सर्वर की आवश्यकता हो सकती है। –
आप एक समय में केवल कुछ निश्चित अनुरोधों को क्यों संसाधित नहीं करते हैं।
मान लीजिए कि आप (बहुत धागे बनाने नहीं करने के लिए) एक बार में 50 अनुरोधों की एक अधिकतम की प्रक्रिया
आप 50 धागे की एक ThreadPool बनाना चाहते हैं।
आप सभी अनुरोधों को एक कतार में डालते हैं (कनेक्शन स्वीकार करते हैं, सॉकेट खोलते हैं), और प्रत्येक थ्रेड, जब यह किया जाता है, तो अगला अनुरोध प्राप्त होता है और फिर इसे संसाधित करता है।
यह अधिक आसानी से स्केल करना चाहिए।
इसके अलावा, अगर जरूरत पड़ने पर, यह आसान लोड संतुलन करने के लिए किया जाएगा, जब से तुम कई सर्वरों
जैसा कि पहले उल्लेख किया गया था, 10.000 क्लाइंट आसान नहीं है। जावा के लिए, एनआईओ (संभावित रूप से एनआईओ थ्रेड को अवरुद्ध किए बिना प्रत्येक अनुरोध को संभालने के लिए एक अलग थ्रेडपूल के साथ बढ़ाया जाता है) बड़ी मात्रा में ग्राहकों को संभालने का सामान्य तरीका है।
जैसा कि बताया गया है, कार्यान्वयन के आधार पर, धागे वास्तव में स्केल हो सकते हैं, लेकिन यह क्लाइंट कनेक्शन के बीच कितनी बातचीत है इस पर निर्भर करता है। धागे के बीच थोड़ा सिंक्रनाइज़ेशन होने पर भारी धागे काम करने की अधिक संभावना रखते हैं।
उस ने कहा, एनआईओ पहली बार लागू होने पर 100% सही प्राप्त करना मुश्किल है।
मैं या तो कोशिश कर रहा हूं या कम से कम naga.googlecode.com पर नागा एनआईओ लिब के स्रोत को देख रहा हूं। Lib के लिए कोडबेस अधिकांश अन्य एनआईओ ढांचे की तुलना में छोटा है। यह देखने के लिए कि क्या आप 10.000 क्लाइंट्स को चला सकते हैं और चल सकते हैं, आपको टेस्ट को तुरंत कार्यान्वित करने में सक्षम होना चाहिए।
निजी तौर पर मैं नहीं बल्कि ग्राहकों को स्वीकार करने के लिए एक थ्रेड का उपयोग कर, एक कस्टम आई/ओ गैर अवरुद्ध सेट अप बनाने का प्रयोग करेंगे (उदाहरण के लिए नागा स्रोत भी मूल लेखक से श्रेय दिए बिना संशोधित करने या कॉपी करने के लिए मुक्त होने के लिए होता है) और उन्हें संसाधित करने के लिए एक अन्य थ्रेड का उपयोग करना (यदि कोई इनपुट उपलब्ध है या आउटपुट में डेटा लिखना आवश्यक है तो जांचना)।
आपको यह पता लगाना होगा कि आपका आवेदन 10,000 धागे पर क्यों विफल रहा है।
क्या JVM या OS में थ्रेड की संख्या की कोई कठोर सीमा है? यदि हां, तो इसे उठाया जा सकता है?
क्या आप स्मृति से बाहर हैं? प्रति थ्रेड के छोटे स्टैक आकार को कॉन्फ़िगर करने का प्रयास करें, और/या सर्वर पर और मेमोरी जोड़ें।
कुछ और? इसे ठीक करो।
केवल एक बार जब आप समस्या का स्रोत निर्धारित कर लेंगे तो आप इसे ठीक कर पाएंगे। सिद्धांत में 10,000 धागे ठीक होना चाहिए लेकिन समेकन के उस स्तर पर यदि आप इसे काम करना चाहते हैं तो उसे JVM और ऑपरेटिंग सिस्टम के कुछ अतिरिक्त ट्यूनिंग की आवश्यकता होती है।
आप एनआईओ पर भी विचार कर सकते हैं लेकिन मुझे लगता है कि यह थ्रेड के साथ भी ठीक काम कर सकता है।
मुझे आपकी टिप्पणियों को पचाने में कठिनाई होती है (10 के धागे ठीक होना चाहिए)? मैं आपको एक छोटा सा प्रोग्राम लिखने के लिए चुनौती देता हूं जो एक ही कार्य करता है। इसे अच्छी तरह से बेंचमार्क करें और उस नंबर को सुरक्षित रखें। फिर, 10 के धागे बनाएं और प्रत्येक थ्रेड में वही कार्य शुरू करें, जबकि यह बेंचमार्किंग भी करें। इससे कोई फर्क नहीं पड़ता कि आप किस ओएस का उपयोग करते हैं, आपके पास शायद थ्रेड-भुखमरी होगी! – Jeach
हाय जेच, यहां पर कार्य "आई/ओ के लिए प्रतीक्षा करें" है, कोई प्रसंस्करण नहीं किया जा रहा है। ओएस I/O की प्रतीक्षा कर रहे धागे पर कोई संदर्भ स्विचिंग नहीं करता है। ओएस उस ढेर के क्षेत्रों में भौतिक स्मृति आवंटित नहीं करता है जो उपयोग में नहीं हैं। –
यह पहले से ही उत्तर दिया गया है: http://stackoverflow.com/questions/592303/asynchronous-io-in-java – mparaz
नीचे कुछ महान एनआईओ गैर-अवरुद्ध सिफारिशें हैं लेकिन संक्षेप में, मुझे इसे स्पष्ट रूप से बताएं : जब आप कुछ ग्राहकों की अपेक्षा करते हैं, तो आप एक सॉकेट प्रति-थ्रेड जा सकते हैं। लेकिन जब आप 10 के ग्राहकों की अपेक्षा करते हैं, और मैं तर्क दूंगा (आई/ओ और सीपीयू लोड के आधार पर) कि यदि आप 100 से अधिक ग्राहकों की अपेक्षा करते हैं तो आपको एनआईओ वे (गैर-अवरुद्ध आईओ) जाना होगा। भले ही आपका ओएस प्रति सेकेंड 1000 बार प्रयास करता है, क्या आप 10 के ग्राहकों को संभालने का काम कल्पना कर सकते हैं? यह कई ग्राहकों के साथ अवरुद्ध सॉकेट के साथ जाने का कोई मतलब नहीं है! – Jeach