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

രണ്ട് കാഷുകൾ, രണ്ട് വ്യത്യസ്ത കാലതാമസങ്ങൾ

രണ്ട് ഓപ്ഷനുകളും കാഷ് എന്ന വാക്കിന് കീഴിൽ പ്രത്യക്ഷപ്പെടുന്നു, അവിടെ നിന്നാണ് ആശയക്കുഴപ്പം തുടങ്ങുന്നത്. അവ നെറ്റ്വർക്കിന്റെ എതിർവശങ്ങളിലാണ്.

ChangeWhere it actsWhat it does not imply
Azure Files service metadata cachingThe service's handling of supported metadata operations on eligible sharesNo removal of the client's network round trips
A supported local server or cache designSome content and operations placed nearer the usersNo universal offline access or instant cross-site consistency
Application batching or limited copy concurrencyThe number and overlap of remote operationsNo automatic speedup for every workload

Microsoft-ന്റെ SMB പ്രകടന മാർഗ്ഗനിർദ്ദേശം യോഗ്യമായ SSD ഷെയറുകൾക്കുള്ള മെറ്റാഡാറ്റ കാഷിംഗും അതിനൊപ്പമുള്ള രജിസ്ട്രേഷൻ ഘട്ടവും വിവരിക്കുന്നു. യോഗ്യതയും സവിശേഷതയുടെ അവസ്ഥയും യഥാർത്ഥ സ്റ്റോറേജ് അക്കൗണ്ടിനുള്ളതാണ്, അതിനാൽ രണ്ട് വർഷം മുമ്പത്തെ പ്രിവ്യൂ പ്രഖ്യാപനമല്ല, നിലവിലെ പേജ് വായിക്കുക.

കാത്തിരിപ്പിനെ മൂന്ന് ഭാഗങ്ങളായി വിഭജിക്കുക

ഓരോ മന്ദഗതിയിലുള്ള ഡയറക്ടറി ലിസ്റ്റിംഗിനും മൂന്ന് ചെലവ് ഘടകങ്ങളുണ്ട്, അവ വ്യത്യസ്ത പരിഹാരങ്ങളോട് പ്രതികരിക്കുന്നു. അഭ്യർത്ഥനയ്ക്ക് സേവന വശത്ത് പ്രോസസ്സിംഗ് സമയമുണ്ട്, VPN വഴിയുള്ള ആശ്രിത റൗണ്ട് ട്രിപ്പുകളുടെ എണ്ണം എന്നിവയും നീക്കേണ്ട പേലോഡും ഉണ്ട്. സേവന വശത്തെ കാഷ് ആദ്യത്തേതിനെ ആക്രമിക്കുന്നു. സെർവർ വശത്ത് ഒന്നും രണ്ടാമത്തേതിനെ ആക്രമിക്കുന്നില്ല.

അതുകൊണ്ടാണ് ഒരു ഷെയർ മികച്ച സേവന മെട്രിക്കുകൾ കാണിക്കുമ്പോഴും ഉപയോക്താവിന്റെ ഫയൽ തിരഞ്ഞെടുക്കൽ എട്ട് സെക്കൻഡ് തൂങ്ങിക്കിടക്കുന്നത്.

ഓരോ ഓപ്ഷനും അതിന്റെ സ്ഥാനം നേടുന്നിടം

ജോലിഭാരം മെറ്റാഡാറ്റ-ഭാരിച്ചതാണെങ്കിൽ, യോഗ്യമായ SSD ഷെയറിനെതിരെ ധാരാളം തുറക്കലുകൾ, stat കോളുകൾ, ഡയറക്ടറി എണ്ണലുകൾ ഉണ്ടെങ്കിൽ, സേവന വശത്തെ കാഷിംഗ് വിലകുറഞ്ഞ പരീക്ഷണമാണ്. പുതിയ അടിസ്ഥാനസൗകര്യമോ ഉപയോക്താക്കൾ ഷെയറിൽ എത്തുന്ന രീതിയിലെ മാറ്റമോ ഇതിന് ആവശ്യമില്ല.

ജോലിഭാരം സംവേദനാത്മകവും കാലതാമസത്താൽ പരിമിതവുമാണെങ്കിൽ, രേഖപ്പെടുത്തിയ സമന്വയ മാതൃകയുള്ള പിന്തുണയുള്ള പ്രാദേശിക സെർവർ ഡിസൈനാണ് സത്യസന്ധമായ ഓപ്ഷൻ. ഇത് സ്വന്തം പ്രവർത്തന ചെലവുകളുള്ള മറ്റൊരു ആർക്കിടെക്ചറാണ്, ഒരു സ്വിച്ചല്ല.

ഓരോ ഓപ്ഷനും മാറ്റാത്തത്

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

ഒരു സേവന സവിശേഷത WAN റൗണ്ട് ട്രിപ്പുകൾ നീക്കുന്നു എന്ന് ആരെങ്കിലും വാഗ്ദാനം ചെയ്യുമ്പോൾ, അതാണ് ആദ്യം പരിശോധിക്കേണ്ട അവകാശവാദം.

ഉപയോക്താക്കൾ പരാതിപ്പെടുന്ന പ്രവർത്തനത്തിനെതിരെ അളക്കുക

സിന്തറ്റിക് പകർപ്പിന് പകരം കൃത്യമായ പ്രവർത്തനം സമയം ചെയ്യുക. ബ്രാഞ്ച് ക്ലയന്റിൽ Measure-Command { Get-ChildItem \\files\projects -Recurse } മുമ്പും ശേഷവും താരതമ്യം ചെയ്യാവുന്ന ഒരു സംഖ്യ നൽകുന്നു, Get-SmbMultichannelConnection ക്ലയന്റ് ഒന്നിലധികം പാതകൾ ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. അതേ ജാലകത്തിനുള്ള സേവന വശത്തെ കാലതാമസ മെട്രിക്കുകൾക്കൊപ്പം അത് വയ്ക്കുക.

ഷെയർ, ക്ലയന്റ് സ്ഥാനം, VPN പാത, സുരക്ഷാ നയം എന്നിവ സ്ഥിരമായി സൂക്ഷിക്കുക, അല്ലെങ്കിൽ നിങ്ങൾ സവിശേഷതയല്ല, നിങ്ങളുടെ മാറ്റ ജാലകം അളക്കുകയാണ്. ഫയൽ എണ്ണവും വലിപ്പ വിതരണവും രേഖപ്പെടുത്തുക, കാരണം ചെറിയ ഫയൽ ജോലിഭാരങ്ങളും വൻതോതിലുള്ള പകർപ്പുകളും തികച്ചും വ്യത്യസ്ത ലിവറുകളോട് പ്രതികരിക്കുന്നു.

സൂക്ഷിക്കാൻ യോഗ്യമായ ഫലം യഥാർത്ഥത്തിൽ മന്ദഗതിയിലായിരുന്ന അതിർത്തിയുമായി പൊരുത്തപ്പെടുന്ന മാറ്റവും അതിന്റെ പ്രവർത്തന-സ്ഥിരതാ ചെലവുകൾ എഴുതപ്പെട്ടതുമാണ്. സ്ലൈഡിലെ വലിയ സ്റ്റോറേജ് IOPS സംഖ്യ ആ ഫലമല്ല.

അനുബന്ധ ലേഖനങ്ങൾ