Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
✔️ Dotyczy: klasyczne udziały plików SMB i NFS utworzone za pomocą dostawcy zasobów Microsoft.Storage
✔️ Dotyczy: udziałów plików utworzonych za pomocą dostawcy zasobów Microsoft.FileShares
Usługa Azure Files może spełniać wymagania dotyczące wydajności dla większości aplikacji i przypadków użycia. W tym artykule wyjaśniono różne czynniki wpływające na wydajność udziałów plików oraz sposób optymalizacji wydajności usługi Azure Files dla danego obciążenia.
Słownik wydajności magazynu
Przed przeczytaniem tego artykułu warto zrozumieć niektóre kluczowe terminy związane z wydajnością magazynu:
Operacje we/wy na sekundę (liczba operacji we/wy na sekundę)
Liczba operacji we/wy na sekundę lub operacji wejścia/wyjścia na sekundę mierzy liczbę operacji systemu plików na sekundę. W dokumentacji usługi Azure Files termin „IO” jest stosowany zamiennie z terminami „operacja” i „transakcja”.
Rozmiar we/wy
Rozmiar we/wy, czasami określany jako rozmiar bloku, jest rozmiarem żądania używanego przez aplikację do wykonywania pojedynczej operacji wejścia/wyjścia (we/wy) w magazynie. W zależności od aplikacji rozmiar we/wy może wahać się od małych rozmiarów, takich jak 4 KiB do większych rozmiarów. Rozmiar we/wy odgrywa ważną rolę w osiągalnej przepływności.
Przepływność
Przepływność mierzy liczbę bitów odczytanych lub zapisanych w magazynie na sekundę i jest mierzona w mebibajtach na sekundę (MiB/s). Aby obliczyć przepływność, pomnożyj liczbę operacji we/wy na sekundę według rozmiaru operacji we/wy. Na przykład 10 000 operacji we/wy na sekundę × 1 rozmiar we/wy MiB = 10 GiB/s, podczas gdy 10 000 operacji we/wy na sekundę × 4 rozmiar we/wy KiB = 38 MiB/s.
Opóźnienie
Opóźnienie jest synonimem opóźnienia i jest mierzone w milisekundach (ms). Istnieją dwa typy opóźnień: kompleksowe opóźnienie i opóźnienie usługi. Aby uzyskać więcej informacji, zobacz Opóźnienie.
Głębokość kolejki
Głębokość kolejki to liczba oczekujących żądań we/wy, które zasób magazynu może obsłużyć w dowolnym momencie. Aby uzyskać więcej informacji, zobacz Głębokość kolejki.
Wybieranie warstwy multimediów na podstawie wzorców użycia
Azure Files zapewnia dwie warstwy nośników magazynowania, których można użyć do równoważenia wydajności i ceny: SSD i HDD. Wybierasz warstwę nośnika dla udziału plików na poziomie konta magazynu. Po utworzeniu konta magazynowania w określonej warstwie nośnika nie można przenieść się do innej warstwy nośnika bez ręcznej migracji do nowego udziału plików.
W przypadku wyboru między udziałami plików SSD i HDD należy wziąć pod uwagę wymagania oczekiwanego wzorca użycia, który ma być uruchamiany w Azure Files. Jeśli potrzebujesz dużej liczby operacji wejścia/wyjścia na sekundę, wysokiej przepustowości danych lub niskich opóźnień, wybierz udziały plików oparte na dyskach SSD.
W poniższej tabeli przedstawiono podsumowanie oczekiwanych celów wydajności między udziałami plików SSD i HDD. Aby uzyskać szczegółowe informacje, zobacz Cele dotyczące skalowalności i wydajności usługi Azure Files.
| Wymagania dotyczące wzorca użycia | SSD | hdd |
|---|---|---|
| Opóźnienie zapisu (liczba milisekund jednocyfrowych) | Tak | Tak |
| Opóźnienie odczytu (liczba milisekund jednocyfrowych) | Tak | Nie. |
Udziały plików SSD korzystają z modelu alokacji, który gwarantuje następujący poziom wydajności zależny od rozmiaru udziału. Aby uzyskać więcej informacji, zobacz aprowizowany model w wersji 1.
Najlepsze rozwiązania dotyczące wydajności
Niezależnie od tego, czy oceniasz wymagania dotyczące wydajności dla nowego, czy istniejącego obciążenia, zrozumienie wzorców użycia pomaga osiągnąć przewidywalną wydajność.
Czułość opóźnienia: Obciążenia, które są wrażliwe na opóźnienie odczytu i mają wysoką widoczność dla użytkowników końcowych, są bardziej odpowiednie dla udziałów plików SSD, co może zapewnić jedno milisekundowe opóźnienie zarówno dla operacji odczytu, jak i zapisu (mniej niż 2 ms dla małego rozmiaru operacji we/wy).
Wymagania dotyczące liczby operacji we/wy na sekundę i przepływności: Udziały plików SSD obsługują większe limity liczby operacji we/wy na sekundę i przepływności niż udziały plików HDD. Aby uzyskać więcej informacji, zobacz Cele skalowania udziałów plików.
Czas trwania i częstotliwość obciążenia: Obciążenia krótkotrwałe (trwające minuty) i występujące rzadko (raz na godzinę) rzadziej osiągają górne granice wydajności udziałów plików na dyskach HDD niż obciążenia długotrwałe i często występujące. W udziałach plików na dyskach SSD czas trwania obciążenia roboczego pomaga określić właściwy profil wydajności, który należy zastosować na podstawie przydzielonej pojemności magazynu, liczby operacji we/wy na sekundę i przepustowości. Typowy błąd polega na uruchamianiu testów wydajnościowych tylko przez kilka minut, co często jest mylące. Aby uzyskać realistyczny obraz wydajności, upewnij się, że testujesz z odpowiednio wysoką częstotliwością i czasem. W udziałach plikowych krótki test może mierzyć oparty na kredytach skokowy limit operacji IOPS zamiast przydzielonych operacji IOPS. Więcej informacji można znaleźć w artykule Bursting.
Równoległe obciążenia: W przypadku obciążeń, które wykonują operacje równolegle, na przykład za pośrednictwem wielu wątków, procesów lub wystąpień aplikacji na tym samym kliencie, udziały plików SSD zapewniają wyraźną przewagę nad udziałami plików HDD: SMB Multichannel. Aby uzyskać więcej informacji, zobacz Poprawianie wydajności udziału plików Azure przez protokół SMB.
Rozkład operacji interfejsu API: obciążenia intensywnie wykorzystujące metadane, takie jak obciążenia wykonujące operacje odczytu na dużej liczbie plików, lepiej nadają się do udziałów plików SSD. Aby uzyskać więcej informacji, zobacz Obciążenie intensywnie wykorzystujące metadane lub przestrzeń nazw.
Umieszczanie strefowe: użyj umieszczania strefowego, aby wybrać określoną strefę dostępności, w której znajduje się twoje konto pamięci masowej. Ta funkcja umożliwia umieszczenie maszyn wirtualnych w tej samej strefie dostępności co pamięć masowa, co może zmniejszyć opóźnienia nawet o 30%. Ta funkcja jest obecnie dostępna tylko dla kont magazynu SSD korzystających z magazynu lokalnie nadmiarowego (LRS) w obsługiwanych regionach.
Zwielokrotnienie wydajności
Udziały plików wykorzystujące model rozliczeniowy provisioned v2 lub provisioned v1 obsługują bursting IOPS oparty na kredytach. Bursting oparty na kredytach pozwala udziałowi plików używać większej liczby operacji wejścia/wyjścia na sekundę (IOPS), niż mu przydzielono, przez ograniczony czas. Zwiększanie wydajności oparte na kredytach to cecha udziału plików. Ruch skokowy to wzorzec obciążenia z krótkimi skokami IOPS lub przepustowości. Tryb burst oparty na kredytach może pochłaniać krótkie skoki IOPS z nagłego ruchu.
Bursting na podstawie kredytu jest wliczony w koszt udostępnionego udziału plików i nie dodaje opłat do rachunku. Zwiększanie wydajności oparte na kredytach dotyczy tylko IOPS. Nie zwiększa przepustowości powyżej przydzielonej przepustowości.
Bursting nie dotyczy udziałów plików w modelu płatności zgodnie z użyciem. Klasyczne udostępnione pliki, które działają w trybie burst, nadal podlegają limitom IOPS konta magazynowego. Więcej informacji można znaleźć w artykule Classic file share data plane limits. Aby uzyskać informacje o tym, jak bursting wpływa na koszty, zobacz Opis rozliczeń usługi Azure Files.
Aprowizowanie w wersji 2
Zwiększanie liczby operacji we/wy na sekundę oparte na kredytach zapewnia większą elastyczność w przypadku użycia operacji we/wy na sekundę. Użyj tej elastyczności jako buforu przed nieprzewidzianymi skokami operacji we/wy. W przypadku ustalonych wzorców operacji we/wy należy uwzględnić szczytowe obciążenia we/wy.
Kredyty na zwiększenie liczby operacji we/wy na sekundę są gromadzone za każdym razem, gdy ruch dla udziału plików jest mniejszy niż określona (bazowa) liczba operacji we/wy na sekundę. Za każdym razem, gdy użycie IOPS udziału plików przekracza przydzieloną liczbę operacji we/wy na sekundę i dostępne są kredyty na przyspieszone operacje we/wy, udział plików może osiągnąć maksymalny dozwolony limit liczby operacji we/wy na sekundę. Udziały plików mogą nadal rosnąć, o ile pozostają środki, na podstawie liczby naliczonych środków. Każde operacje we/wy poza aprowizowaną operacją we/wy zużywają jeden kredyt. Po zużyciu wszystkich kredytów udział powraca do poziomu aprowizowanych operacji IOPS. Operacje we/wy na sekundę w udziale plików nie muszą wykonywać żadnych specjalnych operacji w celu korzystania ze skalowania. Rozerwanie działa na zasadzie najlepszego wysiłku.
Udziały kredytowe mają trzy stany:
- Naliczanie, gdy udostępnianie plików korzysta z mniejszej liczby IOPS niż przydzielono.
- Spadek, gdy udział plików używa więcej niż aprowizowanych IOPS i w trybie burstingu.
- Stała, gdy udział plików używa dokładnie aprowizowanej liczby operacji we/wy na sekundę i nie są naliczane ani wykorzystywane żadne kredyty.
Nowy udział plików zaczyna się od pełnej liczby środków w zasobniku z serii. Kredyty dla nagłego wzrostu nie są naliczane, jeśli dzielone IOPS spadną poniżej ustalonego limitu z powodu ograniczeń serwera. Następujące formuły służą do określania limitu liczby operacji we/wy na sekundę w trybie burst i liczby kredytów możliwych dla udziału w plikach.
| Item | Formuła SSD | Formuła HDD |
|---|---|---|
| Limit liczby operacji we/wy na sekundę | MIN(MAX(3 * ProvisionedIOPS, 10000), 102400) |
MIN(MAX(3 * ProvisionedIOPS, 5000), 50000) |
| Środki na wzrost liczby operacji we/wy na sekundę | (BurstLimit - ProvisionedIOPS) * 3600 |
(BurstLimit - ProvisionedIOPS) * 3600 |
W poniższej tabeli przedstawiono kilka przykładów formuł dla różnych przydzielonych IOPS.
| Aprowizowane operacje wy/wy na sekundę | Limit operacji we/wy na sekundę w trybie burst dla dysków SSD | Kredyty zwiększenia wydajności SSD | Limit operacji we/wy na sekundę hdd | Środki na wzrost dysków HDD |
|---|---|---|---|---|
| 500 | -- | -- | Do 5 000 | 16,200,000 |
| 1,000 | -- | -- | Do 5 000 | 14,400,000 |
| 3,000 | Do 10 000 | 25,200,000 | Do 9000 | 21,600,000 |
| 5,000 | Do 15 000 | 36,000,000 | Do 15 000 | 36,000,000 |
| 10,000 | Do 30 000 | 72,000,000 | Do 30 000 | 72,000,000 |
| 25,000 | Do 75 000 | 180,000,000 | Do 50 000 | 90,000,000 |
| 50,000 | Do 102 400 | 188,640,000 | Do 50 000 | 0 |
| 75,000 | Do 102 400 | 98,640,000 | -- | -- |
| 102,400 | Do 102 400 | 0 | -- | -- |
Aprowizowanie w wersji 1
Model provisioned v1 obsługuje dwa typy burstingu: bursting oparty na kredytach, który jest dostępny bez dodatkowych kosztów, oraz płatny bursting, który można opcjonalnie włączyć, aby umożliwić IOPS i przepustowość powyżej przydzielonej wartości w ramach opłat zależnych od użycia.
Aprowizowana wersja 1 — wzrost wydajności oparty na kredytach
Zwiększanie liczby operacji we/wy na sekundę oparte na kredytach zapewnia większą elastyczność w przypadku użycia operacji we/wy na sekundę. Użyj tej elastyczności jako buforu przed nieprzewidzianymi skokami operacji we/wy. W przypadku ustalonych wzorców operacji we/wy należy uwzględnić szczytowe obciążenia we/wy.
Punkty wzrostu IOPS gromadzą się za każdym razem, gdy ruch dla klasycznego udziału plików jest mniejszy niż wyznaczone IOPS (punkt odniesienia). Za każdym razem, gdy użycie operacji we/wy na sekundę klasycznego udziału plików przekracza aprowizowaną liczbę operacji we/wy na sekundę i jest dostępne środki na operacje we/wy na sekundę, klasyczny udział plików może przekroczyć maksymalny dozwolony limit liczby operacji we/wy na sekundę. Klasyczne udziały plików mogą nadal rosnąć tak długo, jak długo istnieją pozostałe środki, na podstawie liczby naliczanych kredytów z serii. Każde operacje we/wy poza aprowizowaną operacją we/wy zużywają jeden kredyt. Po zużyciu wszystkich kredytów klasyczny plik współdzielony wraca do skonfigurowanego IOPS. Operacje IOPS względem klasycznych udziałów plików nie muszą wykonywać żadnych specjalnych kroków, aby użyć skalowania. Rozerwanie działa na zasadzie najlepszego wysiłku.
Udziały kredytowe mają trzy stany:
- Naliczanie, gdy klasyczny udział plików używa mniej operacji we/wy na sekundę (IOPS) niż przyznane IOPS.
- Malejąco, gdy klasyczny udział plików używa więcej niż aprowizowana liczba operacji we/wy na sekundę i w trybie skalowania.
- Stała, gdy klasyczny udział plików używa dokładnie przydzielonej liczby operacji we/wy na sekundę i nie są naliczane ani używane żadne kredyty.
Nowe klasyczne udostępnianie plików zaczyna się od pełnej liczby środków w wiadrze przyspieszeń. Kredyty dla nagłego wzrostu nie są naliczane, jeśli dzielone IOPS spadną poniżej ustalonego limitu z powodu ograniczeń serwera. Następujące formuły służą do określenia limitu IOPS w trybie burst i liczby kredytów możliwych dla klasycznego udziału plików.
| Item | Formula |
|---|---|
| Limit przepustowości | MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400) |
| Kredyty na przeciążenie | (BurstLimit - BaselineIOPS) * 3600 |
W poniższej tabeli przedstawiono kilka przykładów tych formuł dla aprowizowanych rozmiarów:
| Pojemność (GiB) | Podstawowe IOPS | Zwiększone IOPS | Kredyty na przeciążenie | Przepływność (MiB/s) |
|---|---|---|---|---|
| 100 | 3,100 | Do 10 000 | 24,840,000 | 110 |
| 500 | 3,500 | Do 10 000 | 23,400,000 | 150 |
| 1,024 | 4,024 | Do 10 000 | 21,513,600 | 203 |
| 5,120 | 8 120 | Do 15 360 | 26,064,000 | 613 |
| 10,240 | 13,240 | Do 30 720 | 62,928,000 | 1,125 |
| 33,792 | 36,792 | Do 102 400 | 227,548,800 | 3,480 |
| 51 200 | 54,200 | Do 102 400 | 164,880,000 | 5220 |
| 102,400 | 102,400 | Do 102 400 | 0 | 10,340 |
Przydzielona wersja 1 płatnego zwiększenia przepustowości
Płatne zwiększanie przepustowości to zaawansowana funkcja dedykowanego modelu w wersji 1, przeznaczona do obsługi klientów, którzy nie chcą doświadczać ograniczeń. Płatne zwiększenie wydajności powoduje dodanie dodatkowych rozliczeń opartych na użyciu dla dowolnej ilości operacji we/wy na sekundę lub przepływności powyżej aprowizowanego magazynu. Ta funkcja różni się od zwiększania wydajności w trybie burst opartego na kredytach, który jest dostępny bezpłatnie w ramach przydzielonej pamięci masowej. Chociaż płatne zwiększanie wydajności może dodawać elastyczności w aprowizacji klasycznego udziału plików, może również prowadzić do nieprzewidzianych kosztów w przypadku nieprawidłowego użycia.
Podobnie jak w przypadku zwiększania wydajności opartego na kredytach, płatne zwiększanie wydajności nie zastępuje aprowizacji odpowiedniej ilości operacji we/wy na sekundę i przepływności. Zamiast tego zapewnia dalszą ochronę przed ograniczaniem przepustowości, jeśli wystąpi nieoczekiwane zapotrzebowanie. Jeśli masz stały poziom wykorzystania operacji we/wy na sekundę (IOPS) lub przepustowości, taniej jest przydzielić wystarczającą liczbę operacji IOPS i odpowiednią przepustowość (poprzez aprowizację pamięci masowej), aby pokryć zapotrzebowanie, zamiast polegać na płatnym trybie burst.
Płatne zwiększanie wydajności jest domyślnie wyłączone, ale można je włączyć, postępując zgodnie z instrukcjami dotyczącymi zmiany charakterystyk kosztów i wydajności klasycznego udziału plików v1 z aprowizacją (tylko przy użyciu programu PowerShell i interfejsu wiersza polecenia CLI). Jeśli włączysz płatne zwiększanie wydajności, monitoruj użycie liczby operacji we/wy na sekundę (IOPS) i przepustowości za pomocą następujących metryk dostępnych w usłudze Azure Monitor:
- Przydzielone IOPS udział plików
- Przydzielona przepustowość zasobu plików MiB/s (przepustowość)
- Transakcje według maksymalnej liczby operacji we/wy na sekundę
- Przepustowość według maksymalnej liczby miB/s (przepływność)
- Kredyty Tymczasowego Rozszerzenia dla IOPS (wybuchowe zwiększenie wydajności oparte na kredytach)
- Płatne skalowanie systemu iOS (IOS)
- Płatna przepustowość zwiększona
Opóźnienie
Jeśli myślisz o opóźnieniu, najpierw dowiedz się, jak Azure Files określa opóźnienie. Najbardziej typowe pomiary to opóźnienie skojarzone z metrykami całkowitego opóźnienia i opóźnienia usługi. Korzystając z tych metryk transakcji , można zidentyfikować opóźnienia po stronie klienta i problemy z siecią, pokazując, ile czasu ruch aplikacji spędza podczas przesyłania do i z klienta.
Całkowite opóźnienie końcowe (SuccessE2ELatency) to całkowity czas potrzebny na wykonanie pełnej trasy transakcji od klienta, przez sieć, do usługi Azure Files i z powrotem do klienta.
Opóźnienie usługi (SuccessServerLatency) to czas potrzebny na pełny przebieg transakcji wyłącznie w usłudze Azure Files. Ta miara nie obejmuje żadnego opóźnienia klienta ani sieci.
Różnica między wartościami SuccessE2ELatency i SuccessServerLatency jest prawdopodobnie spowodowana przez sieć i/lub klienta.
Często mylić opóźnienie klienta z opóźnieniem usługi (w tym przypadku wydajność usługi Azure Files). Jeśli na przykład raport opóźnienia usługi wskazuje na niskie opóźnienie, a raport opóźnienia end-to-end wskazuje na bardzo wysokie opóźnienie żądań, oznacza to, że cały czas jest zużywany na przesyłanie danych do klienta i od klienta, a nie w samej usłudze Azure Files.
Ponadto, jak pokazano na diagramie, im dalej znajdujesz się od usługi, tym większe są opóźnienia i tym trudniej jest osiągnąć granice skalowalności wydajnościowej w przypadku dowolnej usługi chmurowej. Ten warunek jest szczególnie spełniony w przypadku uzyskiwania dostępu do Azure Files ze środowiska lokalnego. Chociaż opcje takie jak Azure ExpressRoute są idealne dla środowisk lokalnych, nadal nie dorównują wydajności aplikacji (moc obliczeniowa + magazyn danych) działającej wyłącznie w tym samym regionie platformy Azure.
Napiwek
Używanie maszyny wirtualnej na platformie Azure do testowania wydajności między środowiskiem lokalnym a platformą Azure jest skutecznym i praktycznym sposobem odniesienia możliwości sieciowych połączenia z platformą Azure. Niedostatecznie duże lub niepoprawnie kierowane obwody usługi ExpressRoute lub bramy sieci VPN mogą znacznie spowolnić zadania uruchomione w usłudze Azure Files.
Głębokość kolejki
Głębokość kolejki to liczba oczekujących żądań we/wy, które może obsłużyć zasób magazynu. Wraz z ewolucją dysków używanych przez systemy pamięci masowej — od dysków twardych HDD (IDE, SATA, SAS) po urządzenia półprzewodnikowe (SSD, NVMe) — zaczęły one też obsługiwać większą głębokość kolejek. Obciążenie składające się z pojedynczego klienta, który szeregowo wchodzi w interakcję z pojedynczym plikiem w dużym zestawie danych, jest przykładem niskiej głębokości kolejki. Natomiast obciążenie, które obsługuje równoległość z wieloma wątkami i wieloma plikami, może łatwo osiągnąć wysoką głębokość kolejki. Ponieważ Azure Files jest rozproszoną usługą plików, która obejmuje tysiące węzłów klastra Azure i jest przeznaczona do uruchamiania obciążeń na dużą skalę, kompilowania i testowania obciążeń z dużą głębokością kolejki.
Wysoką głębokość kolejki można osiągnąć na kilka różnych sposobów. Aby określić głębokość kolejki dla obciążenia, należy pomnożyć liczbę klientów przez liczbę plików przez liczbę wątków (klienci × pliki × wątki = głębokość kolejki).
W poniższej tabeli przedstawiono różne kombinacje, których można użyć do osiągnięcia wyższej głębokości kolejki. Chociaż można przekroczyć optymalną głębokość kolejki 64, nie jest to zalecane. Jeśli tak zrobisz, nie zobaczysz więcej zysków wydajności i ryzykujesz zwiększenie opóźnienia ze względu na nasycenie protokołu TCP.
| Klienci | Pliki | Wątki | Głębokość kolejki |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 1 | 2 | 2 |
| 1 | 2 | 2 | 4 |
| 2 | 2 | 2 | 8 |
| 2 | 2 | 4 | 16 |
| 2 | 4 | 4 | 32 |
| 1 | 8 | 8 | 64 |
| 4 | 4 | 2 | 32 |
Napiwek
Aby osiągnąć górne limity wydajności, upewnij się, że obciążenie lub test porównawczy jest wielowątkowy z wieloma plikami.
Aplikacje jednowątkowa i wielowątkowa
Azure Files najlepiej współdziała z aplikacjami wielowątkowymi. Najłatwiejszym sposobem na zrozumienie wpływu wielowątkowości na wydajność obciążenia jest przeanalizowanie scenariusza pod kątem operacji wejścia/wyjścia (I/O). W poniższym przykładzie istnieje obciążenie, które wymaga skopiowania 10 000 małych plików tak szybko, jak to możliwe, do udziału plików platformy Azure lub z niego.
Ta tabela pokazuje czas potrzebny (w milisekundach) na utworzenie pojedynczego pliku 16 KiB na udostępnianym zasobie plików platformy Azure, w oparciu o jednowątkową aplikację zapisującą w blokach o rozmiarze 4 KiB.
| Operacja we/wy | Utwórz | Zapis 4 KiB | Zapis 4 KiB | Zapis 4 KiB | Zapis 4 KiB | Zamknij | Łącznie |
|---|---|---|---|---|---|---|---|
| Wątek 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
W tym przykładzie utworzenie pojedynczego pliku o rozmiarze 16 KiB w ramach sześciu operacji zajmuje około 14 ms. Jeśli aplikacja jednowątkowa chce przenieść 10 000 plików do udziału plików platformy Azure, zajmie to 140 000 ms (14 ms × 10 000), czyli 140 sekund, ponieważ pliki są przenoszone kolejno, po jednym na raz. Czas obsługi każdego żądania zależy przede wszystkim od tego, jak blisko siebie znajdują się zasoby obliczeniowe i magazyn, zgodnie z opisem w poprzedniej sekcji.
Używając ośmiu wątków zamiast jednego, można zmniejszyć poprzednie obciążenie z 140 000 ms (140 sekund) do 17 500 ms (17,5 sekund). Jak pokazano w poniższej tabeli, podczas przenoszenia ośmiu plików równolegle zamiast jednego pliku jednocześnie, można przenieść tę samą ilość danych w 87,5% mniej czasu.
| Operacja we/wy | Utwórz | Zapis 4 KiB | Zapis 4 KiB | Zapis 4 KiB | Zapis 4 KiB | Zamknij | Łącznie |
|---|---|---|---|---|---|---|---|
| Wątek 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 2 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 3 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 4 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 5 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 6 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 7 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 8 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |