Cele dotyczące skalowalności i wydajności usługi Azure Files
Usługa Azure Files oferuje w pełni zarządzane udziały plików w chmurze, które są dostępne za pośrednictwem protokołów systemu plików SMB i NFS. W tym artykule omówiono cele dotyczące skalowalności i wydajności usług Azure Files i Azure File Sync.
Cele wymienione tutaj mogą mieć wpływ na inne zmienne we wdrożeniu. Na przykład wydajność operacji we/wy dla pliku może mieć wpływ na zachowanie klienta SMB i przez dostępną przepustowość sieci. Należy przetestować wzorzec użycia, aby określić, czy skalowalność i wydajność usługi Azure Files spełniają twoje wymagania.
Dotyczy
| Typ udziału plików | SMB | NFS |
|---|---|---|
| Udziały plików w warstwie Standardowa (GPv2), LRS/ZRS |  |
 |
| Udziały plików w warstwie Standardowa (GPv2), GRS/GZRS | |
|
| Udziały plików w warstwie Premium (FileStorage), LRS/ZRS | |
|
Cele skalowania usługi Azure Files
Udziały plików platformy Azure są wdrażane na kontach magazynu, które są obiektami najwyższego poziomu reprezentującymi udostępnioną pulę magazynu. Ta pula magazynu może służyć do wdrażania wielu udziałów plików. W związku z tym należy wziąć pod uwagę trzy kategorie: konta magazynu, udziały plików platformy Azure i pojedyncze pliki.
Cele skalowania konta magazynu
Cele skalowania konta magazynu mają zastosowanie na poziomie konta magazynu. Istnieją dwa główne typy kont magazynu dla usługi Azure Files:
Konta magazynu ogólnego przeznaczenia w wersji 2 (GPv2): konta magazynu GPv2 umożliwiają wdrażanie udziałów plików platformy Azure na standardowym/twardym sprzęcie (opartym na dyskach TWARDYCH). Oprócz przechowywania udziałów plików platformy Azure konta magazynu GPv2 mogą przechowywać inne zasoby magazynu, takie jak kontenery obiektów blob, kolejki lub tabele. Udziały plików można wdrożyć w zoptymalizowanych pod kątem transakcji (domyślnie), warstwach Gorąca lub Chłodna.
Konta magazynu FileStorage: konta magazynu FileStorage umożliwiają wdrażanie udziałów plików platformy Azure na sprzęcie opartym na dyskach ssd (ssd). Konta FileStorage mogą być używane tylko do przechowywania udziałów plików platformy Azure; na koncie FileStorage nie można wdrożyć żadnych innych zasobów magazynu (kontenerów obiektów blob, kolejek, tabel itp.).
| Atrybut | Konta magazynu GPv2 (w warstwie Standardowa) | Konta magazynu FileStorage (premium) |
|---|---|---|
| Liczba kont magazynu na region na subskrypcję | 2501 | 2501 |
| Maksymalna pojemność konta magazynu | 5 PiB2 | 100 TiB (aprowizowana) |
| Maksymalna liczba udziałów plików | Nieograniczony | Nieograniczony, łączny aprowizowany rozmiar wszystkich udziałów musi być mniejszy niż maksymalna niż maksymalna pojemność konta magazynu |
| Maksymalna szybkość współbieżnych żądań | 20 000 operacji we/wy na sekundę2 | 102 400 operacji we/wy na sekundę |
Przepływność (ruch przychodzący i ruch wychodzący) dla magazynu LRS/GRS
|
|
10 340 MiB/s |
Przepływność (ruch przychodzący i wychodzący) dla magazynu ZRS
|
|
10 340 MiB/s |
| Przepływność (ruch przychodzący i ruch wychodzący) dla kombinacji nadmiarowości/regionu, które nie są wymienione w poprzednim wierszu |
|
10 340 MiB/s |
| Maksymalna liczba reguł sieci wirtualnej | 200 | 200 |
| Maksymalna liczba reguł adresów IP | 200 | 200 |
| Operacje odczytu zarządzania | 800 na 5 minut | 800 na 5 minut |
| Operacje zapisu zarządzania | 10 na sekundę/1200 na godzinę | 10 na sekundę/1200 na godzinę |
| Operacje listy zarządzania | 100 na 5 minut | 100 na 5 minut |
1 W przypadku zwiększenia limitu przydziału można utworzyć maksymalnie 500 kont magazynu ze standardowymi punktami końcowymi na region. Aby uzyskać więcej informacji, zobacz Zwiększanie limitów przydziału kont usługi Azure Storage. 2 Konta magazynu ogólnego przeznaczenia w wersji 2 obsługują wyższe limity pojemności i wyższe limity dla ruchu przychodzącego według żądania. Aby poprosić o zwiększenie limitów dla kont, skontaktuj się z działem pomocy technicznej platformy Azure.
Cele skalowania udziałów plików platformy Azure
Cele skalowania udziałów plików platformy Azure mają zastosowanie na poziomie udziału plików.
| Atrybut | Standardowe udziałyplików 1 | Udziały plików w warstwie Premium |
|---|---|---|
| Minimalny rozmiar udziału plików | Brak minimum | 100 GiB (aprowizowana) |
| Aprowizowany rozmiar zwiększa/zmniejsza jednostkę | Nie dotyczy | 1 GiB |
| Maksymalny rozmiar udziału plików |
|
100 TiB |
| Maksymalna liczba plików w udziale plików | Brak ograniczeń | Brak ograniczeń |
| Maksymalna szybkość żądań (maksymalna liczba operacji we/wy na sekundę) |
|
|
| Przepływność (ruch przychodzący i ruch wychodzący) dla pojedynczego udziału plików (MiB/s) |
|
100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |
| Maksymalna liczba migawek udziałów | 200 migawek | 200 migawek |
| Maksymalna długośćnazwy obiektu 3 (pełna nazwa ścieżki, w tym wszystkie katalogi, nazwy plików i znaki ukośnika odwrotnego) | 2048 znaków | 2048 znaków |
| Maksymalna długość pojedynczego składnikapathname 3 (w ścieżce \A\B\C\D każda litera reprezentuje katalog lub plik, który jest pojedynczym składnikiem) | 255 znaków | 255 znaków |
| Limit linków twardych (tylko system plików NFS) | Nie dotyczy | 178 |
| Maksymalna liczba kanałów SMB Multichannel | Nie dotyczy | 100 |
| Maksymalna liczba przechowywanych zasad dostępu na udział plików | 5 | 5 |
1 Limity standardowych udziałów plików mają zastosowanie do wszystkich trzech warstw dostępnych dla standardowych udziałów plików: zoptymalizowane pod kątem transakcji, gorąca i chłodna.
2 Domyślne w standardowych udziałach plików to 5 TiB, zobacz Tworzenie udziału plików platformy Azure, aby uzyskać szczegółowe informacje na temat tworzenia udziałów plików o rozmiarze 100 TiB i zwiększaniu istniejących standardowych udziałów plików do 100 TiB. Aby skorzystać z większych celów skalowania, musisz zmienić limit przydziału, aby był większy niż 5 TiB.
3 Usługa Azure Files wymusza niektóre reguły nazewnictwa dla nazw katalogów i plików.
Wartości docelowe skalowania plików
Cele skalowania plików mają zastosowanie do poszczególnych plików przechowywanych w udziałach plików platformy Azure.
| Atrybut | Pliki w udziałach plików w warstwie Standardowa | Pliki w udziałach plików w warstwie Premium |
|---|---|---|
| Maksymalna wielkość pliku | 4 TiB | 4 TiB |
| Maksymalna szybkość współbieżnych żądań | 1000 operacji we/wy na sekundę | Do 80001 |
| Maksymalny ruch przychodzący dla pliku | 60 MiB/s | 200 MiB/s (do 1 GiB/s z SMB Multichannel)2 |
| Maksymalny ruch wychodzący dla pliku | 60 MiB/s | 300 MiB/s (do 1 GiB/s z SMB Multichannel)2 |
| Maksymalna liczba współbieżnych dojść dla katalogugłównego 3 | 10 000 dojść | 10 000 dojść |
| Maksymalna liczba współbieżnych dojść na plik i katalog3 | 2000 dojść | 2000 dojść |
1 Dotyczy operacji we/wy odczytu i zapisu (zazwyczaj mniejsze rozmiary we/wy mniejsze niż lub równe 64 KiB). Liczba operacji na metadanych innych niż operacje odczytu i zapisu może być niższa. Są to limity miękkie, po przekroczeniu których może wystąpić ograniczanie przepustowości.
2 Z zastrzeżeniem limitów sieci maszynowych, dostępnej przepustowości, rozmiarów we/wy, głębokości kolejki i innych czynników. Aby uzyskać szczegółowe informacje, zobacz Wydajność funkcji SMB Multichannel.
3 Usługa Azure Files obsługuje 10 000 otwartych dojść w katalogu głównym i 2000 otwartych dojść na plik i katalog w udziale. Liczba aktywnych użytkowników obsługiwanych na udział zależy od aplikacji, które uzyskują dostęp do udziału. Jeśli aplikacje nie otwierają dojścia do katalogu głównego, usługa Azure Files może obsługiwać ponad 10 000 aktywnych użytkowników na udział. Jeśli jednak używasz usługi Azure Files do przechowywania obrazów dysków dla obciążeń pulpitu wirtualnego na dużą skalę, możesz zabrakło dojść do katalogu głównego lub dla każdego pliku/katalogu. W takim przypadku może być konieczne użycie wielu udziałów plików platformy Azure. Aby uzyskać więcej informacji, zobacz Azure Files sizing guidance for Azure Virtual Desktop (Wskazówki dotyczące określania rozmiaru usługi Azure Files dla usługi Azure Virtual Desktop).
Wskazówki dotyczące określania rozmiaru usługi Azure Files dla usługi Azure Virtual Desktop
Popularnym przypadkiem użycia usługi Azure Files jest przechowywanie kontenerów profilu użytkownika i obrazów dysków dla usługi Azure Virtual Desktop przy użyciu dołączania plików FSLogix lub App. W przypadku wdrożeń usługi Azure Virtual Desktop na dużą skalę można zabrakło dojść do katalogu głównego lub dla pliku/katalogu, jeśli używasz pojedynczego udziału plików platformy Azure. W tej sekcji opisano sposób obsługi używanych przez różne typy obrazów dysków i zawiera wskazówki dotyczące określania rozmiaru w zależności od używanej technologii.
FSLogix
Jeśli używasz programu FSLogix z usługą Azure Virtual Desktop, kontenery profilu użytkownika to pliki wirtualnego dysku twardego (VHD) lub wirtualnego dysku twardego funkcji Hyper-V (VHDX), a nie kontekst systemu. Każdy użytkownik otworzy jeden uchwyt katalogu głównego, który powinien być udziałem plików. Usługa Azure Files może obsługiwać maksymalnie 10 000 użytkowników przy założeniu, że masz udział plików () + katalog profilu (\\storageaccount.file.core.windows.net\sharename%sid%_%username%) i kontener profilu (profile_%username.vhd(x)).
Jeśli osiągniesz limit 10 000 współbieżnych dojść dla katalogu głównego lub użytkownicy widzą słabą wydajność, spróbuj użyć dodatkowego udziału plików platformy Azure i rozpowszechnić kontenery między udziałami.
Ostrzeżenie
Chociaż usługa Azure Files może obsługiwać maksymalnie 10 000 równoczesnych użytkowników z jednego udziału plików, ważne jest, aby prawidłowo przetestować obciążenia pod kątem rozmiaru i typu utworzonego udziału plików. Wymagania mogą się różnić w zależności od użytkowników, rozmiaru profilu i obciążenia.
Jeśli na przykład masz 2400 równoczesnych użytkowników, potrzebujesz 2400 dojść w katalogu głównym (jeden dla każdego użytkownika), co jest poniżej limitu 10 000 otwartych dojść. W przypadku użytkowników FSLogix osiągnięcie limitu 2000 otwartych dojść do plików i katalogów jest bardzo mało prawdopodobne. Jeśli masz jeden kontener profilów FSLogix na użytkownika, będziesz używać tylko dwóch dojść do plików/katalogów: jeden dla katalogu profilu i jeden dla pliku kontenera profilu. Jeśli użytkownicy mają dwa kontenery (profil i ODFC), potrzebujesz jednego dodatkowego dojścia dla pliku ODFC.
Dołączanie aplikacji za pomocą systemu cimFS
Jeśli używasz dołączania aplikacji MSIX lub dołączania aplikacji do dynamicznie dołączania aplikacji, możesz użyć złożonego systemu plików obrazów (CimFS) lub plików VHD/VHDX dla obrazów dysków. Tak czy inaczej, limity skalowania są na maszynę wirtualną instalowania obrazu, a nie na użytkownika. Liczba użytkowników nie ma znaczenia podczas obliczania limitów skalowania. Po uruchomieniu maszyny wirtualnej instaluje obraz dysku, nawet jeśli nie ma żadnych użytkowników.
Jeśli używasz dołączania aplikacji z systemem cimFS, obrazy dysków zużywają tylko dojścia do plików obrazów dysku. Nie używają dojść do katalogu głównego ani katalogu zawierającego obraz dysku. Jednak ponieważ obraz CimFS jest kombinacją pliku .cim i co najmniej dwóch innych plików, dla każdej maszyny wirtualnej instalowania obrazu dysku należy wykonać jedną obsługę dla trzech plików w katalogu. Jeśli więc masz 100 maszyn wirtualnych, będziesz potrzebować 300 dojść do plików.
Może zabraknie dojść do plików, jeśli liczba maszyn wirtualnych na aplikację przekroczy 2000. W takim przypadku użyj dodatkowego udziału plików platformy Azure.
Dołączanie aplikacji przy użyciu dysku VHD/VHDX
Jeśli używasz dołączania aplikacji z plikami VHD/VHDX, pliki są instalowane w kontekście systemu, a nie w kontekście użytkownika i są udostępniane i tylko do odczytu. Więcej niż jeden uchwyt w pliku VHDX może być używany przez system łączenia. Aby zachować limity skalowania usługi Azure Files, liczba maszyn wirtualnych pomnożonych przez liczbę aplikacji musi być mniejsza niż 10 000, a liczba maszyn wirtualnych na aplikację nie może przekroczyć 2000. Więc ograniczenie jest w zależności od tego, który trafisz jako pierwszy.
W tym scenariuszu można osiągnąć limit dla każdego pliku/katalogu z 2000 instalacji pojedynczego dysku VHD/VHDX. Jeśli udział zawiera wiele plików VHD/VHDX, najpierw można osiągnąć limit katalogu głównego. Na przykład 100 maszyn wirtualnych instalowania 100 udostępnionych plików VHDX osiągnie limit 10 000 obsługi katalogu głównego.
W innym przykładzie 100 maszyn wirtualnych, które uzyskują dostęp do 20 aplikacji, będzie wymagać 2000 dojść katalogu głównego (100 x 20 = 20000), które mieści się w granicach limitu 10 000 dla dojścia katalogu głównego. Potrzebujesz również dojścia do plików i uchwytu katalogu/folderu dla każdej maszyny wirtualnej instalowania obrazu VHD(X), więc 200 dojść w tym przypadku (100 dojść do plików + 100 dojść do katalogów), co jest wygodnie poniżej limitu 2000 dojść na plik/katalog.
Jeśli osiągasz limity maksymalnej liczby współbieżnych dojść dla katalogu głównego lub dla każdego pliku/katalogu, użyj dodatkowego udziału plików platformy Azure.
Cele skalowania usługi Azure File Sync
W poniższej tabeli przedstawiono, które obiekty docelowe są miękkie, reprezentujące przetestowaną granicę firmy Microsoft i twarde, wskazujące wymuszoną maksymalną wartość:
| Zasób | Cel | Limit twardy |
|---|---|---|
| Usługi synchronizacji magazynu na region | 100 usług synchronizacji magazynu | Tak |
| Usługi synchronizacji magazynu na subskrypcję | 15 usług synchronizacji magazynu | Tak |
| Grupy synchronizacji na usługę synchronizacji magazynu | 200 grup synchronizacji | Tak |
| Zarejestrowane serwery na usługę synchronizacji magazynu | 99 serwerów | Tak |
| Prywatne punkty końcowe na usługę synchronizacji magazynu | 100 prywatnych punktów końcowych | Tak |
| Punkty końcowe w chmurze na grupę synchronizacji | 1 punkt końcowy w chmurze | Tak |
| Punkty końcowe serwera na grupę synchronizacji | 100 punktów końcowych serwera | Tak |
| Punkty końcowe serwera na serwer | 30 punktów końcowych serwera | Tak |
| Obiekty systemu plików (katalogi i pliki) na grupę synchronizacji | 100 milionów obiektów | Nie |
| Maksymalna liczba obiektów systemu plików (katalogów i plików) w katalogu (niecykliczne) | 5 milionów obiektów | Tak |
| Maksymalny rozmiar deskryptora zabezpieczeń obiektu (katalogów i plików) | 64 KiB | Tak |
| Rozmiar pliku | 100 GiB | Nie |
| Minimalny rozmiar pliku, który może być warstwowy | Na podstawie rozmiaru klastra systemu plików (dwukrotność rozmiaru klastra systemu plików). Jeśli na przykład rozmiar klastra systemu plików to 4 KiB, minimalny rozmiar pliku to 8 KiB. | Tak |
Uwaga
Punkt końcowy usługi Azure File Sync może być skalowany w górę do rozmiaru udziału plików platformy Azure. Jeśli zostanie osiągnięty limit rozmiaru udziału plików platformy Azure, synchronizacja nie będzie mogła działać.
Metryki wydajności usługi Azure File Sync
Ponieważ agent usługi Azure File Sync działa na maszynie z systemem Windows Server, która łączy się z udziałami plików platformy Azure, efektywna wydajność synchronizacji zależy od wielu czynników w infrastrukturze: Windows Server i podstawowej konfiguracji dysku, przepustowości sieci między serwerem a usługą Azure Storage, rozmiarem pliku, całkowitym rozmiarem zestawu danych i działaniem w zestawie danych. Ponieważ funkcja Azure File Sync działa na poziomie pliku, właściwości wydajności rozwiązania opartego na technologii Azure File Sync powinny być mierzone przez liczbę obiektów (plików i katalogów) przetwarzanych na sekundę.
W przypadku funkcji Azure File Sync wydajność ma kluczowe znaczenie na dwóch etapach:
- Wstępna jednorazowa aprowizacja: Aby zoptymalizować wydajność wstępnej aprowizacji, zapoznaj się z tematem Dołączanie przy użyciu usługi Azure File Sync w celu uzyskania szczegółów optymalnego wdrożenia.
- Trwająca synchronizacja: Po początkowym zainicjowaniu danych w udziałach plików platformy Azure funkcja Azure File Sync utrzymuje wiele punktów końcowych w synchronizacji.
Uwaga
Gdy wiele punktów końcowych serwera w tej samej grupie synchronizacji jest synchronizowanych w tym samym czasie, walczą o zasoby usługi w chmurze. W związku z tym wydajność przekazywania ma wpływ na wydajność. W skrajnych przypadkach niektóre sesje synchronizacji nie będą mieć dostępu do zasobów i zakończy się niepowodzeniem. Jednak te sesje synchronizacji zostaną wznowione wkrótce i ostatecznie powiedzą się po zmniejszeniu przeciążenia.
Wyniki testów wewnętrznych
Aby ułatwić zaplanowanie wdrożenia dla każdego etapu (początkowa jednorazowa aprowizacja i ciągła synchronizacja), poniżej przedstawiono wyniki zaobserwowane podczas testów wewnętrznych w systemie z następującą konfiguracją:
| Konfiguracja systemu | Szczegóły |
|---|---|
| Procesor CPU | 64 rdzenie wirtualne z pamięcią podręczną L3 o wielkości 64 MiB |
| Memory (Pamięć) | 128 GiB |
| Dysk | Dyski SAS z macierzą RAID 10 i pamięcią podręczną podtrzymywaną bateryjnie |
| Sieć | Sieć 1 Gb/s |
| Obciążenie | Serwer plików ogólnego przeznaczenia |
Wstępna jednorazowa aprowizacja
| Wstępna jednorazowa aprowizacja | Szczegóły |
|---|---|
| Liczba obiektów | 25 mln obiektów |
| Rozmiar zestawu danych | ~4,7 TiB |
| Średni rozmiar pliku | ~200 KiB (największy plik: 100 GiB) |
| Wstępne wyliczanie zmian w chmurze | 80 obiektów na sekundę |
| Przepływność przekazywania | 20 obiektów na sekundę na grupę synchronizacji |
| Przepływność pobierania przestrzeni nazw | 400 obiektów na sekundę |
Początkowa wyliczenie zmiany w chmurze: po utworzeniu nowej grupy synchronizacji początkowa wyliczenie zmiany w chmurze jest pierwszym krokiem, który jest wykonywany. W tym procesie system wylicza wszystkie elementy w udziale plików platformy Azure. W trakcie tego procesu nie będzie żadnych działań synchronizacji. Żadne elementy nie zostaną pobrane z punktu końcowego chmury do punktu końcowego serwera, a żadne elementy nie zostaną przekazane z punktu końcowego serwera do punktu końcowego chmury. Działanie synchronizacji zostanie wznowione po zakończeniu początkowego wyliczania zmian w chmurze.
Wydajność to 80 obiektów na sekundę. Możesz oszacować czas ukończenia początkowej wyliczenia zmiany w chmurze, określając liczbę elementów w udziale w chmurze i używając następującej formuły, aby uzyskać czas w dniach.
Czas (w dniach) dla początkowego wyliczenia w chmurze = (liczba obiektów w punkcie końcowym w chmurze)/(80 * 60 * 60 * 24)
Początkowa synchronizacja danych z systemu Windows Server do udziału plików platformy Azure: wie wdrożeń usługi Azure File Sync rozpoczyna się od pustego udziału plików platformy Azure, ponieważ wszystkie dane są w systemie Windows Server. W takich przypadkach początkowa wyliczenie zmiany w chmurze jest szybka, a większość czasu poświęca na synchronizowanie zmian z systemu Windows Server z udziałami plików platformy Azure.
Podczas synchronizacji przekazuje dane do udziału plików platformy Azure, nie ma przestoju na lokalnym serwerze plików, a administratorzy mogą skonfigurować limity sieciowe, aby ograniczyć przepustowość używaną do przekazywania danych w tle.
Synchronizacja początkowa jest zwykle ograniczona przez początkową szybkość przekazywania wynoszącą 20 plików na sekundę na grupę synchronizacji. Klienci mogą oszacować czas przekazywania wszystkich swoich danych na platformę Azure przy użyciu następującej formuły, aby uzyskać czas w dniach:
Czas (w dniach) przekazywania plików do grupy synchronizacji = (liczba obiektów w punkcie końcowym serwera)/(20 * 60 * 60 * 24)
Podzielenie danych na wiele punktów końcowych serwera i grup synchronizacji może przyspieszyć początkowe przekazywanie danych, ponieważ przekazywanie można wykonać równolegle dla wielu grup synchronizacji w tempie 20 elementów na sekundę każda. W związku z tym dwie grupy synchronizacji będą działać z łączną szybkością równą 40 elementów na sekundę. Łączny czas do ukończenia to szacowany czas dla grupy synchronizacji z największą liczbą plików do synchronizacji.
Przepływność pobierania przestrzeni nazw: po dodaniu nowego punktu końcowego serwera do istniejącej grupy synchronizacji agent usługi Azure File Sync nie pobiera żadnej zawartości pliku z punktu końcowego chmury. Najpierw synchronizuje on pełną przestrzeń nazw, a następnie wyzwala wycofanie w tle w celu pobrania plików w całości albo, jeśli włączono obsługę warstw w chmurze, do zasad obsługi warstw w chmurze ustawionych w punkcie końcowym serwera.
Bieżąca synchronizacja
| Bieżąca synchronizacja | Szczegóły |
|---|---|
| Liczba zsynchronizowanych obiektów | 125 000 obiektów (współczynnik zmian danych ~1%) |
| Rozmiar zestawu danych | 50 GiB |
| Średni rozmiar pliku | ~500 KiB |
| Przepływność przekazywania | 20 obiektów na sekundę na grupę synchronizacji |
| Przepływność pełnego pobierania* | 60 obiektów na sekundę |
*Jeśli obsługa warstw w chmurze jest włączona, prawdopodobnie zauważysz lepszą wydajność, ponieważ pobierane są tylko niektóre dane pliku. Usługa Azure File Sync pobiera dane buforowanych plików tylko wtedy, gdy zostaną zmienione w dowolnym punkcie końcowym. W przypadku wszystkich plików warstwowych lub nowo utworzonych agent nie pobiera danych pliku, a zamiast tego synchronizuje przestrzeń nazw tylko ze wszystkimi punktami końcowymi serwera. Agent obsługuje również częściowe pobieranie plików warstwowych w miarę uzyskiwania dostępu do nich przez użytkownika.
Uwaga
Te liczby nie są wskazaniem wydajności, która zostanie osiągnięta. Rzeczywista wydajność zależy od wielu czynników, jak opisano na początku tej sekcji.
W ogólnym przewodniku dotyczącym wdrażania należy pamiętać o kilku kwestiach:
- Przepływność obiektu jest w przybliżeniu skalowana proporcjonalnie do liczby grup synchronizacji na serwerze. Podzielenie danych na wiele grup synchronizacji na serwerze zapewnia lepszą przepływność, która jest również ograniczona przez serwer i sieć.
- Przepływność obiektu jest odwrotnie proporcjonalna do przepływności MiB na sekundę. W przypadku mniejszych plików będziesz mieć większą przepływność w zakresie liczby przetworzonych obiektów na sekundę, ale niższej przepływności MiB na sekundę. Z drugiej strony w przypadku większych plików uzyskasz mniej przetworzonych obiektów na sekundę, ale wyższą przepływność MiB na sekundę. Przepływność MiB na sekundę jest ograniczona przez cele skalowania usługi Azure Files.