VPN വഴിയുള്ള ഫയൽ പങ്കിടൽ മന്ദഗതിയിൽ തോന്നുന്നത് എന്തുകൊണ്ട്: റൗണ്ട് ട്രിപ്പുകൾ, Mbps അല്ല

VPN വഴി പങ്കിട്ട ഫോൾഡർ തുറന്ന് ഡയറക്ടറി ലിസ്റ്റ് ഇഴഞ്ഞ് നീങ്ങുന്നതുവരെ കാത്തിരിക്കുന്നത് പരിചിതമായ അനുഭവമാണ്, ആദ്യ പ്രവണത ബാൻഡ്വിഡ്ത്തിനെ കുറ്റപ്പെടുത്തുകയാണ്. സാധാരണയായി ലിങ്ക് മിക്കവാറും നിഷ്ക്രിയമാണ്. പ്രോട്ടോക്കോൾ അതിന്റെ സമയം മറുപടികൾക്കായി കാത്തിരിക്കുന്നതിൽ ചെലവഴിക്കുന്നു, ഓരോ കാത്തിരിപ്പിനും LAN ഒരിക്കലും കണക്കാക്കാത്ത ഒരു പൂർണ റൗണ്ട് ട്രിപ്പ് ചെലവാകുന്നു. ജോലിയുടെ രൂപം തിരുത്തുക, പങ്കിടൽ വീണ്ടും ഉപയോഗയോഗ്യമാകും.

വിദൂര പ്രവർത്തന പകർപ്പിന് തെറ്റായ രൂപമാണ്

SMB ഫയലുകൾ തുറക്കുന്നു, മെറ്റാഡാറ്റ വായിക്കുന്നു, നിരവധി ചെറിയ കൈമാറ്റങ്ങളിൽ സ്ഥിരീകരിക്കുന്നു. മാപ്പ് ചെയ്ത ഡ്രൈവിലെ പതിപ്പ് നിയന്ത്രണ പ്രവർത്തന പകർപ്പ് പ്രാദേശിക ഫയൽസിസ്റ്റം കാലതാമസം അനുമാനിക്കുകയും നിരവധി ചെറിയ ഫയലുകൾ വായിക്കുകയും ചെയ്യുന്നു. ഡെസ്ക്ടോപ്പ് ഡാറ്റാബേസ് ഉപയോക്താവ് ജോലി ചെയ്യുമ്പോൾ പേജുകൾ വലിക്കുന്നു. ഇവയോരോന്നും കാലതാമസത്തെ ഗുണിതമാക്കുന്നു, കാരണം പ്രവർത്തനം നടത്തുന്ന കൈമാറ്റങ്ങളുടെ എണ്ണത്തിനൊപ്പം ചെലവ് വളരുന്നു; അതിനാൽ 40 ms ടണൽ നൂറുകണക്കിന് പ്രവർത്തനങ്ങളെ ഏതാനും സെക്കൻഡുകളാക്കുന്നു. ആ ഗണിതത്തിൽ പേലോഡിന്റെ വലിപ്പം മിക്കവാറും അപ്രസക്തമാണ്.

എൻക്രിപ്ഷൻ ഓവർഹെഡ് അതിന്റെ ചെറിയ ഭാഗമാണ്; നഷ്ടം കൂടുതൽ മോശമാണ്, കാരണം ഒരു പുനഃസംപ്രേഷണവും തകർന്ന കൺജഷൻ വിൻഡോയും ബന്ധപ്പെട്ട ബൈറ്റുകളേക്കാൾ വളരെ ചെലവേറിയതാണ്.

മെഗാബൈറ്റുകൾക്ക് മുൻപ് റൗണ്ട് ട്രിപ്പുകൾ എണ്ണുക

ശേഷി വാങ്ങുന്നതിന് മുൻപ് കാലതാമസം അളക്കുക. ഒരു ping ഓരോ കൈമാറ്റവും എന്ത് നൽകുന്നു എന്ന് പറയും.

ping -c 10 fileserver.example.net

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

ജോലി നീക്കുക, ബൈറ്റുകളല്ല

കൂടുതൽ വീതിയുള്ള പൈപ്പിന് പണം നൽകുന്നതിനുപകരം ജോലി എവിടെ നടക്കുന്നു എന്ന് മാറ്റുക. റിപ്പോസിറ്ററി മൗണ്ട് ചെയ്യുന്നതിനുപകരം സേവിക്കുക, വ്യത്യാസങ്ങൾ മാത്രം അയക്കുന്ന ഉപകരണം ഉപയോഗിച്ച് കൂട്ടമായി പകർത്തുക.

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

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

ഒരേ വലിപ്പത്തിന് സമീപം തടയുന്നത് MTU ലക്ഷണമാണ്

ping ഉം ചെറിയ പേജുകളും പ്രവർത്തിക്കുമ്പോൾ ഏകദേശം ഒരേ ഡാറ്റയ്ക്ക് ശേഷം നിലയ്ക്കുന്ന വലിയ കൈമാറ്റങ്ങൾ ബാൻഡ്വിഡ്ത്തിനെയല്ല, പാക്കറ്റ് വലിപ്പത്തെയാണ് സൂചിപ്പിക്കുന്നത്.

ping -M do -s 1400 -c 3 fileserver.example.net

വിജയകരമായ പരിശോധന എന്നാൽ 1428 ബൈറ്റ് IP പാക്കറ്റ് വിഭജനമില്ലാതെ വഴി കടക്കുന്നു, കാരണം ICMP, IP ഹെഡറുകൾ 28 ബൈറ്റ് ചേർക്കുന്നു. വിഭജനം വിലക്കുന്ന ഫ്ലാഗോടെ പരാജയം എന്നാൽ ടണലിന്റെ ഉപയോഗയോഗ്യമായ MTU സെർവർ അനുമാനിക്കുന്നതിനേക്കാൾ ചെറുതാണ്. 9000 ബൈറ്റ് ബഫറുകൾ 1500 ബൈറ്റ് വഴിയിലേക്ക് അയക്കുന്ന സെർവർ വിഭജനമോ നഷ്ടമോ നിർബന്ധിക്കുന്നു, ICMP ഫിൽട്ടർ ചെയ്യുമ്പോൾ വഴി MTU കണ്ടെത്തൽ നിശബ്ദമായി പരാജയപ്പെടാം. ടണലിന്റെ MTU കുറയ്ക്കുക, പ്രവർത്തനക്ഷമമാക്കുക mssfix OpenVPN ൽ, അല്ലെങ്കിൽ സെർവറിന്റെ ബഫറുകൾ ചെറുതാക്കുക, പിന്നീട് സ്ഥിരീകരിക്കാൻ അതേ കൈമാറ്റം വീണ്ടും പ്രവർത്തിപ്പിക്കുക.

പ്രധാനമായ വിടവ് അളക്കുക

നയം അനുവദിക്കുന്നിടത്ത് അതേ പ്രവർത്തനം മൂന്ന് വഴികളിൽ നടത്തുക: പ്രാദേശികമായി, ടണൽ വഴി, നേരിട്ടുള്ള ഇന്റർനെറ്റ് വഴി. ഓരോന്നിനും റൗണ്ട്-ട്രിപ്പ് സമയം, ഒരു വലിയ സ്ട്രീമിന്റെ വേഗത, ഡയറക്ടറി ലിസ്റ്റ് അല്ലെങ്കിൽ ആപ്പ് തുറക്കാൻ എത്ര സമയമെടുക്കുന്നു എന്നിവ രേഖപ്പെടുത്തുക. പ്രാദേശിക പ്രവർത്തനത്തെ ടണൽ പ്രവർത്തനവുമായി താരതമ്യം ചെയ്യുന്നത് ഏത് ചെലവ് മേധാവിയാണെന്ന് കാണിക്കുന്നു. പതുക്കെ അവസാനിക്കുന്ന പകർപ്പ് വേഗതയുടെയോ കാലതാമസത്തിന്റെയോ പ്രശ്നത്തെ സൂചിപ്പിക്കുന്നു, സ്ഥിരമായ ഒരു ബിന്ദുവിൽ മരിക്കുന്ന പകർപ്പ് പാക്കറ്റ് വലിപ്പത്തെയോ വഴിയിലെ അവസ്ഥ സൂക്ഷിക്കുന്ന ഉപകരണത്തെയോ സൂചിപ്പിക്കുന്നു.

ആദ്യ മെഗാബൈറ്റുകൾ മാത്രം വലിഞ്ഞാൽ പ്രാമാണീകരണവും മെറ്റാഡാറ്റയും നോക്കുക; എല്ലാം ഇഴയുകയാണെങ്കിൽ ശേഷിയും നഷ്ടവും നോക്കുക. യോജിക്കുന്ന കാരണം തിരുത്തുക, WAN ലിങ്ക് LAN കേബിൾ പോലെ പെരുമാറുമെന്ന പ്രതീക്ഷ ഉപേക്ഷിക്കുക.