कम विलंब वाले प्रॉक्सी से भी डाउनलोड धीमा क्यों हो सकता है

छोटा पृष्ठ जल्दी लौटाने वाला प्रॉक्सी भी फ़ाइल डाउनलोड करते समय धीमा हो सकता है। पहला अनुरोध मुख्यतः कनेक्शन बनाने और प्रतिक्रिया मिलने का विलंब बताता है। बड़े ट्रांसफ़र में यह भी मायने रखता है कि रास्ता लगातार कितना डेटा ले जा सकता है।

कौन-सा आँकड़ा आपके सवाल का जवाब देता है?

ICMP ping अलग परीक्षण है। सर्वर की प्रॉक्सी सेवा अनुपलब्ध होने पर भी वह ping का जवाब दे सकता है, या प्रॉक्सी चलने पर भी ping रोक सकता है। प्रॉक्सी के पते तक आने-जाने का समय, प्रॉक्सी से आपके गंतव्य तक का कनेक्शन भी नहीं मापता।

वास्तविक ट्रांसफ़र मापें

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

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 30 --silent --show-error --output /dev/null --write-out 'status=%{http_code} bytes=%{size_download} average_Bps=%{speed_download} seconds=%{time_total}\n' https://example.com/test-file.bin

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

औसत गति वाले फ़ील्ड की इकाई बाइट प्रति सेकंड है। बिट प्रति सेकंड में विज्ञापित नेटवर्क प्लान अलग इकाई इस्तेमाल करता है। बाइट को मोटे तौर पर बिट में बदलने के लिए आठ से गुणा करें; पूरी तुलना में इकाई एक रखें।

तुलना की शर्तें समान रखें

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

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

कार्यभार के अनुसार चुनें

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

ProxyHub की प्रॉक्सी सूची प्रत्येक IP के लिए स्वतंत्र थ्रूपुट माप नहीं देती। प्रोटोकॉल या देश का फ़िल्टर गति की रैंकिंग नहीं है।