OpenVPN लाई कतिओटा कोर चाहिन्छ? यो मार्गमा निर्भर गर्दछ

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

तलको तुलना प्याकेट कहाँ प्रशोधन हुन्छन् भन्ने बारेमा हो, कुन उत्पादन अमूर्त रूपमा छिटो छ भन्ने बारेमा होइन। यी फरक प्रश्नहरू हुन् जसका फरक उत्तरहरू छन्।

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

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

एउटै होस्टमा धेरै सर्भर इन्स्टेन्स चलाउँदा छुट्टाछुट्टै ग्राहक प्रक्रियाहरूमा बाँडिन्छन्। यसले विद्यमान जडानलाई समानान्तर बनाउँदैन, र छुट्टै पूल, श्रोता तथा राउटिङ निर्णयहरू खर्च गर्छ।

अर्को मार्ग: कर्नेलमा प्याकेट

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

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

तुलनाले वास्तवमा के निर्णय गर्छ

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

तीन आकार नाप्नुहोस्: एउटा स्थानान्तरणसहित एक ग्राहक, धेरै प्रवाहसहित एक ग्राहक, र सँगै धेरै ग्राहक। तेस्रोमा उच्च जम्मा एउटा डाउनलोडले त्यहाँ पुग्न सक्छ भनी प्रमाणित गर्दैन, र ढिलो एकल स्थानान्तरणले सर्भरको समग्र क्षमता सकिएको प्रमाणित गर्दैन। नतिजाहरू फरक प्रश्नको उत्तर दिन्छन् र दुवै राख्न योग्य छन्।

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

अङ्कको अर्थ होस् भनेर मापन

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

त्यसपछि नियन्त्रण च्यानल, पुनर्वार्ता र होस्टमा चल्ने बाँकी सबैका लागि ठाउँ छोड्नुहोस्।

इच्छित समवर्तिता अन्तर्गत कन्फिगरेसनले के टिकाइरह्यो भनी रिपोर्ट गर्नुहोस्, अरू कसैको हार्डवेयरबाट अनुमान गरिएको दरको सट्टा। परीक्षणका सर्तसहित दिइएको अङ्क उपयोगी छ; ती बिनाको वाचा पछि तपाईंलाई उद्धृत गरिने अनुमान हो।