കുറഞ്ഞ ലേറ്റൻസിയുള്ള പ്രോക്സിയിലും ഡൗൺലോഡ് മന്ദമാകുന്നതെന്തുകൊണ്ട്

ചെറിയ പേജ് വേഗത്തിൽ മടക്കിനൽകുന്ന പ്രോക്സിയും ഫയൽ ഡൗൺലോഡ് ചെയ്യുമ്പോൾ മന്ദമായിരിക്കാം. ആദ്യ അഭ്യർത്ഥന പ്രധാനമായും കണക്ഷൻ സ്ഥാപിക്കുന്നതിലെയും പ്രതികരണത്തിലെയും വൈകലാണ് കാണിക്കുന്നത്. വലിയ കൈമാറ്റം ആ പാതയ്ക്ക് തുടർച്ചയായി എത്ര ഡാറ്റ കൊണ്ടുപോകാനാകും എന്നതിനെയും ആശ്രയിക്കുന്നു.

ഏത് കണക്കാണ് നിങ്ങളുടെ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നത്?

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-ക്കും സ്വതന്ത്ര ത്രൂപുട്ട് അളവുകൾ നൽകുന്നില്ല. പ്രോട്ടോക്കോൾ അല്ലെങ്കിൽ രാജ്യ ഫിൽട്ടർ വേഗത്തിന്റെ റാങ്കിങ് അല്ല.