प्रदर्शन - मल्टीथ्रेड या मल्टीप्रोसेस अनुप्रयोग

Question

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

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

धन्यवाद।

Answer 1

लिनक्स पर प्रक्रियाएं और धागे एक-दूसरे के समान हैं - मुख्य अंतर यह है कि संपूर्ण वर्चुअल मेमोरी साझा की जाती है और सिग्नल हैंडलिंग जैसी कुछ चीजें अलग-अलग होती हैं।

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

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

ऐसी स्थितियों में पेश आ रही समस्याओं के बारे में एक प्रसिद्ध writeup कि "C10k समस्या", http://www.kegel.com/c10k.html से उपलब्ध है - यह अलग आई/ओ दृष्टिकोण का वर्णन करता है, तो थोड़ा दिनांकित होने के बावजूद, यह एक बहुत अच्छा परिचय है।

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

Answer 2

यदि आपके धागे एक दूसरे से स्वतंत्र काम कर रहे हैं, लिनक्स के तहत, इसके बजाय कई प्रक्रियाओं के साथ नहीं जाने का कोई कारण नहीं है। कई प्रक्रियाएं आपके मेमोरी उपयोग को बढ़ाएंगी क्योंकि प्रत्येक प्रक्रिया में अपनी निजी मेमोरी स्पेस होती है, लेकिन दूसरी तरफ स्वतंत्र धागे के बीच मेमोरी स्पेस साझा करना बुरा निर्णय होता है। धागे बनाम प्रक्रियाओं के बीच संदर्भ स्विचिंग आमतौर पर धागे की बजाय प्रक्रियाओं के लिए बेहतर होती है हालांकि इसका थोड़ा सा आर्किटेक्चर और कोड निर्भर होता है। लॉक और म्यूटेक्स एसएस के साथ क्रमबद्ध नहीं होने के लिए प्रक्रियाएं सुरक्षित हैं। लिनक्स में प्रक्रियाओं का प्रबंधन और बातचीत करना आसान है। यहां एक अच्छा दस्तावेज़ है जो आपको दिलचस्प लगेगा (http://elinux.org/images/1/1c/Ben-Yossef-GoodBadUgly.pdf)।