OpenVPN ला किती कोअर लागतात? ते मार्गावर अवलंबून असते

सारख्याच प्रोसेसर संख्येचे दोन सर्व्हर खूप वेगळा थ्रूपुट टिकवू शकतात, कारण महत्त्वाची संख्या म्हणजे सक्रिय डेटा मार्ग खरोखर किती कोअर वापरू शकतो ही आहे। एका क्लायंटचे पॅकेट प्रक्रिया करणारा एकच वापरकर्ता-जागेतील डीमन एका कोअरपुरता मर्यादित असतो, तर ऑफलोड केलेला कर्नेल मार्ग ते काम पसरवू शकतो। या दोन्ही विधानांपैकी कोणतेही ठराविक मशीन तुमच्या ट्रॅफिकसाठी काय करेल हे सांगत नाही, म्हणून कोअर मोजण्यापूर्वी मापन येते।

खालील तुलना पॅकेट कुठे प्रक्रिया होतात याबद्दल आहे, कोणते उत्पादन अमूर्तपणे वेगवान आहे याबद्दल नाही। हे वेगळ्या उत्तरांचे वेगळे प्रश्न आहेत।

वापरकर्ता-जागेच्या मार्गावर प्रति प्रवाह एक कोअर

पारंपरिक Community OpenVPN इन्स्टन्समध्ये डेटा चॅनेल वापरकर्ता-जागेत प्रक्रिया होते, आणि व्यस्त कनेक्शन एक प्रोसेसर व्यापू शकते, तर मशीनचा एकूण वापर लक्षात न येण्यासारखा राहतो। म्हणूनच एका प्रवाहावर आधीच संतृप्त असलेल्या होस्टवर कोअर जोडल्याने काहीही बदलत नाही: शेड्युलरकडे ते काम विभागण्याचा मार्ग नाही। प्रति-क्लायंट एक प्रक्रिया ही रचना एका क्लायंटचे हस्तांतरण एकूण कोअर संख्या कितीही असो एका कोअरच्या क्षमतेपर्यंत बांधते। चाचणीदरम्यान एकूण आकड्याऐवजी प्रति-कोअर वापर वाचा, अन्यथा अडथळा अतिरिक्त क्षमता वाटेल।

एका होस्टवर अनेक सर्व्हर इन्स्टन्स चालवल्यास वेगळे क्लायंट प्रक्रियांमध्ये विभागले जातात। ते विद्यमान कनेक्शन समांतर करत नाही, आणि वेगळे पूल, श्रोते व मार्गनिर्देशन निर्णय लागतात।

दुसरा मार्ग: कर्नेलमधील पॅकेट

डेटा चॅनेल ऑफलोड समर्थित पॅकेट प्रक्रिया आणि क्रिप्टोग्राफी कर्नेलमध्ये हलवते, जिथे काम अनेक कोअर वापरू शकते। यामुळे क्षमतेचा प्रश्न एका कोअरवरून मशीनकडे बदलतो, पण केवळ अशा कॉन्फिगरेशनसाठी ज्यांना अंमलबजावणी समर्थन देते: सुसंगत कर्नेल मॉड्यूल, पात्र डेटा सायफर आणि ऑफलोड जी वैशिष्ट्ये वगळतो ती नसलेले कॉन्फिगरेशन। मॉड्यूल इन्स्टॉल करणे हे ते वापरण्यासारखे नाही, म्हणून कनेक्शनच्या स्वतःच्या लॉगमधून किंवा स्थिती आउटपुटमधून सक्रिय मोडची खात्री करा। आवृत्ती बॅनर काय उपलब्ध आहे हे सिद्ध करतो, काय चालू आहे ते नाही।

ऑफलोड प्रमाणीकरण किंवा नियंत्रण चॅनेल काढून टाकत नाही, आणि प्रत्येक तैनातीला बहु-कोअर करत नाही। ते सुसंगत डेटा मार्गाचे स्थानिक प्रवेग आहे, आणि आवश्यकता प्लॅटफॉर्म व आवृत्तीनुसार बदलतात।

तुलना प्रत्यक्षात काय ठरवते

खरी निवड म्हणजे प्रति-प्रवाह मर्यादा स्वीकारणे, क्लायंट इन्स्टन्समध्ये पसरवणे, किंवा समर्थित ऑफलोड कॉन्फिगरेशनकडे जाणे यामधील आहे। प्रत्येक वेगळी समस्या सोडवते, आणि चुकीची निवड केल्यास आकडा न हलवता पैसा खर्च होतो। महत्त्वाची चाचणी म्हणजे सेवा कशी वापरली जाते त्या आकाराची चाचणी।

तीन आकार मोजा: एका हस्तांतरणासह एक क्लायंट, अनेक प्रवाहांसह एक क्लायंट, आणि एकत्र अनेक क्लायंट। तिसऱ्यातील उच्च बेरीज एका डाउनलोडला तिथपर्यंत पोहोचता येते हे सिद्ध करत नाही, आणि संथ एकल हस्तांतरण सर्व्हरची एकूण क्षमता संपली हे सिद्ध करत नाही। निकाल वेगळ्या प्रश्नांची उत्तरे देतात आणि दोन्ही ठेवण्यासारखे आहेत।

एका क्लायंटमधील समवर्तीता उपयोगी आहे का हे फक्त मधला आकार सांगतो, जी सामान्यतः सर्व्हरची नसून वाहतूक व मार्गाची वैशिष्ट्ये असते। एक अनुप्रयोग जी मर्यादा पाहील ते फक्त पहिला सांगतो। तुलना अर्थपूर्ण व्हावी म्हणून धावांमध्ये कामाचा भार समान ठेवा।

आकडा अर्थपूर्ण व्हावा म्हणून मापन

सर्व्हर व क्लायंटच्या आवृत्त्या, सक्रिय डेटा मार्ग, ठरलेला डेटा सायफर, हस्तांतरणाची दिशा, पॅकेट आकार, प्रवाह संख्या आणि कालावधी नोंदवा। प्रति-कोअर हालचाल आणि दोन्ही टोकांवरील पॅकेट व रांगा गमावणे पहा, कारण क्लायंटचा स्वतःचा इंटरफेस, पुरवठादाराचे नेटवर्क किंवा गंतव्य सेवा आधी मर्यादा होऊ शकते। एका वेळी एक चल बदला, कारण सायफर, संक्षेपण, MTU आणि ऑफलोड एकत्र बदलणारी धाव कोणते महत्त्वाचे होते हे सांगू शकत नाही। चाचणीदरम्यान तुम्ही खरोखर लागू करू इच्छित असलेली प्रवेश धोरण ठेवा, कारण कोणीही चालवणार नाही अशी प्रयोगशाळा रचना फारसे सिद्ध करत नाही।

नंतर नियंत्रण चॅनेल, पुनर्वाटाघाटी आणि होस्टवर चालणाऱ्या बाकी सर्वांसाठी जागा ठेवा।

इच्छित समवर्तीतेखाली कॉन्फिगरेशनने काय टिकवले ते सांगा, दुसऱ्याच्या हार्डवेअरवरून अंदाजलेल्या दराऐवजी। चाचणीच्या अटींसह दिलेला आकडा उपयुक्त; त्या नसलेले वचन नंतर तुम्हाला उद्धृत केले जाईल असे गृहीतक।