प्रयोगकर्ता कि थ्रुपुट? वास्तविक लोडका लागि VPN सर्भरको आकार निर्धारण

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

खाताको संख्यालाई व्यस्त घण्टासँग तुलना गर्नुहोस्

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

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

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

लिङ्कभन्दा पहिले सकिने स्रोत खोज्नुहोस्

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

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

त्यसपछि वैकल्पिक भार रोकेर त्यही दौड दोहोर्याउनुहोस्। ब्याकअप रोकिँदा सर्ने सीमा कहिल्यै गेटवेको सीमा थिएन।

तुलनालाई तपाईंले बचाउन सक्ने संख्यामा बदल्नुहोस्

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

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

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

माथि स्केल गर्ने र भूमिका विभाजन गर्नेबीच छान्नुहोस्

जब नापिएको सीमा एउटा कोर हो, त्यही गतिका थप कोरले सहयोग नगर्न सक्छन्; छिटो कोर वा फरक वर्कर मोडेलले सक्छ। जब सीमा कुल CPU हो, ठूलो इन्स्ट्यान्स प्रत्यक्ष समाधान हो। जब सीमा पहुँच लिङ्क हो, कुनै सर्भर परिवर्तनले सहयोग गर्दैन र तुलना प्रदायकमै टुङ्गिन्छ। वेब र VPN भूमिका अलग होस्टमा विभाजन गर्दा दोस्रो व्यवस्थापन सतहको मूल्यमा अलगाव किनिन्छ।

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