Azure Files મેટાડેટા કેશિંગ વિરુદ્ધ સ્થાનિક શાખા કેશ
સેવા-બાજુનો મેટાડેટા કેશ સર્વરનું કામ ઘટાડે છે. તે તમારા WANમાંથી રાઉન્ડ ટ્રિપ્સ દૂર કરતું નથી. બન્નેની સરખામણી એના આધારે કરો કે તેઓ ખરેખર શું ટૂંકાવે છે.
VPN દ્વારા ધીમા Azure Files એક્સેસ માટે બે ફેરફાર સૂચવામાં આવે છે, અને તે અલગ અલગ વસ્તુઓ ટૂંકાવે છે. સેવા-બાજુનો મેટાડેટા કેશ પાત્ર ઑપરેશનને સર્વર માટે સસ્તા બનાવે છે. સ્થાનિક શાખા કેશ બાઇટ્સ અને ઑપરેશનને વપરાશકર્તાની નજીક લાવે છે. કિમત-યાદી કે પ્રેસ રિલીઝના આધારે બન્નેમાંથી પસંદ કરવું એ એ રીત છે જેમાં શેર બેન્ચમાર્કમાં ઝડપી દેખાય છે અને સવારે નવ વાગ્યે અપરિવર્તિત રહે છે.
બે કેશ, બે અલગ વિલંબ
બન્ને વિકલ્પ કેશ શબ્દ હેઠળ આવે છે, અને ગૂંચવણ ત્યાંથી જ શરૂ થાય છે. તેઓ નેટવર્કની વિરુદ્ધ બાજુઓ પર બેસે છે.
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
Microsoftની SMB પ્રદર્શન માર્ગદર્શિકા પાત્ર SSD શેર માટે મેટાડેટા કેશિંગનું વર્ણન કરે છે, સાથે તેની સાથે આવતા નોંધણી પગલાનું પણ. પાત્રતા અને સુવિધાની સ્થિતિ વાસ્તવિક સ્ટોરેજ ખાતા પર આધારિત છે, તેથી વર્તમાન પૃષ્ઠ વાંચો, બે વર્ષ જૂની પૂર્વાવલોકન જાહેરાત નહીં.
પ્રતીક્ષાને ત્રણ ભાગમાં વહેંચો
દરેક ધીમી ડિરેક્ટરી સૂચિમાં ત્રણ ખર્ચ ઘટકો હોય છે, અને તે અલગ ઉપાયોને પ્રતિસાદ આપે છે. દરેક વિનંતી માટે સેવા પ્રક્રિયા સમય છે, VPN દ્વારા નિર્ભર રાઉન્ડ ટ્રિપ્સની સંખ્યા અને જે પેલોડ ખસેડવો પડે છે. સેવા-બાજુનો કેશ પ્રથમ પર હુમલો કરે છે. સર્વર બાજુ પર કંઈ પણ બીજા પર હુમલો કરતું નથી.
તેથી જ શેર વધુ સારા સેવા મેટ્રિક્સ બતાવી શકે છે જ્યારે વપરાશકર્તાનું ફાઇલ પિકર હજી આઠ સેકન્ડ માટે અટકી જાય છે.
દરેક વિકલ્પ પોતાનું સ્થાન ક્યાં કમાય છે
જો કામનો ભાર મેટાડેટા-ભારે હોય, પાત્ર SSD શેર સામે ઘણી ખુલવાની ક્રિયાઓ, stat કૉલ્સ અને ડિરેક્ટરી ગણતરીઓ હોય, તો સેવા-બાજુનો કેશ સસ્તો પ્રયોગ છે. તેને નવી ઇન્ફ્રાસ્ટ્રક્ચરની અને વપરાશકર્તાઓ શેર સુધી કેવી રીતે પહોંચે તેમાં ફેરફારની જરૂર નથી.
જો કામનો ભાર પરસ્પરક્રિયાત્મક અને વિલંબ-મર્યાદિત હોય, તો દસ્તાવેજીકૃત સિંક્રોનાઇઝેશન મોડેલ સાથેનું સમર્થિત સ્થાનિક સર્વર ડિઝાઇન એ પ્રામાણિક વિકલ્પ છે. તે પોતાના ચાલુ ખર્ચ સાથેનું અલગ આર્કિટેક્ચર છે, સ્વિચ નહીં.
બન્નેમાંથી કોઈ વિકલ્પ જે બદલતું નથી
SMB સાઇનિંગ અને એન્ક્રિપ્શન હજી લાગુ પડે છે, અને તે હજી પોતાનો ખર્ચ લે છે. એક્સેસ નિયંત્રણ હજી પ્રતિ વપરાશકર્તા નક્કી થાય છે, તેથી કેશ કરેલી નકલ અધિકૃતિને સરળ બનાવતી નથી. સાઇટ્સ વચ્ચેની સુસંગતતાને હજી નિર્ધારિત મોડેલની જરૂર છે, કારણ કે શાખા-સ્થાનિક વાંચન અને ક્લાઉડ-બાજુનું લેખન કોઈ વસ્તુ પર સહમત થવું પડે છે. અને ઑફલાઇન એક્સેસ ક્લાઇયન્ટ સેટિંગ જ રહે છે, સર્વર સુવિધાની આડઅસર નહીં.
જ્યારે કોઈ વચન આપે છે કે સેવા સુવિધા WAN રાઉન્ડ ટ્રિપ્સ દૂર કરે છે, ત્યારે એ પ્રથમ ચકાસવાનો દાવો છે.
વપરાશકર્તાઓ જે ઑપરેશનની ફરિયાદ કરે છે તેની સામે માપો
કૃત્રિમ નકલને બદલે ચોક્કસ ઑપરેશનનો સમય લો. શાખા ક્લાઇયન્ટ પર Measure-Command { Get-ChildItem \\files\projects -Recurse } એ સંખ્યા આપે છે જે તમે પહેલાં અને પછી સરખાવી શકો છો, અને Get-SmbMultichannelConnection બતાવે છે કે ક્લાઇયન્ટ એક કરતાં વધુ માર્ગ વાપરે છે કે નહીં. તેને સમાન વિન્ડો માટે સેવા-બાજુના વિલંબ મેટ્રિક્સની બાજુમાં મૂકો.
શેર, ક્લાઇયન્ટનું સ્થાન, VPN માર્ગ અને સુરક્ષા નીતિ સ્થિર રાખો, નહીં તો તમે સુવિધાને બદલે તમારી ફેરફાર-વિન્ડો માપી રહ્યા છો. ફાઇલની સંખ્યા અને કદનું વિતરણ પણ નોંધો, કારણ કે નાની ફાઇલના કામના ભાર અને મોટા પ્રમાણમાં નકલો સંપૂર્ણપણે અલગ લિવરને પ્રતિસાદ આપે છે.
જે પરિણામ રાખવા લાયક છે તે ખરેખર ધીમી હતી તે સીમા સાથે મેળ ખાતો ફેરફાર છે, જેના સંચાલન અને સુસંગતતાના ખર્ચ લખેલા હોય. સ્લાઇડ પર મોટો સ્ટોરેજ IOPS આંકડો એ પરિણામ નથી.