Azure Files metadata keşi yerli filial keşi ilə müzayisədə
Xidmət tərəfindəki metadata keşi serverin işini azaldır. Lakin WAN üzərindəki gediş-gəlişləri aradan qaldırmır. İkisini həqiqətən nəyi qısaltdıqlarına görə müzayisə edin.
VPN üzərindən yavaş Azure Files girişi üçün iki dəyişiklik təklif olunur və onlar fərqli şeyləri qısaldır. Xidmət tərəfindəki metadata keşi uyğun əməliyyatları server üçün daha ucuz edir. Yerli filial keşi isə baytları və əməliyyatları istifadəçiyə daha yaxın yerə köçürür. Aralarında qiymət siyahısına və ya mətbuat bəyanatına görə seçim etmək, paylaşımın benchmarkda daha sürətli görünüb səhər doqquzda dəyişməz qalmasının yoludur.
İki keş, iki fərqli gecikmə
Hər iki variant keş sözü altında təqdim olunur və çaşqınlıq buradan başlayır. Onlar şəbəkənin əks tərəflərində yerləşir.
| 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-un SMB performans təlimatı uyğun SSD paylaşımları üçün metadata keşini və onunla birlikdə gələn qeydiyyat addımını təsvir edir. Uyğunluq və funksiya vəziyyəti faktiki saxlama hesabına aiddir, ona görə də iki il əvvəlki önizləmə elanını deyil, cari səhifəni oxuyun.
Gözləməni üç hissəyə bölün
Hər yavaş qovluq siyahısının üç xərc komponenti var və onlar fərqli düzəlişlərə cavab verir. Hər sorğu üçün xidmət emal müddəti, və VPN üzərindən asılı gediş-gəlişlərin sayı və daşınmalı olan yük var. Xidmət tərəfindəki keş birinciyə hücum edir. Server tərəfində heç nə ikinciyə hücum etmir.
Buna görə də paylaşım daha yaxşı xidmət göstəriciləri göstərə bilər, halbuki istifadəçinin fayl seçicisi hələ də səkkiz saniyə donub qalır.
Hər variant harada yer qazanır
Əgər iş yükü metadata baxımından ağırdırsa, uyğun SSD paylaşımına qarşı çoxsaylı açılış, stat çağırışı və qovluq sadalaması varsa, xidmət tərəfindəki keş ucuz təcrübədir. Yeni infrastruktur və istifadəçilərin paylaşıma çatma üsulunda heç bir dəyişiklik tələb etmir.
Əgər iş yükü interaktiv və gecikmə ilə məhdudlaşırsa, sənədləşdirilmiş sinxronizasiya modeli olan dəstəklənən yerli server dizaynı dürüst variantdır. Bu, öz əməliyyat xərcləri olan fərqli bir memarlıqdır, açar deyil.
İki variantdan heç birinin dəyişmədiyi şeylər
SMB imzalanması və şifrələmə hələ də tətbiq olunur və hələ də öz qiymətinə başa gəlir. Giriş nəzarəti hələ də hər istifadəçi üzrə həll olunur, ona görə də keşlənmiş surət avtorizasiyanı sadələşdirmir. Saytlar arasında uyğunluq hələ də müəyyən edilmiş model tələb edir, çünki filialdaxili oxumalar və bulud tərəfindəki yazmalar nəyisə razılaşdırmalıdır. Və oflayn giriş müştəri parametri olaraq qalır, server funksiyasının yan təsiri deyil.
Kimsə bir xidmət funksiyasının WAN gediş-gəlişlərini aradan qaldırdığını vəd edəndə, ilk yoxlanmalı iddia budur.
İstifadəçilərin şikayət etdiyi əməliyyata görə ölçün
Sintetik surəti deyil, dəqiq əməliyyatı ölçün. Measure-Command { Get-ChildItem \\files\projects -Recurse } filial müştərisində əvvəl və sonra müzayisə edə biləcəyiniz rəqəm verir, Get-SmbMultichannelConnection isə müştərinin birdən çox yoldan istifadə edib-etmədiyini göstərir. Bunu eyni pəncərə üçün xidmət tərəfindəki gecikmə göstəricilərinin yanına qoyun.
Paylaşımı, müştəri məkanını, VPN yolunu və təhlükəsizlik siyasətini sabit saxlayın, əks halda funksiyanı deyil, dəyişiklik pəncərənizi ölçürsünüz. Fayl sayını və ölçü paylanmasını da qeyd edin, çünki kiçik fayl iş yükləri və toplu surətləmələr tamamilə fərqli qollara cavab verir.
Dəyərli nəticə, həqiqətən yavaş olan sərhədə uyğunlaşdırılmış dəyişiklikdir və onun əməliyyat və uyğunluq xərcləri yazılmalıdır. Slaydda daha böyük saxlama IOPS rəqəmi o nəticə deyil.