OpenVPN को कितने कोर चाहिए? यह मार्ग पर निर्भर करता है

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

नीचे दी गई तुलना इस बारे में है कि पैकेट कहाँ संसाधित होते हैं, इस बारे में नहीं कि कौन सा उत्पाद अमूर्त रूप से तेज़ है। ये अलग प्रश्न हैं जिनके अलग उत्तर हैं।

उपयोगकर्ता-स्थान मार्ग पर प्रति प्रवाह एक कोर

पारंपरिक Community OpenVPN इंस्टेंस में डेटा चैनल उपयोगकर्ता-स्थान में संसाधित होता है, और व्यस्त कनेक्शन एक प्रोसेसर को पकड़ सकता है जबकि मशीन का समग्र उपयोग सामान्य बना रहता है। इसीलिए जिस होस्ट पर पहले से एक प्रवाह संतृप्त है, उसमें कोर जोड़ने से कुछ नहीं बदलता: शेड्यूलर के पास उस काम को बाँटने का कोई तरीका नहीं है। प्रति-क्लाइंट संरचना एक क्लाइंट के स्थानांतरण को एक कोर की क्षमता तक सीमित करती है, कुल कोर संख्या जो भी हो। परीक्षण के दौरान समग्र आंकड़े के बजाय प्रति-कोर उपयोग पढ़ें, अन्यथा अड़चन अतिरिक्त क्षमता जैसी लगेगी।

एक होस्ट पर कई सर्वर इंस्टेंस चलाना अलग-अलग क्लाइंट को प्रक्रियाओं में बाँटता है। यह किसी मौजूदा कनेक्शन को समांतर नहीं करता, और अलग पूल, श्रोता तथा रूटिंग निर्णयों की लागत लेता है।

दूसरा मार्ग: कर्नेल में पैकेट

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

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

तुलना वास्तव में क्या तय करती है

असली चुनाव यह है कि प्रति-प्रवाह सीमा स्वीकार की जाए, क्लाइंट को इंस्टेंस में फैलाया जाए, या समर्थित ऑफलोड कॉन्फ़िगरेशन की ओर बढ़ा जाए। हर विकल्प अलग समस्या का समाधान करता है, और गलत चुनने पर संख्या हिलाए बिना पैसा खर्च होता है। महत्वपूर्ण परीक्षण वह है जो सेवा के उपयोग के तरीके जैसा गढ़ा गया हो।

तीन आकार मापें: एक स्थानांतरण वाला एक क्लाइंट, कई प्रवाह वाला एक क्लाइंट, और साथ में कई क्लाइंट। तीसरे में ऊँचा कुल यह साबित नहीं करता कि एक डाउनलोड उस तक पहुँच सकता है, और धीमा एकल स्थानांतरण यह साबित नहीं करता कि सर्वर की समग्र क्षमता समाप्त हो गई है। परिणाम अलग प्रश्नों के उत्तर देते हैं और दोनों रखने योग्य हैं।

केवल बीच का आकार बताता है कि एक क्लाइंट के भीतर की समवर्तिता सहायक है या नहीं, जो सामान्यतः सर्वर की नहीं बल्कि परिवहन और मार्ग की विशेषता है। केवल पहला वह सीमा बताता है जो एक अनुप्रयोग देखेगा। तुलना का अर्थ बना रहे इसके लिए रनों के बीच कार्यभार समान रखें।

मापें ताकि संख्या का अर्थ रहे

सर्वर और क्लाइंट के संस्करण, सक्रिय डेटा मार्ग, तय किया गया डेटा साइफ़र, स्थानांतरण की दिशा, पैकेट आकार, प्रवाह संख्या और अवधि दर्ज करें। प्रति-कोर गतिविधि तथा दोनों सिरों पर पैकेट और कतार ड्रॉप देखें, क्योंकि क्लाइंट का अपना इंटरफ़ेस, प्रदाता का नेटवर्क या गंतव्य सेवा पहले सीमा बन सकते हैं। एक समय में एक चर बदलें, क्योंकि साइफ़र, संपीड़न, MTU और ऑफलोड साथ बदलने वाला रन यह नहीं बता सकता कि कौन महत्वपूर्ण था। परीक्षण के दौरान वही प्रवेश नीति रखें जिसे आप वास्तव में लागू करना चाहते हैं, क्योंकि ऐसी प्रयोगशाला व्यवस्था जिसे कोई नहीं चलाएगा, बहुत कम साबित करती है।

फिर नियंत्रण चैनल, पुनः बातचीत और होस्ट पर चलने वाले बाकी सब के लिए जगह छोड़ें।

बताएं कि कॉन्फ़िगरेशन ने इच्छित समवर्तिता के अंतर्गत क्या बनाए रखा, किसी और के हार्डवेयर से अनुमानित दर के बजाय। परीक्षण की शर्तों के साथ दी गई संख्या उपयोगी है; उनके बिना किया गया वादा एक अनुमान है जो आपको बाद में उद्धृत किया जाएगा।