उपयोगकर्ता या थ्रूपुट? वास्तविक लोड के लिए VPN सर्वर का आकार तय करना

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

खातों की संख्या की तुलना व्यस्त घंटे से करें

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

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

पृष्ठभूमि लोड को अपनी अलग पंक्ति के रूप में जोड़ें: क्लाइंट अपडेट, टेलीमेट्री और फ़ॉरवर्डिंग के अलावा होस्ट जो कुछ करता है। इन बाइट्स को भूलना आसान है और उन्हें वही इंटरफ़ेस गिनता है।

वह संसाधन खोजें जो लिंक से पहले खत्म हो

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

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

फिर वैकल्पिक लोड रोककर दौड़ दोहराएँ। जो सीमा बैकअप रुकने पर खिसकती है, वह कभी गेटवे की सीमा नहीं थी।

तुलना को ऐसी संख्या में बदलें जिसका आप बचाव कर सकें

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

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

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

ऊपर की ओर बढ़ाने और भूमिका बाँटने के बीच चुनें

जब मापी गई सीमा एक कोर हो, तो उसी गति के अधिक कोर शायद मदद न करें; तेज़ कोर या अलग वर्कर मॉडल मदद कर सकता है। जब सीमा कुल CPU हो, तो बड़ा इंस्टेंस सीधा समाधान है। जब सीमा एक्सेस लिंक हो, तो कोई सर्वर परिवर्तन मदद नहीं करता और तुलना प्रदाता पर समाप्त होती है। वेब और VPN भूमिकाओं को अलग होस्ट पर बाँटना दूसरी प्रबंधन सतह की कीमत पर अलगाव खरीदता है।

उन विकल्पों की तुलना दर्ज संख्या से करें, एक-दूसरे से नहीं। जो परिवर्तन ऐसे संसाधन को दोगुना करता है जो बाधा नहीं था, वह लाभहीन लागत है, और रिकॉर्ड ही आपको यह बिना बहस कहने देता है। परिवर्तन के बाद उसी लोड के साथ फिर मापें, वरना आपने एक अनुमान को दूसरे से बदल दिया है।