Verstehen und Optimieren der Leistung von Azure-Dateifreigaben

✔️ Gilt für: Klassische SMB- und NFS-Dateifreigaben, die mit dem Microsoft.Storage-Ressourcenanbieter erstellt wurden

✔️ Gilt für: Dateifreigaben, die mit dem Microsoft.FileShares-Ressourcenanbieter erstellt wurden

Azure Files kann Leistungsanforderungen für die meisten Anwendungen und Anwendungsfälle erfüllen. In diesem Artikel werden die verschiedenen Faktoren erläutert, die sich auf die Leistung von Dateifreigaben auswirken, und es wird beschrieben, wie Sie die Leistung von Azure Files für Ihre Workloads optimieren können.

Glossar zur Speicherleistung

Bevor Sie diesen Artikel lesen, ist es hilfreich, einige wichtige Begriffe im Zusammenhang mit der Speicherleistung zu verstehen:

  • E/A-Vorgänge pro Sekunde (IOPS)

    „IOPS“ oder „Eingabe-/Ausgabevorgänge pro Sekunde“ misst die Anzahl von Dateisystemvorgängen pro Sekunde. In der Azure Files Dokumentation ist der Begriff "IO" mit den Begriffen "Operation" und "transaction" austauschbar.

  • E/A-Größe

    Die E/A-Größe, manchmal auch als Blockgröße bezeichnet, ist die Größe der Anforderung, die eine Anwendung zum Ausführen eines einzelnen Eingabe-/Ausgabevorgangs (E/A-Vorgang) für den Speicher verwendet. Je nach Anwendung kann die E/A-Größe von kleinen Größen wie 4 KiB bis zu größeren Größen reichen. Die E/A-Größe spielt eine wichtige Rolle für den erreichbaren Durchsatz.

  • Durchsatz

    Der Durchsatz misst die Anzahl der Bits, die pro Sekunde aus dem Speicher gelesen oder in den Speicher geschrieben werden, und wird in Mebibytes pro Sekunde (MiB/s) gemessen. Um den Durchsatz zu berechnen, multiplizieren Sie den IOPS-Wert mit der E/A-Größe. Beispiel: 10.000 IOPS × 1 MiB I/O-Größe = 10 GiB/s, während 10.000 IOPS × 4 KiB-E/A-Größe = 38 MiB/s.

  • Latenz

    Latenz ist ein Synonym für Verzögerung und wird in Millisekunden (ms) gemessen. Es gibt zwei Arten von Latenz: End-to-End-Latenz und Dienstlatenz. Weitere Informationen finden Sie unter Latenz.

  • Warteschlangenlänge

    Warteschlangentiefe ist die Anzahl der ausstehenden E/A-Anforderungen, die eine Speicherressource gleichzeitig verarbeiten kann. Weitere Informationen finden Sie unter Warteschlangentiefe.

Auswählen einer Medienebene basierend auf Verwendungsmustern

Azure Files bietet zwei Speichermedienebenen, mit denen Sie die Leistung und den Preis ausgleichen können: SSD und HDD. Sie wählen die Medienebene für die Dateifreigabe auf Speicherkontoebene aus. Nachdem Sie ein Speicherkonto auf einer bestimmten Medienebene erstellt haben, können Sie nicht zur anderen Medienebene wechseln, ohne manuell zu einer neuen Dateifreigabe zu migrieren.

Wenn Sie zwischen SSD- und HDD-Dateifreigaben wählen, sollten Sie die Anforderungen des erwarteten Verwendungsmusters berücksichtigen, das Sie für Azure Files ausführen möchten. Wenn Sie große Mengen an IOPS, schnelle Datenübertragungsgeschwindigkeiten oder geringe Latenz benötigen, wählen Sie SSD-Dateifreigaben aus.

In der folgenden Tabelle sind die erwarteten Leistungsziele zwischen SSD- und HDD-Dateifreigaben zusammengefasst. Weitere Informationen finden Sie unter Skalierbarkeits- und Leistungsziele für Azure Files.

Nutzungsmusteranforderungen SSD HDD
Schreiblatenz (im einstelligen Millisekundenbereich) Ja Ja
Leselatenz (im einstelligen Millisekundenbereich) Ja Nein

SSD-Dateifreigaben verwenden ein Provisionierungsmodell, das abhängig von der Größe der Freigabe das folgende Leistungsprofil garantiert. Weitere Informationen finden Sie unter bereitgestelltes V1-Modell.

Bewährte Verfahren für Leistungsoptimierung

Ganz gleich, ob Sie die Leistungsanforderungen für eine neue oder vorhandene Arbeitslast bewerten, indem Sie Ihre Nutzungsmuster verstehen, können Sie eine vorhersehbare Leistung sicherstellen.

  • Latenzempfindlichkeit: Workloads, die empfindlich auf Leselatenz reagieren und für Endbenutzer besonders sichtbar sind, eignen sich besser für SSD-Dateifreigaben, die sowohl für Lese- als auch für Schreibvorgänge eine Latenz im einstelligen Millisekundenbereich bieten können (weniger als 2 ms bei kleinen E/A-Größen).

  • IOPS- und Durchsatzanforderungen: SSD-Dateifreigaben unterstützen größere IOPS- und Durchsatzgrenzwerte als HDD-Dateifreigaben. Weitere Informationen finden Sie unter Skalierungsziele für die Dateifreigabe.

  • Dauer und Häufigkeit von Workloads: Kurze (Minuten) und seltene (stündliche) Workloads stoßen mit geringerer Wahrscheinlichkeit an die oberen Leistungsgrenzen von HDD-Dateifreigaben als lang andauernde, häufig auftretende Workloads. Bei SSD-Dateifreigaben hilft die Workload-Dauer dabei, das richtige Leistungsprofil zu ermitteln, das basierend auf dem bereitgestellten Speicher, IOPS und Durchsatz verwendet werden soll. Ein häufiger Fehler ist das Ausführen von Leistungstests nur für ein paar Minuten, was oft irreführend ist. Um eine realistische Leistung zu bekommen, solltest du sicherstellen, dass du mit ausreichend hoher Frequenz und Dauer testest. Bei bereitgestellten Dateifreigaben kann ein kurzer Test kreditbasierte Burst-IOPS anstelle von provisionierten IOPS messen. Weitere Informationen finden Sie unter Bursting.

  • Workload-Parallelisierung: Für Workloads, die Vorgänge parallel ausführen, z. B. durch mehrere Threads, Prozesse oder Anwendungsinstanzen auf demselben Client, bieten SSD-Dateifreigaben einen klaren Vorteil gegenüber HDD-Dateifreigaben: SMB Multichannel. Weitere Informationen finden Sie unter Verbessern der SMB-Azure-Dateifreigabeleistung.

  • Verteilung der API-Operationen: Metadatenintensive Workloads, wie z. B. Workloads, die Lesevorgänge für eine große Anzahl von Dateien ausführen, eignen sich besser für SSD-Dateifreigaben. Weitere Informationen finden Sie unter "Metadaten" oder "Namespace heavy workload".

  • Zonenplatzierung: Verwenden Sie die Zonenplatzierung, um die spezifische Verfügbarkeitszone auszuwählen, in der sich Ihr Speicherkonto befindet. Mit diesem Feature können Sie Ihre virtuellen Computer in derselben Verfügbarkeitszone wie Ihr Speicher platzieren, wodurch die Latenz um bis zu 30 Prozent reduziert werden kann. Dieses Feature ist derzeit nur für SSD-Speicherkonten verfügbar, die lokal redundanten Speicher (LRS) in unterstützten Regionen verwenden.

Bursting

Dateifreigaben, die das bereitgestellte v2- oder provisionierte v1-Abrechnungsmodell verwenden, unterstützen kreditbasiertes IOPS-Bursting. Kreditbasiertes Bursting ermöglicht es einer Dateifreigabe, für eine begrenzte Zeit mehr IOPS zu verwenden, als ihr bereitgestellt wurden. Credit-basiertes Bursting ist eine Funktion der Dateifreigabe. Bursty Traffic ist ein Workload-Muster mit kurzen Spitzen bei IOPS oder Durchsatz. Credit-basiertes Bursting kann kurze IOPS-Spitzen durch stoßartigen Datenverkehr absorbieren.

Kreditbasiertes Bursting ist in den Kosten der bereitgestellten Dateifreigabe enthalten und fügt keine Gebühren zu Ihrer Rechnung hinzu. Credit-basiertes Bursting gilt nur für IOPS. Es erhöht den Durchsatz nicht über den bereitgestellten Durchsatz.

Bursting gilt nicht für Pay-as-you-go-Dateifreigaben. Klassische Dateifreigaben, die bursten, unterliegen weiterhin den IOPS-Limits des Speicherkontos. Weitere Informationen finden Sie unter Classic File Share Data Plane Limits. Informationen darüber, wie Bursting die Kosten beeinflusst, finden Sie unter Understand Azure Files billing.

Bereitgestelltes v2-Bursting

Auf Kredit basierende IOPS-Bursts bieten zusätzliche Flexibilität bei der IOPS-Nutzung. Verwenden Sie diese Flexibilität als Puffer gegen unvorhergesehene E/A-Spitzen. Bei etablierten E/A-Mustern planen Sie E/A-Spitzen ein.

IOPS-Burst-Credits häufen sich an, wenn Datenverkehr für Ihre Dateifreigabe unterhalb der bereitgestellten IOPS (Baseline) liegt. Wenn die IOPS-Nutzung einer Dateifreigabe die bereitgestellten IOPS überschreitet und IOPS-Burstcredits verfügbar sind, kann die Dateifreigabe bis zum maximal zulässigen IOPS-Grenzwert Bursts verwenden. Dateifreigaben können weiterhin Bursts ausführen, solange Credits verbleiben. Dies hängt aber von der Anzahl der aufgelaufenen Burst-Credits ab. Jede E/A über die bereitgestellte IOPS hinaus verbraucht einen Credit. Nachdem alle Credits verbraucht wurden, kehrt der Anteil zum bereitgestellten IOPS zurück. IOPS für die Dateifreigabe muss nichts Besonderes tun, um Bursting zu verwenden. Bursting arbeitet auf Best-Effort-Basis.

Freigabeguthaben können drei Zustände aufweisen:

  • Ansammelnd, wenn die Dateifreigabe weniger als die bereitgestellte IOPS verwendet.
  • Abnehmend, wenn die Dateifreigabe mehr als die bereitgestellten IOPS verwendet und sich im Burstmodus befindet.
  • Konstant, wenn die Dateifreigabe genau die bereitgestellten IOPS nutzt und entweder keine Guthaben angesammelt oder verbraucht wurden.

Eine neue Dateifreigabe beginnt mit der vollen Anzahl von Guthaben im Burstbucket. Burstcredits sammeln sich nicht an, wenn die Freigabe-IOPS aufgrund einer Einschränkung durch den Server unter die bereitgestellte Grenze fällt. Die folgenden Formeln werden verwendet, um den IOPS-Burstgrenzwert und die Anzahl der für eine Dateifreigabe möglichen Credits zu bestimmen:

Item SSD-Formel HDD-Formel
IOPS-Burstgrenzwert MIN(MAX(3 * ProvisionedIOPS, 10000), 102400) MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)
IOPS-Burstcredits (BurstLimit - ProvisionedIOPS) * 3600 (BurstLimit - ProvisionedIOPS) * 3600

In der folgenden Tabelle sind einige Beispiele für diese Formeln für verschiedene bereitgestellte IOPS-Beträge dargestellt:

Bereitgestellte IOPS SSD-Burst-IOPS-Grenzwert SSD-Burst-Guthaben IOPS-Grenzwert bei HDD-Burst HDD-Burstcredits
500 -- -- Bis zu 5.000 16.200.000
1,000 -- -- Bis zu 5.000 14.400.000
3,000 Bis zu 10.000 25,200,000 Bis zu 9.000 21.600.000
5,000 Bis zu 15.000 36.000.000 Bis zu 15.000 36.000.000
10,000 Bis zu 30.000 72.000.000 Bis zu 30.000 72.000.000
25,000 Bis zu 75.000 180,000,000 Bis zu 50.000 90.000.000
50,000 Bis zu 102 400 188,640,000 Bis zu 50.000 0
75,000 Bis zu 102 400 98,640,000 -- --
102,400 Bis zu 102 400 0 -- --

Bereitgestelltes v1-Bursting

Das bereitgestellte v1-Modell unterstützt zwei Arten von Bursting: kreditbasiertes Bursting, das ohne zusätzliche Kosten enthalten ist, und kostenpflichtiges Bursting, das optional aktiviert werden kann, um IOPS und Durchsatz über die bereitgestellte Kapazität hinaus gegen nutzungsbasierte Gebühren zu ermöglichen.

Bereitgestelltes v1 kreditbasiertes Bursting

Auf Kredit basierende IOPS-Bursts bieten zusätzliche Flexibilität bei der IOPS-Nutzung. Verwenden Sie diese Flexibilität als Puffer gegen unvorhergesehene E/A-Spitzen. Bei etablierten E/A-Mustern planen Sie E/A-Spitzen ein.

IOPS-Burst-Credits häufen sich an, wenn der Datenverkehr für Ihre klassische Dateifreigabe unterhalb der bereitgestellten IOPS (Baseline) liegt. Wenn die IOPS-Nutzung einer klassischen Dateifreigabe die bereitgestellten IOPS überschreitet und IOPS-Burstcredits verfügbar sind, kann die klassische Dateifreigabe bis zum maximal zulässigen IOPS-Grenzwert Bursts verwenden. Klassische Dateifreigaben können weiterhin Bursts ausführen, solange Credits verbleiben. Dies hängt aber von der Anzahl der aufgelaufenen Burst-Credits ab. Jede E/A über die bereitgestellte IOPS hinaus verbraucht einen Credit. Nachdem alle Gutschriften verbraucht sind, kehrt die klassische Dateifreigabe zum bereitgestellten IOPS zurück. Für IOPS für die klassische Dateifreigabe sind keine besonderen Maßnahmen erforderlich, um Bursting zu verwenden. Bursting arbeitet auf Best-Effort-Basis.

Freigabeguthaben können drei Zustände aufweisen:

  • Anwachsend, wenn die klassische Dateifreigabe weniger als die bereitgestellten IOPS verwendet.
  • Abnehmend, wenn die klassische Dateifreigabe mehr als die bereitgestellten IOPS verwendet und sich im Burstmodus befindet.
  • Konstant, wenn die klassische Dateifreigabe genau die bereitgestellten IOPS nutzt und weder Gutschriften angesammelt noch verwendet werden.

Eine neue klassische Dateifreigabe beginnt mit der vollständigen Anzahl von Guthaben im Burst-Bucket. Burstcredits sammeln sich nicht an, wenn die Freigabe-IOPS aufgrund einer Einschränkung durch den Server unter die bereitgestellte Grenze fällt. Die folgenden Formeln werden verwendet, um den IOPS-Burstgrenzwert und die Anzahl der für eine klassische Dateifreigabe möglichen Credits zu bestimmen:

Item Formel
Burstgrenzwert MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)
Burstguthaben (BurstLimit - BaselineIOPS) * 3600

In der folgenden Tabelle sind einige Beispiele für diese Formeln für die bereitgestellten Größen dargestellt:

Kapazität (GiB) Basis-IOPS Burst-IOPS Burstguthaben Durchsatz (MiB/Sek.)
100 3.100 Bis zu 10.000 24.840.000 110
500 3,500 Bis zu 10.000 23.400.000 150
1,024 4.024 Bis zu 10.000 21.513.600 203
5\.120 8.120 Bis zu 15.360 26.064.000 613
10.240 13.240 Bis zu 30.720 62.928.000 1.125
33.792 36.792 Bis zu 102 400 227.548.800 3\.480
51.200 54.200 Bis zu 102 400 164.880.000 5.220
102,400 102,400 Bis zu 102 400 0 10.340

Bereitgestellte v1 kostenpflichtige Platzierung

Kostenpflichtige Aufstockung ist ein erweitertes Feature des „Bereitgestellt v1“-Modells, das Kunden unterstützt, die nie gedrosselt werden möchten. Kostenpflichtiges Bursting beinhaltet eine zusätzliche nutzungsbasierte Abrechnung für jeden IOPS oder Durchsatz, der über den bereitgestellten Speicherplatz hinausgeht. Diese Funktion unterscheidet sich vom guthabenbasierten Bursting, das im Rahmen des bereitgestellten Speichers kostenlos enthalten ist. Kostenpflichtiges Bursting kann zwar die Bereitstellung Ihrer klassischen Dateifreigabe erheblich flexibler gestalten, bei falscher Verwendung jedoch auch zu unerwarteten Abrechnungen führen.

Wie kreditbasiertes Bursting ist kostenpflichtiges Bursting kein Ersatz für die Bereitstellung der richtigen Menge an IOPS und Durchsatz. Vielmehr bietet es zusätzlichen Schutz vor einer Drosselung, falls eine unerwartete Nachfrage erfolgt. Wenn Sie über ein konsistentes Maß an IOPS oder Durchsatz verfügen, ist es günstiger, genügend IOPS und Durchsatz (durch Speicherbereitstellung) bereitzustellen, um die Nachfrage abzudecken, anstatt auf kostenpflichtiges Bursting zu vertrauen.

Kostenpflichtiges Bursting ist standardmäßig deaktiviert, Sie können es jedoch aktivieren, indem Sie die Anweisungen befolgen, um die Kosten- und Leistungsmerkmale einer bereitgestellten klassischen v1-Dateifreigabe zu ändern ( nur PowerShell und CLI). Wenn Sie kostenpflichtiges Bursting aktivieren, überwachen Sie die IOPS- und Durchsatznutzung mithilfe der folgenden Metriken, die über Azure Monitor verfügbar sind:

  • Bereitgestellte IOPS für Dateifreigaben
  • Bereitgestellte Bandbreite MiB/s für Dateifreigabe (Durchsatz)
  • Transaktionen von Max IOPS
  • Bandbreite nach Max MiB/s (Durchsatz)
  • Platzguthaben für IOPS (kreditbasiertes Bursting)
  • Paid Bursting IOS (IOs)
  • Kostenpflichtige Platzbandbreite

Latenz

Wenn Sie sich die Latenz überlegen, verstehen Sie zunächst, wie Azure Files die Latenz bestimmt. Die häufigsten Messwerte sind die Latenzmetriken im Zusammenhang mit End-to-End-Latenz und Dienstlatenz. Mithilfe dieser Transaktionsmetriken können Sie clientseitige Latenz- und Netzwerkprobleme ermitteln, indem Sie zeigen, wie viel Zeit ihr Anwendungsdatenverkehr während der Übertragung auf und vom Client verbringt.

  • End-to-End-Latenz (SuccessE2ELatency) ist die Gesamtdauer, die eine Transaktion benötigt, um einen vollständigen Roundtrip vom Client über das Netzwerk zum Azure Files-Dienst und zurück zum Client durchzuführen.

  • Die Dienstlatenz (SuccessServerLatency) ist die Zeit, die eine Transaktion für einen Hin- und Rückweg ausschließlich innerhalb von Azure Files benötigt. Diese Messung enthält keine Client- oder Netzwerklatenz.

    Diagramm des Vergleichs von Clientlatenz und Dienstlatenz für Azure Files.

Der Unterschied zwischen SuccessE2ELatency- und SuccessServerLatency-Werten ist die Latenz, die wahrscheinlich durch das Netzwerk und/oder den Client verursacht wird.

Es ist üblich, Clientlatenz mit Dienstlatenz zu verwechseln (in diesem Fall Azure Files-Leistung). Wenn z. B. für die Dienstlatenz eine niedrige Latenz und für die End-to-End-Latenz eine sehr hohe Latenz bei Anforderungen gemeldet wird, entfällt die gesamte Zeit auf die Übertragung zum und vom Client und nicht auf den Azure Files-Dienst.

Darüber hinaus ist, wie das Diagramm veranschaulicht, je weiter Sie vom Dienst entfernt sind, desto langsamer ist die Latenzerfahrung und desto schwieriger ist es, Leistungsskalierungsgrenzwerte mit jedem Clouddienst zu erreichen. Diese Bedingung gilt insbesondere für den Zugriff auf Azure Files von der lokalen Bereitstellung. Optionen wie Azure ExpressRoute eignen sich zwar ideal für lokale Bereitstellungen, stimmen aber trotzdem nicht mit der Leistung einer Anwendung (Compute + Speicher) überein, die ausschließlich in derselben Azure Region ausgeführt wird.

Tipp

Die Verwendung einer VM in Azure zum Testen der Leistung zwischen der lokalen Umgebung und Azure ist eine effektive und praktische Möglichkeit, um eine Baseline für die Netzwerkfunktionen der Verbindung mit Azure zu ermitteln. Untergeordnete oder falsch weitergeleitete ExpressRoute-Schaltkreise oder VPN-Gateways können Workloads, die auf Azure Files ausgeführt werden, erheblich verlangsamen.

Warteschlangenlänge

Die Warteschlangentiefe ist die Anzahl der ausstehenden E/A-Anforderungen, die eine Speicherressource verarbeiten kann. Da sich die von Speichersystemen verwendeten Datenträger von HDD-Spindeln (IDE, SATA, SAS) zu Solid-State-Geräten (SSD, NVMe) entwickelten, entwickelten sie sich auch zur Unterstützung einer höheren Warteschlangentiefe. Eine Workload, die aus einem einzelnen Client besteht, der seriell mit einer einzelnen Datei innerhalb eines großen Datasets interagiert, ist ein Beispiel für eine geringe Warteschlangentiefe. Im Gegensatz dazu kann eine Workload, die Parallelität mit mehreren Threads und mehreren Dateien unterstützt, problemlos eine große Warteschlangentiefe erzielen. Da Azure Files ein verteilter Dateidienst ist, der tausende von Azure Clusterknoten umfasst und für die Ausführung von Workloads im Maßstab konzipiert ist, erstellen und testen Sie Workloads mit hoher Warteschlangentiefe.

Sie können eine hohe Warteschlangentiefe auf verschiedene Arten erreichen. Um die Warteschlangentiefe für Ihre Workload zu ermitteln, multiplizieren Sie die Anzahl der Clients mit der Anzahl der Dateien mit der Anzahl der Threads (Clients × Dateien × Threads = Warteschlangentiefe).

In der folgenden Tabelle sind die verschiedenen Kombinationen dargestellt, die Sie verwenden können, um eine höhere Warteschlangentiefe zu erzielen. Sie können zwar die optimale Warteschlangentiefe von 64 überschreiten, es wird jedoch nicht empfohlen. Wenn Sie so vorgehen, erreichen Sie keine weiteren Leistungssteigerungen, und Sie riskieren, die Latenz aufgrund von TCP-Sättigung zu erhöhen.

Klienten Dateien Threads Warteschlangenlänge
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

Tipp

Um höhere Leistungsbeschränkungen zu erreichen, stellen Sie sicher, dass Ihr Workload- oder Benchmarking-Test mit mehreren Dateien multithreadiert wird.

Einzelthread- und Multithreadanwendungen

Azure Files funktioniert am besten mit Multithread-Anwendungen. Am einfachsten lässt sich der Leistungseinfluss von Multithreading auf eine Arbeitslast verstehen, indem man das Szenario anhand der E/A-Operationen durchgeht. Im folgenden Beispiel haben Sie einen Workload, der 10.000 kleine Dateien so schnell wie möglich in eine Azure-Dateifreigabe oder aus einer Azure-Dateifreigabe kopieren muss.

In dieser Tabelle wird die erforderliche Zeit (in Millisekunden) zum Erstellen einer einzelnen 16-KiB-Datei auf einer Azure-Dateifreigabe anhand einer Einzelthreadanwendung aufschlüsselt, die in 4 KiB-Blockgrößen schreibt.

E/A-Vorgang Erstellen 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang Close Gesamt
Thread 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

In diesem Beispiel dauert es ungefähr 14 ms, um eine einzelne 16 KiB-Datei aus den sechs Vorgängen zu erstellen. Wenn eine Singlethread-Anwendung 10.000 Dateien in eine Azure-Dateifreigabe verschieben möchte, entspricht dies 140.000 ms (14 ms × 10.000) bzw. 140 Sekunden, weil die Dateien sequenziell, also einzeln nacheinander, verschoben werden. Die Zeit zum Warten jeder Anforderung wird in erster Linie durch die Nähe der Berechnung und des Speichers bestimmt, wie im vorherigen Abschnitt erläutert.

Wenn Sie acht Threads anstelle eines Threads verwenden, können Sie die vorhergehende Arbeitsauslastung von 140.000 ms (140 Sekunden) auf 17.500 ms (17,5 Sekunden) reduzieren. Wie in der folgenden Tabelle dargestellt, können Sie, wenn Sie acht Dateien parallel anstelle einer Datei gleichzeitig verschieben, die gleiche Datenmenge in 87,5% weniger Zeit verschieben.

E/A-Vorgang Erstellen 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang Close Gesamt
Thread 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Weitere Informationen