सी: एपोल और मल्टीथ्रेडिंग

Question

मुझे विशेष HTTP सर्वर बनाने की आवश्यकता है, इसके लिए मैं एपोल सिकॉल का उपयोग करने की योजना बना रहा हूं, लेकिन मैं एकाधिक प्रोसेसर/कोर का उपयोग करना चाहता हूं और मैं आर्किटेक्चर समाधान के साथ नहीं आ सकता। एटीएम मेरा विचार followng है: अपने एपोल डिस्क्रिप्टर के साथ कई धागे बनाएं, मुख्य धागा कनेक्शन स्वीकार करता है और उन्हें थ्रेड एपोल के बीच वितरित करता है। लेकिन क्या कोई बेहतर समाधान है? उच्च लोड आर्किटेक्चर पर मैं कौन सी किताबें/लेख/गाइड पढ़ सकता हूं? मैं केवल C10K लेख देखा है, लेकिन उदाहरण के लिए सबसे अधिक लिंक मृत इस विषय :(पर कोई में गहराई से किताबें हैं :(और अभी भी

जवाब के लिए धन्यवाद

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

Answer 1

जांच libevent और libev स्रोतों एक अच्छा बुनियादी सुविधाओं की जरूरत है। वे अत्यधिक पठनीय हैं, और पहले से ही उपयोग करें।

इसके अलावा, libev के दस्तावेज में कई कोशिश की और सच्ची रणनीतियों के कई उदाहरण हैं। भले ही आप सीधे epoll() पर लिखना पसंद करते हैं, उदाहरण कई अंतर्दृष्टि का कारण बन सकते हैं।

Answer 2

..my विचार followng है: वर्णनकर्ता खुद epoll साथ एक से अधिक थ्रेड बनाने के लिए, मुख्य थ्रेड कनेक्शन स्वीकार करता है और धागे epoll के बीच उन्हें वितरित करता है।

हां वर्तमान में ऐसा करने का सबसे अच्छा तरीका है और यह है कि निगेंक्स यह कैसे करता है। लोड और/या मशीन पर भौतिक कोर की संख्या के आधार पर धागे की संख्या में वृद्धि या कमी की जा सकती है।

अतिरिक्त धागे (भौतिक कोर की संख्या से अधिक) और घटनाओं के बीच व्यापार-विराम विलंबता और थ्रूपुट में से एक है। थ्रेड विलंबता में सुधार करते हैं क्योंकि वे संदर्भ स्विचिंग और थ्रेड सृजन/हटाना द्वारा किए गए ओवरहेड के कारण पूर्व-निष्पादित रूप से निष्पादित कर सकते हैं लेकिन थ्रूपुट की कीमत पर। घटनाक्रम थ्रूपुट में सुधार करते हैं लेकिन नुकसान होता है कि लंबे समय से चलने वाले कोड पूरे थ्रेड को रोकते हैं।

दूसरा सबसे अच्छा यह है कि Apache2 थ्रेड को अवरुद्ध करने के थ्रेड पूल का उपयोग करके कैसे करता है। यहां कोई इवेंट प्रोसेसिंग नहीं है इसलिए कार्यान्वयन आसान है और पूल का मतलब है कि धागे अनावश्यक रूप से बनाए और नष्ट नहीं होते हैं, लेकिन यह वास्तव में एक अच्छी तरह से लागू थ्रेड/एसिंक्रोनस हाइब्रिड के साथ प्रतिस्पर्धा नहीं कर सकता है जैसे आप कार्यान्वित करने की कोशिश कर रहे हैं या Nginx।

तीसरा सबसे अच्छा लाइटटैड या नोड.जे.एस. जैसे अकेले असीमित घटना प्रसंस्करण है। ठीक है, अगर आप सर्वर में भारी प्रसंस्करण नहीं कर रहे हैं तो यह दूसरा सबसे अच्छा है। लेकिन जैसा कि पहले उल्लेख किया गया है, लूप एक पूरे लंबे समय तक चल रहा है जबकि लूप पूरे सर्वर को अवरुद्ध करता है।

Answer 3

जब तक आपके पास एक टेराबिट अपलिंक नहीं है और एक सर्वर से 10000 एक साथ कनेक्शन की सेवा करने की योजना है, तो epoll भूल जाएं। यह सिर्फ अनावश्यक गैर पोर्टेबिलिटी है; poll या यहां तक ​​कि select भी वही करेगा। ध्यान रखें कि उस समय तक टेराबिट अपलिंक और मानक हैं, आपका सर्वर भी तेज़ होगा कि आपको अभी भी epoll की आवश्यकता नहीं होगी।

यदि आप केवल स्थिर सामग्री की सेवा कर रहे हैं, तो थ्रेड के बारे में भी भूल जाएं और लिनक्स sendfile syscall का उपयोग करें। यह भी गैर मानक है, लेकिन कम से कम यह वास्तविक वास्तविक दुनिया के प्रदर्शन लाभ प्रदान करता है।

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