वापरकर्ते की थ्रूपुट? वास्तविक लोडसाठी VPN सर्व्हरचे मापन

दहा निष्क्रिय खाती टनेल भरणाऱ्या एका रात्रीच्या बॅकअपपेक्षा कमी खर्चिक आहेत, आणि वापरकर्त्यांची संख्या हा फरक दाखवू शकत नाही. VPN सर्व्हरचे मापन दोन संख्यांची तुलना आहे: तुम्ही प्रत्यक्षात वाहून नेणारी समवर्तीता आणि प्रथम संपणारे साधन. बहुतेक क्षमता-चुका पहिली संख्या निवडून दुसरी कधीही न मोजण्यातून येतात. दोन्ही याच क्रमाने करा, मग हार्डवेअरचा निर्णय अंदाज राहणार नाही.

खात्यांची संख्या व्यस्त तासाशी तुलना करा

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

दिशा ठरवते कोणती लिंक महत्त्वाची आहे. घरची अपलिंक क्वचितच सममितीय असते, आणि दिवसभर डाउनलोड करणारी शाखा गेटवे घाम गाळण्यापूर्वीच आपल्या खालच्या मर्यादेपर्यंत पोहोचते. प्रत्येक बाबीजवळ दिशा आणि टनेलचा व्याप्ती लिहा, कारण केवळ खाजगी गंतव्ये वाहणारे गेटवे आणि संपूर्ण इंटरनेट रहदारी वाहणारे गेटवे हे दोन वेगळे मापन-प्रश्न आहेत.

पार्श्वभूमी भार स्वतंत्र रांग म्हणून जोडा: क्लायंट अद्ययावत, टेलिमेट्री आणि फॉरवर्डिंगशिवाय होस्ट जे काही करतो. हे बाइट विसरणे सोपे आहे आणि तेच इंटरफेस ते मोजते.

लिंकपूर्वी संपणारे साधन शोधा

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

ज्या हस्तांतरणाला तुम्हाला परवानगी आहे त्याने मोजा, आणि समवर्ती काम एकाच वेळी नाही तर टप्प्याटप्प्याने जोडा. टिकाऊ दर आणि संवादात्मक प्रतिसाद एकत्र वाचा, कारण केवळ शिखर-दर चाचणी निरुपयोगी झालेले सत्र लपवते. जे गेटवे कॉल तुटत असताना आपला कमाल थ्रूपुट पार करते, ते चाचणीत उत्तीर्ण झाले नाही.

नंतर ऐच्छिक भार थांबवून तीच धाव पुन्हा करा. बॅकअप थांबल्यावर सरकणारी मर्यादा कधीच गेटवेची मर्यादा नव्हती.

तुलनेचे अशा संख्येत रूपांतर करा ज्याचा तुम्ही बचाव करू शकता

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

प्रति कोर वापरकर्त्यांचा आकडा या सरावातील सर्वात कमी हस्तांतरणीय संख्या आहे, कारण तो पुढील साइट सामायिक न करणारे प्रोटोकॉल मिश्रण आणि उपकरण प्रोफाइल गृहीत धरतो. मापन ठेवा आणि सूत्र सोडा. जेव्हा कोणी अधिक पन्नास वापरकर्त्यांसाठी क्षमता मागते, तेव्हा प्रामाणिक उत्तर त्या पन्नासचे व्यस्त-तास प्रोफाइल आहे, गुणाकार नाही.

थ्रूपुटसह प्रतिसाद वेळही नोंदवा. केवळ मोठ्या प्रमाणातील हस्तांतरण जपणारी क्षमता कॉलवर असलेल्या लोकांसाठी क्षमता नाही, आणि पुढील पुनरावलोकन या फरकाबद्दल विचारेल.

वरच्या दिशेने स्केल करणे आणि भूमिका विभाजित करणे यातून निवडा

जेव्हा मोजलेली मर्यादा एक कोर असेल, तेव्हा त्याच वेगाचे अधिक कोर मदत करतीलच असे नाही; वेगवान कोर किंवा वेगळे वर्कर मॉडेल मदत करू शकते. जेव्हा मर्यादा एकूण CPU असेल, तेव्हा मोठे इन्स्टन्स हा थेट उपाय आहे. जेव्हा मर्यादा प्रवेश लिंक असेल, तेव्हा कोणताही सर्व्हर बदल मदत करत नाही आणि तुलना पुरवठादाराकडे संपते. वेब आणि VPN भूमिका वेगळ्या होस्टवर विभाजित करणे दुसऱ्या व्यवस्थापन पृष्ठभागाच्या किंमतीत विलगीकरण विकत घेते.

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