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 ਅੰਕੜਾ ਉਹ ਨਤੀਜਾ ਨਹੀਂ ਹੈ।