एउटै सुरुङमा दुई VPN गति परीक्षण किन मिल्दैनन्
नयाँ निकासले परीक्षण सर्भर फेर्छ, र ढिलो सुरुवातले नतिजा फेर्छ। गन्तव्य स्थिर गर्नुहोस्, स्ट्रिमको संख्या मिलाउनुहोस् र प्रोसेसरको खर्चलाई लिङ्कको क्षमताबाट अलग गर्नुहोस्।
दुई दौड, एउटा सुरुङ, र संख्याहरू तीन गुणा फरक छन्। तिनीहरूबीच सुरुङ बदलिएको छैन। बदलिएको कुरा मापन हो: तपाईंको देखिने स्थानका आधारमा सर्भर छान्ने परीक्षण साइट, नली एउटा ढिलो सुरुवातले भर्छ कि छवटाले भन्ने निर्धारण गर्ने स्ट्रिमको संख्या, र बाटो ठीकसँग प्रयोग हुनुअघि नै सकिने छोटो अवधि। गति परीक्षणहरू गलत छैनन्, तर ती मानिसहरूले तिनीहरूलाई सोध्ने प्रश्नभन्दा साँघुरो प्रश्नको जवाफ दिन्छन्।
नयाँ निकास ठेगानाले परीक्षणको गन्तव्य फेर्छ
अधिकांश परीक्षण साइटहरू स्वतः मापन सर्भर छान्छन्, र तपाईंको जडान कहाँबाट आएजस्तो देखिन्छ भन्ने हेरेर आंशिक रूपमा छान्छन्। सुरुङ खोल्नुहोस्, तपाईंको देखिने देश बदलिन्छ, त्यसैले छानिएको सर्भर बदलिन्छ, र तुलना अब दुई फरक होस्टतर्फ जाने दुई फरक बाटो समेट्छ।
नतिजा कुनै पनि हिसाबले VPN मापन होइन। यो तपाईंले नछान्नुभएको सर्भरसम्मको तपाईंको बाटोको मापन हो, र दुई दौडबीचको फरक सुरुङले गरेको कुनै कुराभन्दा त्यो सर्भरको पियरिङले निर्धारण गर्न सक्छ।
अरू केही बदल्नुअघि गन्तव्य स्थिर गर्नुहोस्। हरेक भरपर्दो उपकरणले तपाईंलाई स्पष्ट रूपमा सर्भर छान्न दिन्छ, र नदिएको खण्डमा नतिजा पृष्ठले सामान्यतया प्रयोग गरिएको सर्भरको नाम बताउँछ, जुन दुई दौड तुलनीय छैनन् भन्ने देख्न पर्याप्त छ। साइटले के देख्यो भन्ने कुरा उसको छनोटमा भरोसा गर्नुअघि पुष्टि गर्नुहोस्:
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'यदि दौडहरूबीच देश बदलियो भने परीक्षणले त्यसपछि छानेको सबै पनि बदलियो। हरेक नतिजाको छेउमा देखिएको निकास लेख्नुहोस् र अन्योल धेरै हदसम्म हराउँछ।
ढिलो सुरुवात अधिकांश छोटा परीक्षण सकिएपछि सकिन्छ
TCP जडान लिङ्कको गतिमा सुरु हुँदैन। यो सानो भिडको विन्डोबाट सुरु हुन्छ, लगभग हरेक राउन्ड ट्रिपमा त्यसलाई दोब्बर बनाउँछ, र धेरै राउन्ड ट्रिपपछि मात्र बाटोको क्षमतामा पुग्छ। उच्च लेटेन्सी भएको बाटोमा दस सेकेन्डको परीक्षणले आफ्नो जीवनको ठूलो हिस्सा त्यो चढाइमा बिताउन सक्छ।
त्यसैले बढी लेटेन्सी भएको सुरुङ छोटो परीक्षणमा योग्यभन्दा खराब अंक पाउँछ, र त्यसैले लामो दौडले कुनै पनि कन्फिगरेसन नबदली बढी संख्या जनाउँछ। RFC 6349 थ्रुपुट ढाँचा ले यसलाई स्पष्ट रूपमा सम्बोधन गर्छ, र त्यसैले गम्भीर मापनहरू स्थिर अवस्थामा पुग्न पर्याप्त लामो चल्छन्। स्याटेलाइट बाटोमा पाँच सेकेन्डको दौडले बाटो होइन, गतिवर्धक मापन गर्छ।
एउटै संख्यामा भरोसा गर्नुको सट्टा जडानका चरणहरू हेर्नुहोस्। Curl ले हरेक चरण अलग बताउँछ, त्यसैले समय हात मिलाउनमा जान्छ, चढाइमा कि स्थानान्तरणमा भन्ने देख्न सकिन्छ:
curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
https://mirror.example.net/testfile.binयसलाई उही गन्तव्यमा लगातार दुई पटक चलाउनुहोस्। यदि दोस्रो दौड धेरै छिटो छ भने तपाईं बाटो होइन, चढाइ मापन गर्दै हुनुहुन्थ्यो, र पहिलो मात्र प्रयोग गर्ने कुनै पनि तुलना शंकास्पद छ।
एउटा स्ट्रिम र छवटा स्ट्रिम फरक कुरा मापन गर्छन्
एउटा TCP स्ट्रिमले हावामा राख्न सक्ने विन्डोले सीमित हुन्छ, जुन लगभग राउन्ड ट्रिप समय गुणा दर हो। लामो बाटोमा त्यो गुणनफल एउटा स्ट्रिमले प्रयोग गर्नेभन्दा बढी हुन्छ, त्यसैले एउटा डाउनलोडले भएको क्षमता कम देखाउँछ। छवटा समानान्तर स्ट्रिमले त्यो खाली ठाउँ भर्छन् र ठूलो संख्या दिन्छन्।
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.netदुवै संख्या सत्य हुन्। एउटा स्ट्रिमको संख्याले एउटा डाउनलोडले के गर्छ भन्ने बताउँछ, जुन सामान्यतया ब्राउजर ट्याबले पाउँछ। समानान्तर संख्याले बाटोले कुल मिलाएर के बोक्न सक्छ भन्ने बताउँछ, जुन टोरेन्ट वा बहुभाग डाउनलोडले प्रयोग गर्न सक्छ। एउटालाई अर्को जस्तै उद्धृत गर्नु नै स्वस्थ सुरुङ बिनाकारण फेर्ने बाटो हो।
समानान्तर नतिजालाई एउटा स्ट्रिमको नतिजासँग तुलना गर्नु नै मानिसहरूले VPN ले आफ्नो गति आधा बनायो भन्ने निष्कर्षमा पुग्ने सबैभन्दा सामान्य बाटो हो। विधि मिलाउनुहोस्, त्यसपछि तुलना गर्नुहोस्। तेस्रो आदेशको ट्रेसले छुटेको सन्दर्भ थप्छ: बढी जिटर भएको बाटोले दुवै मोडमा अस्थिर नतिजा दिन्छ, र कुनै पनि स्ट्रिम संख्याले त्यो सुधार्दैन।
इन्क्रिप्शनले प्रोसेसरको समय लिन्छ, इन्क्याप्सुलेसनले बाइट लिन्छ
लिङ्क जति छिटो भए पनि हरेक प्याकेटमा दुई संयन्त्र चल्छन्। इन्क्रिप्शनले प्रति बाइट प्रोसेसर खर्च गर्छ, र इन्क्याप्सुलेसनले लिङ्कले अझै बोक्नुपर्ने हेडर बाइट थप्छ। दुवै सीमाका रूपमा देखिन्छन्, र तिनका लक्षण फरक छन्।
प्रोसेसरको सीमा पठारजस्तो देखिन्छ: तपाईं जति स्ट्रिम थप्नुभए पनि थ्रुपुट बढ्न छाड्छ, र लिङ्क खाली हुँदा मेसिनको प्रोसेसर व्यस्त हुन्छ। सानो राउटर वा फोनमा यही प्रायः वास्तविक सीमा हुन्छ, र त्यसैले छिटो लाइनले पनि साधारण सुरुङ दिन सक्छ।
बाइटको खर्च कम तर स्थिर हुन्छ। थप हेडरको अर्थ प्रति प्याकेट कम पेलोड हो, र निश्चित अधिकतम प्रसारण इकाइ भएको बाटोमा तिनले ठूला स्थानान्तरणमा ढिलो औसतको रूपमा होइन, रोकावटको रूपमा देखिने खण्डीकरण वा कालो प्वाल पनि निम्त्याउन सक्छन्।
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
यी तीन प्रायः मिसाइन्छन्, किनकि प्रयोगकर्ताहरूले सबैलाई «VPN ढिलो छ» भन्छन्। पहिलोले मात्र ठूलो मेसिनमा प्रतिक्रिया दिन्छ, दोस्रोले मात्र सानो MTU मा, र तेस्रोले मात्र पङ्क्ति व्यवस्थापनमा।
विधि अभिलेखमा लेख्नुहोस्
राख्न योग्य नतिजाले उपकरण, पहुँच सञ्जाल, निकास, मापन सर्भर, दिशा, स्ट्रिम संख्या र अवधिको नाम बताउँछ। ती बिना दुई संख्याको तुलना हुँदैन, र एउटा संख्या भएको टिकट वास्तवमा एउटा मनोस्थिति हो।
खराब दौडहरू पनि राख्नुहोस्। जुन शृंखलामा एउटा निकासले हरेक पटक रोकावट सिर्जना गर्छ त्यो औसतभन्दा धेरै जानकारीपूर्ण हुन्छ, र रोकावटहरू नै औसतले लुकाउने कुरा हुन्।
अनि तपाईंलाई साँच्चै महत्त्वपूर्ण कुरा परीक्षण गर्नुहोस्। लक्ष्य ठूलो डाउनलोड हो भने फाइल डाउनलोड गर्नुहोस्। लक्ष्य कल हो भने निष्क्रिय थ्रुपुट होइन, भारअन्तर्गत लेटेन्सी मापन गर्नुहोस्, किनकि सुरुङले गति परीक्षणमा राम्रो अंक ल्याउन सक्छ र तैपनि हरेक बैठक सुन्न नसकिने बनाउन सक्छ।