बड़ी संख्या में फाइल डिस्क्रिप्टरों को सबसे प्रभावी ढंग से कैसे संभालें?

Question

ऐसे कार्यक्रमों के लिए कई विकल्प उपलब्ध हैं जो बड़ी संख्या में सॉकेट कनेक्शन (जैसे वेब सेवाएं, पी 2 पी सिस्टम इत्यादि) को संभालते हैं।

1. प्रत्येक सॉकेट के लिए I/O को संभालने के लिए एक अलग थ्रेड स्पॉन करें।
2. I12 को एक थ्रेड में मल्टीप्लेक्स करने के लिए select सिस्टम कॉल का उपयोग करें।
3. आई/ओ (चयन को प्रतिस्थापित करने) को मल्टीप्लेक्स करने के लिए poll सिस्टम कॉल का उपयोग करें।
4. उपयोगकर्ता/सिस्टम सीमाओं के माध्यम से सॉकेट एफडी को बार-बार भेजने से बचने के लिए epoll सिस्टम कॉल का उपयोग करें।
5. कई I/O धागे स्पॉन करें जो प्रत्येक एपीआईपीएल का उपयोग करके कनेक्शन की कुल संख्या का अपेक्षाकृत छोटा सेट मल्टीप्लेक्स करता है।
6. प्रत्येक स्वतंत्र I/O थ्रेड के लिए एक अलग एपोल ऑब्जेक्ट बनाने के लिए एपोल एपीआई का उपयोग करके # 5 के अनुसार।

एक मल्टीकोर सीपीयू पर मुझे उम्मीद है कि # 5 या # 6 का सर्वश्रेष्ठ प्रदर्शन होगा, लेकिन मेरे पास इसका समर्थन करने वाला कोई भी कठिन डेटा नहीं है। वेब पर खोज this पृष्ठ पर लेखक परीक्षण दृष्टिकोण # 2, # 3 और # 4 के अनुभवों का वर्णन करने वाला पृष्ठ बदल गया। दुर्भाग्य से यह वेब पेज लगभग 7 साल पुराना प्रतीत होता है, जिसमें कोई स्पष्ट हालिया अपडेट नहीं मिलते हैं।

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

Answer 1

मैं epoll() बड़े पैमाने पर उपयोग करता हूं, और यह अच्छी तरह से प्रदर्शन करता है। मैं नियमित रूप से हजारों सॉकेट सक्रिय करता हूं, और 131,072 सॉकेट के साथ परीक्षण करता हूं। और एपोल() हमेशा इसे संभाल सकता है।

मैं एकाधिक धागे का उपयोग करता हूं, जिनमें से प्रत्येक सॉकेट के सबसेट पर मतदान करता है। यह कोड को जटिल बनाता है, लेकिन बहु-कोर CPUs का पूर्ण लाभ लेता है।

Answer 2

मेरे अनुभव से, आपके पास # 6 के साथ सबसे अच्छा perf होगा।

मैं आपको इन विवरणों में से कुछ को संक्षिप्त करने के साथ निपटने के लिए लिबरवेन्ट की भी सलाह देता हूं। कम से कम, आप उनके कुछ बेंचमार्क देख पाएंगे।

इसके अलावा, आप कितने सॉकेट के बारे में बात कर रहे हैं? जब तक आप कम से कम कुछ सौ सॉकेट प्राप्त नहीं करते हैं, तब तक आपका दृष्टिकोण शायद बहुत अधिक मायने रखता नहीं है।

Answer 3

बड़े आईआरसी सर्वर चलाने के साथ अपने अनुभव के साथ बोलते हुए, हम चुनिंदा() और मतदान() (क्योंकि एपोल()/kqueue() उपलब्ध नहीं थे)। लगभग 700 एक साथ ग्राहकों पर, सर्वर 100% CPU का उपयोग करेगा (आईआरसी सर्वर बहुप्रचारित नहीं था)। हालांकि, दिलचस्प बात यह है कि सर्वर अभी भी अच्छा प्रदर्शन करेगा। लगभग 4,000 ग्राहकों पर, सर्वर अंतराल शुरू हो जाएगा।

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

एपोल()/kqueue() पर जाने के लिए, इसी तरह की spec'd मशीनें 10,000 ग्राहकों के साथ मामूली रूप से सौदा करती हैं, कुछ (स्वीकार्य रूप से अधिक शक्तिशाली मशीनें, लेकिन अभी भी मशीनें जिन्हें आज के मानकों द्वारा छोटे माना जाएगा), 30,000 एक पसीना तोड़ने के बिना ग्राहकों।

एसआईजीआईओ के साथ मैंने जो प्रयोग देखा है, वह सुझाव देता है कि यह उन अनुप्रयोगों के लिए अच्छा काम करता है जहां विलंबता बेहद महत्वपूर्ण है, जहां केवल कुछ सक्रिय ग्राहक बहुत कम व्यक्तिगत काम कर रहे हैं।

मैं लगभग किसी भी स्थिति में चयन()/poll() पर epoll()/kqueue() का उपयोग करने की अनुशंसा करता हूं। मैंने धागे के बीच विभाजित ग्राहकों के साथ प्रयोग नहीं किया है। ईमानदार होने के लिए, मुझे कभी ऐसी सेवा नहीं मिली है जिसके लिए थ्रेड के साथ प्रयोग को न्यायसंगत बनाने के लिए फ्रंट एंड क्लाइंट प्रोसेसिंग पर अधिक अनुकूलन कार्य की आवश्यकता है।

Answer 4

मैंने पिछले 2 वर्षों में उस विशिष्ट मुद्दे पर काम किया है (जी-वैन वेब सर्वर के लिए, जो कई बेंचमार्क और चार्टों के साथ आता है)।

मॉडल जो लिनक्स के तहत सबसे अच्छा काम करता है वह एक घटना कतार (और, भारी प्रसंस्करण, कई कार्यकर्ता धागे) के साथ एपोल है।

यदि आपके पास कम प्रोसेसिंग (कम प्रोसेसिंग विलंबता) है तो एक थ्रेड का उपयोग करके कई थ्रेड का उपयोग करके तेज़ी से बढ़ेगी।

इसका कारण यह है कि एपोल बहु-कोर CPUs पर स्केल नहीं करता है (उसी उपयोगकर्ता-मोड एप्लिकेशन में कनेक्शन I/O के लिए कई समवर्ती एपॉल कतारों का उपयोग करके आपके सर्वर को धीमा कर देगा)।

मैं कर्नेल में एपोल के कोड पर गंभीरता से नहीं देखता था (मैं केवल अब तक उपयोगकर्ता मोड पर केंद्रित हूं) लेकिन मेरा अनुमान है कि कर्नेल में एपोल कार्यान्वयन ताले से अपंग है।

यही कारण है कि कई धागे का उपयोग दीवार को तुरंत हिट करते हैं।

यह कहने के बिना चला जाता है कि लिनक्स सबसे अच्छा प्रदर्शन कर्नेल में से एक के रूप में अपनी स्थिति रखना चाहता है तो ऐसी खराब स्थिति नहीं रहनी चाहिए।