Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
✔️ 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.
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 |