നിങ്ങളുടെ ഡൗൺലോഡ് വേഗതയുള്ളതാണ്, എന്നിട്ടും ഓരോ ക്ലിക്കും സാവധാനം തോന്നുന്നത് എന്തുകൊണ്ട്?

വലിയ ഫയൽ വേഗത്തിൽ ഡൗൺലോഡ് ചെയ്ത ശേഷം ഓരോ ക്ലിക്കും സാവധാനമാണെന്ന് തോന്നുന്നത് വൈരുദ്ധ്യമല്ല. ശേഷി ഒരു സെക്കൻഡിൽ എത്ര നീങ്ങാം എന്ന് പറയുന്നു; റൗണ്ട്-ട്രിപ്പ് സമയം ഉപയോഗപ്രദമായ എന്തെങ്കിലും സംഭവിക്കുന്നതിന് മുൻപ് ഒരു കൈമാറ്റം എത്ര നേരം എടുക്കുന്നു എന്ന് പറയുന്നു. ആദ്യത്തേത് മെച്ചപ്പെടുത്തുന്നത് രണ്ടാമത്തേതിന് ഒന്നും ചെയ്യുന്നില്ല, രണ്ടാമത്തേതാണ് ഒരാൾ ടൈപ്പ് ചെയ്യുമ്പോഴും ക്ലിക്ക് ചെയ്യുമ്പോഴും സംസാരിക്കുമ്പോഴും ശ്രദ്ധിക്കുന്നത്. പരാതി അളക്കുക, കണക്ഷനല്ല.

വേഗമുള്ള ഫയൽ, സാവധാനത്തിലുള്ള ക്ലിക്ക്: രണ്ട് വ്യത്യസ്ത സംഖ്യകൾ

വലിയ തോതിലുള്ള കൈമാറ്റം ഡാറ്റയെ തുടർച്ചയായി ചലനത്തിൽ നിർത്തുന്നു, അതിനാൽ ഓരോ വ്യക്തിഗത അഭ്യർത്ഥനയും കാത്തിരിക്കുമ്പോഴും അത് ആരോഗ്യകരമായ നിരക്ക് റിപ്പോർട്ട് ചെയ്യാം. പല ബെഞ്ച്മാർക്കുകളും ഒരേ സമയം നിരവധി കണക്ഷനുകൾ തുറക്കുന്നു, ഇത് ഒരു അഭ്യർത്ഥന സാവധാനത്തിൽ തുടരുമ്പോഴും മൊത്ത സംഖ്യ ഉയർത്തുന്നു. രണ്ട് ഫലങ്ങളും പൊരുത്തപ്പെടുന്നു, കാലതാമസത്തെക്കുറിച്ച് പരാതിപ്പെടുന്ന ഉപയോക്താവിന് ഉയർന്ന സംഖ്യ ഉദ്ധരിക്കുന്നതാണ് വിശ്വാസം നഷ്ടപ്പെടുന്ന വഴി.

ഒരു പേജ് ലോഡ് ചെയ്യുന്നത് ചെറിയ കൈമാറ്റങ്ങളുടെ ശൃംഖലയാണ്: പേര് പരിഹരിക്കൽ, കണക്ഷൻ സ്ഥാപിക്കൽ, ഒരു അഭ്യർത്ഥന, ഒരു പ്രതികരണം, തുടർന്ന് ആശ്രിത അഭ്യർത്ഥനകൾ. ഓരോ ഘട്ടവും റൗണ്ട്-ട്രിപ്പ് വീണ്ടും നൽകുന്നു, അതിനാൽ കൂടുതൽ കാലതാമസമുള്ള വഴി ധാരാളം ശേഷിയുണ്ടെങ്കിലും സാവധാനമായി തോന്നുന്നു.

ടണൽ അതിന്റെ സ്വന്തം യാത്രയും പ്രോസസ്സിംഗും ചേർക്കുന്നു, മാപ്പിലെ ലേബലിനേക്കാൾ പാത പ്രധാനമാണ്. ഒരേ രാജ്യത്തെ രണ്ട് എഗ്രെസുകൾക്ക് ഒരു ലക്ഷ്യസ്ഥാനത്തേക്ക് വളരെ വ്യത്യസ്ത പാതകളാകാം. ഇരുപത് മില്ലിസെക്കൻഡ് വ്യത്യാസം ഒരു പേജിന്റെ അനുഭൂതി മാറ്റാൻ മതി, എന്നാൽ അത് ത്രൂപുട്ട് സംഖ്യയെ വളരെക്കുറച്ചേ ചലിപ്പിക്കൂ. അതുകൊണ്ട് എഗ്രെസ് തിരഞ്ഞെടുപ്പ് പതാക ഐക്കണിനെക്കാൾ കാലതാമസ മാതൃക പിന്തുടരണം.

പരാതി അളക്കുക, കണക്ഷനല്ല

ഉപയോക്താവ് പറഞ്ഞ വാക്യത്തിന് യോജിക്കുന്ന അളവ് തിരഞ്ഞെടുക്കുക. സാവധാനമുള്ള ഡൗൺലോഡിന് ശരിയായ ദിശയിൽ സ്ഥിരമായ നിരക്ക് വേണം; വൈകുന്ന കോളിന് ആ ആപ്പിന്റെ സ്വന്തം സ്ഥിതിവിവരക്കണക്കുകൾ വേണം; സാവധാനം തുടങ്ങുന്ന പേജിന് പേര് പരിഹരിക്കലിന്റെയും സ്ഥാപിക്കലിന്റെയും സമയങ്ങൾ വേണം.

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

ആദ്യ കമാൻഡ് പ്രവചനാത്മകമായി പ്രതികരിക്കുന്ന ഹോസ്റ്റിലേക്ക് റൗണ്ട്-ട്രിപ്പ് മാതൃക നൽകുന്നു, രണ്ടാമത്തേത് ഒരു കണക്ഷനുള്ള ആദ്യ ബൈറ്റ് വരെയുള്ള സമയവും സ്ഥിരമായ നിരക്കും റിപ്പോർട്ട് ചെയ്യുന്നു, മൂന്നാമത്തേത് നാല് സമാന്തര സ്ട്രീമുകളുമായി മൊത്ത ത്രൂപുട്ട് അളക്കുന്നു. അവ ഒരേ ദിവസത്തിലെ ഒരേ സമയത്ത് ഒരേ ലക്ഷ്യസ്ഥാനത്തിനെതിരെ പ്രവർത്തിപ്പിക്കുക, കാരണം രാവിലത്തെ മാതൃകയെ വൈകുന്നേരത്തെ മാതൃകയുമായി താരതമ്യം ചെയ്യുന്നത് അളവല്ല, കഥയാണ് സൃഷ്ടിക്കുന്നത്.

എഗ്രെസുകൾ താരതമ്യം ചെയ്യുമ്പോൾ ലക്ഷ്യസ്ഥാനം സ്ഥിരമായി സൂക്ഷിക്കുക. സർവറും ടണലും ഒരുമിച്ച് മാറ്റുന്നത് ഒരു ചരത്തെ രണ്ടാക്കുന്നു, ഫലം ഏതാണ് പ്രധാനമായിരുന്നതെന്ന് പറയാനാവില്ല. ഓരോ എഗ്രെസും കുറഞ്ഞത് മൂന്ന് തവണ പ്രവർത്തിപ്പിക്കുക, കാരണം ഒരു മാതൃക പലപ്പോഴും റൂട്ടിംഗ് മാറ്റത്തിലോ ശബ്ദമുള്ള ഒരു മിനിറ്റിലോ വീഴുന്നു. ഏറ്റവും നല്ല കേസിനെക്കാൾ മീഡിയൻ ഉപയോഗപ്രദമാണ്.

ICMP യെ ഉത്തരമല്ല, സൂചനയായി കാണുക. പ്രതികരിക്കുന്ന ഹോസ്റ്റ് നിങ്ങളുടെ ആപ്പ് ഉപയോഗിക്കുന്ന പാതയിൽ നിന്ന് വ്യത്യസ്തമായ പാതയിൽ എക്കോ അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്തേക്കാം, ഒരു പ്രതികരണം നഷ്ടപ്പെട്ടത് ഓരോ ആപ്പും പാക്കറ്റുകൾ നഷ്ടപ്പെടുത്തുന്നു എന്നതിന് തെളിവല്ല.

ലോഡിന് കീഴിലുള്ള കാലതാമസം ഒരു ക്യൂ പ്രശ്നമാണ്

ആളുകളെ ഏറ്റവും കൂടുതൽ ആശയക്കുഴപ്പത്തിലാക്കുന്ന മാതൃക നിഷ്ക്രിയമായിരിക്കുമ്പോൾ നന്നായി തോന്നുകയും ബാക്കപ്പ് സമയത്ത് ഉപയോഗശൂന്യമാകുകയും ചെയ്യുന്ന കണക്ഷനാണ്. അത് ക്യൂവാണ്, ശേഷിയല്ല. നിറഞ്ഞ അപ്ലിങ്ക് മറ്റെല്ലാ പാക്കറ്റുകൾക്കും മുന്നിൽ ബഫർ നിർമ്മിക്കുന്നു, അതിനാൽ ഒരു കീ അമർത്തൽ അപ്ലോഡിന്റെ ഒരു ഭാഗത്തിന് പിന്നിൽ കാത്തിരിക്കുന്നു.

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

ആദ്യ കമാൻഡ് പശ്ചാത്തലത്തിൽ കാലതാമസ മാതൃകകൾ എടുക്കുന്നു, രണ്ടാമത്തേത് എതിർ ദിശ നിറയ്ക്കുന്നു. കൈമാറ്റത്തിനിടയിൽ ping സമയങ്ങൾ കുതിച്ചുയർന്ന് പിന്നീട് കരകയറുകയാണെങ്കിൽ, നിങ്ങൾ റൂട്ടിംഗ് തകരാർ കണ്ടെത്തിയതല്ല, bufferbloat പുനർനിർമ്മിച്ചതാണ്. പരിഹാരം സാധാരണയായി ഒരു ക്യൂ മാനേജ്മെന്റ് ക്രമീകരണം, കുറഞ്ഞ പശ്ചാത്തല നിരക്ക്, അല്ലെങ്കിൽ വലിയ കൈമാറ്റം ഇന്ററാക്ടീവ് പാതയിൽ നിന്ന് നീക്കുന്നതാണ്.

ഓപ്ഷണൽ പശ്ചാത്തല ട്രാഫിക് കുറയ്ക്കുന്നത് എഗ്രെസ് രാജ്യം മാറ്റുന്നതിനേക്കാൾ പലപ്പോഴും സഹായിക്കുന്നു. ഇത് വിലകുറഞ്ഞതും മടക്കാവുന്നതും ഒരു മിനിറ്റിൽ പരിശോധിക്കാവുന്നതുമാണ്. ക്യൂ കൈകാര്യം ചെയ്യാനാവില്ലെങ്കിൽ വലിയ അപ്ലോഡുകൾ ജോലി സമയത്തിന് പുറത്ത് ഷെഡ്യൂൾ ചെയ്യുക, പകൽ ഓടേണ്ടതുണ്ടെങ്കിൽ അവയുടെ നിരക്ക് പരിമിതപ്പെടുത്തുക. റൗട്ടർ പിന്തുണയ്ക്കുന്നുവെങ്കിൽ ക്യൂ മാനേജ്മെന്റ് ക്രമീകരണമാണ് മികച്ച പരിഹാരം.

ഒരു കാര്യം മാറ്റി സമാനത്തെ സമാനവുമായി താരതമ്യം ചെയ്യുക

കൂടുതൽ നിഷ്ക്രിയ കാലതാമസത്തിന് ലക്ഷ്യസ്ഥാനം സ്ഥിരമായി വെച്ച് എഗ്രെസുകൾ താരതമ്യം ചെയ്യുക, തുടർന്ന് മികച്ച സ്ഥാനാർത്ഥിക്ക് പാതകൾ താരതമ്യം ചെയ്യുക. കുറഞ്ഞ സ്ഥിരമായ ത്രൂപുട്ടിന് പകരം ശേഷി, സർവർ ലോഡ്, ക്ലയന്റ് പ്രോസസ്സിംഗ് എന്നിവ നോക്കുക, കാരണം അവ വ്യത്യസ്ത പരിധികളാണ്.

നിങ്ങൾ എന്ത് അളന്നു, ഏത് ലക്ഷ്യസ്ഥാനത്തിനെതിരെ, ഏത് സമയത്ത്, ഏത് ക്രമീകരണങ്ങളോടെ എന്ന് എഴുതിവയ്ക്കുക. ആ നാല് വസ്തുതകളില്ലാതെ താരതമ്യം ആവർത്തിക്കാനാവില്ല, അടുത്ത വ്യക്തി പൂജ്യത്തിൽ നിന്ന് തുടങ്ങും.

തുടർന്ന് ടിക്കറ്റിലെ അവകാശവാദവുമായി ഉപകരണം ചേർക്കുക. "ഇന്റർനെറ്റ് സാവധാനം" അളവല്ല; "ഈ ഹോസ്റ്റിലേക്ക് ആദ്യ ബൈറ്റിന് 900 ms എടുത്തു, അതേസമയം ത്രൂപുട്ട് നന്നായിരുന്നു" ഒരു അളവാണ്, അത് ശേഷിയിലേക്കല്ല, നേരിട്ട് കാലതാമസത്തിലേക്ക് ചൂണ്ടുന്നു.