Checkliste zu Leistung und Skalierbarkeit für Queue Storage
Microsoft hat viele bewährte Methoden für die Entwicklung leistungsstarker Anwendungen mit Queue Storage zusammengestellt. Diese Checkliste enthält wichtige Methoden, mit denen Entwickler die Leistung optimieren können. Beachten Sie diese Methoden beim Entwerfen einer Anwendung und während des gesamten Prozesses.
Azure Storage verfügt über Skalierbarkeits- und Leistungsziele für die Kapazität, Transaktionsrate und Bandbreite. Weitere Informationen zu Azure Storage-Skalierbarkeitszielen finden Sie unter Skalierbarkeits- und Leistungsziele für Standardspeicherkonten und Skalierbarkeits- und Leistungsziele für Queue Storage.
Checkliste
In diesem Artikel werden bewährte Methoden für die Leistung in einer Checkliste zusammengefasst, an der Sie sich beim Entwickeln Ihrer Queue Storage-Anwendung orientieren können.
Skalierbarkeitsziele
Wenn Ihre Anwendung eines der Skalierbarkeitsziele erreicht oder überschreitet, kann es zu erhöhter Transaktionslatenz oder Drosselung kommen. Wenn Azure Storage Ihre Anwendung drosselt, beginnt der Dienst mit der Rückgabe der Fehlercodes 503 (Server Busy) oder 500 (Operation Timeout). Diese Fehler zu vermeiden, indem Sie innerhalb der Grenzwerte der Skalierbarkeitsziele bleiben, trägt maßgeblich dazu bei, die Leistung Ihrer Anwendung zu verbessern.
Weitere Informationen zu den Skalierbarkeitszielen für Queue Storage finden Sie unter Skalierbarkeits- und Leistungsziele in Azure Storage.
Maximale Anzahl von Speicherkonten
Wenn Sie die maximal zulässige Anzahl von Speicherkonten für eine bestimmte Kombination aus Abonnement und Region fast erreicht haben: Verwenden Sie mehrere Speicherkonten zur horizontalen Partitionierung, um den ein- und ausgehenden Datenverkehr, die E/A-Vorgänge pro Sekunde (IOPS) oder die Kapazität zu erhöhen? In diesem Szenario empfiehlt Microsoft, höhere Grenzwerte für Speicherkonten zu nutzen, um möglichst die Anzahl der Speicherkonten zu verringern, die für Ihre Workload erforderlich sind. Wenden Sie sich an den Azure-Support, wenn Sie höhere Grenzwerte für Ihr Speicherkonto benötigen.
Kapazitäts- und Transaktionsziele
Wenn sich Ihre Anwendung den Skalierbarkeitszielen für ein Speicherkonto nähert, sollten Sie eine der folgenden Vorgehensweisen wählen:
- Wenn die Skalierbarkeitsziele für Warteschlangen nicht für Ihre Anwendung ausreichen, sollten Sie mehrere Warteschlangen verwenden, auf die Sie Nachrichten verteilen.
- Berücksichtigen Sie die Arbeitsauslastung, aufgrund derer Ihre Anwendung das Skalierbarkeitsziel erreicht oder überschreitet. Können Sie diese anders konzipieren, um weniger Bandbreite bzw. Kapazität oder weniger Transaktionen zu verwenden?
- Wenn Ihre Anwendung eines der Skalierbarkeitsziele überschreiten muss, erstellen Sie mehrere Speicherkonten, und partitionieren Sie Ihre Anwendungsdaten über diese Speicherkonten hinweg. Konzipieren Sie in diesem Fall die Anwendung so, dass Sie künftig weitere Speicherkonten für den Lastenausgleich hinzufügen können. Speicherkonten selbst verursachen abgesehen von den Nutzungskosten für gespeicherte Daten, durchgeführte Transaktionen oder übertragene Daten keine Kosten.
- Wenn sich Ihre Anwendung den Bandbreitenzielen nähert, versuchen Sie, Daten clientseitig zu komprimieren, um die erforderliche Bandbreite zum Senden der Daten an Azure Storage zu reduzieren. Die Komprimierung von Daten kann zwar Bandbreite sparen und die Netzwerkleistung verbessern, aber auch negative Auswirkungen auf die Leistung haben. Beobachten Sie, wie sich der zusätzliche Verarbeitungsbedarf für das Komprimieren und Dekomprimieren der Daten auf dem Client auf die Leistung auswirkt. Bedenken Sie, dass das Speichern von komprimierten Daten die Problembehandlung erschweren kann, da es schwieriger sein kann, die Daten mithilfe von Standardtools anzuzeigen.
- Wenn sich Ihre Anwendung den Skalierbarkeitszielen nähert, sollten Sie unbedingt ein exponentielles Backoff für Wiederholungsversuche verwenden. Sie sollten die in diesem Artikel beschriebenen Empfehlungen umsetzen, um zu verhindern, dass die Skalierbarkeitsziele erreicht werden. Durch die Verwendung eines exponentiellen Backoffs für Wiederholungsversuche wird jedoch verhindert, dass Ihre Anwendung Vorgänge schnell wiederholen kann, wodurch sich die Drosselung verschlechtern kann. Weitere Informationen finden Sie im Abschnitt Timeoutfehler und Fehler durch ausgelasteten Server.
Netzwerk
Die physischen Netzwerkeinschränkungen der Anwendung können erhebliche Auswirkungen auf die Leistung haben. In den folgenden Abschnitten werden einige Einschränkungen beschrieben, die Benutzer*innen bemerken können.
Client-Netzwerkkapazität
Wie in den folgenden Abschnitten beschrieben, sind die Bandbreite und die Qualität der Netzwerkverbindung entscheidend für die Anwendungsleistung.
Throughput
Bei der Bandbreite liegt das Problem häufig in der Clientkapazität. Größere Azure-Instanzen verfügen über NICs mit höherer Kapazität. Daher sollten Sie erwägen, eine größere Instanz oder mehr VMs zu verwenden, wenn Sie höhere Netzwerkgrenzwerte auf einem einzelnen Computer benötigen. Wenn Sie von einer lokalen Anwendung aus auf Azure Storage zugreifen, gilt dieselbe Regel: Informieren Sie sich über die Netzwerkkapazität des Clientgeräts und die Netzwerkverbindung mit dem Azure Storage-Speicherort, und optimieren Sie diese, oder entwerfen Sie Ihre Anwendung entsprechend diesen Kapazitätsgrenzen.
Verbindungsqualität
Wie bei jeder Netzwerknutzung ist zu beachten, dass Netzwerkbedingungen, die zu Fehlern und Paketverlusten führen, den effektiven Durchsatz verringern. Die Verwendung von Wireshark oder Netzwerkmonitor kann bei der Diagnose dieses Problems helfen.
Standort
In jeder verteilten Umgebung wird die beste Leistung erzielt, indem der Client in der Nähe des Servers platziert wird. Zum Zugriff auf den Azure-Speicher mit der niedrigsten Latenz befindet sich der beste Standort für den Client innerhalb derselben Azure-Region. Wenn Sie beispielsweise eine Azure-Web-App haben, die Azure Storage verwendet, sollten Sie beide in derselben Region bereitstellen (z. B. „USA, Westen“ oder „Asien, Südosten“). Durch die räumliche Zusammenlegung von Ressourcen werden die Wartezeit und die Kosten verringert, da die Bandbreitennutzung innerhalb einer Region kostenlos ist.
Wenn Clientanwendungen auf Azure Storage zugreifen, aber nicht in Azure gehostet werden (z. B. Apps für mobile Geräte oder lokale Unternehmensdienste), können Sie die Wartezeit verkürzen, indem Sie für das Speicherkonto eine Region in der Nähe dieser Clients verwenden. Wenn Ihre Clients weit verteilt sind (z. B. einige in Nordamerika und andere in Europa), kann es sinnvoll sein, ein Speicherkonto pro Region zu verwenden. Diese Vorgehensweise ist einfacher zu implementieren, wenn die in der Anwendung gespeicherten Daten spezifisch für einzelne Benutzer*innen sind und keine Replikation von Daten zwischen Speicherkonten erforderlich ist.
SAS und CORS
Angenommen, Sie müssen im Webbrowser eines Benutzers oder in einer Mobiltelefon-App ausgeführten Code (z. B. JavaScript) für den Zugriff auf Daten in Azure Storage autorisieren. Eine Möglichkeit besteht darin, eine Dienstanwendung zu erstellen, die als Proxy fungiert. Das Gerät des Benutzers wird beim Dienst authentifiziert, der wiederum den Zugriff auf Azure Storage-Ressourcen autorisiert. Auf diese Weise müssen Sie den Speicherkontoschlüssel nicht gegenüber unsicheren Geräten offenbaren. Dieser Ansatz führt für die Dienstanwendung jedoch zu einem erheblichen Mehraufwand, da alle zwischen dem Benutzergerät und Azure Storage übertragenen Daten über die Dienstanwendung gesendet werden müssen.
Mit SAS (Shared Access Signature) können Sie die Verwendung einer Dienstanwendung als Proxy für Azure Storage vermeiden. SAS ermöglicht es dem Benutzergerät, Anforderungen mithilfe eines beschränkten Zugriffstokens direkt an Azure Storage zu senden. Wenn ein Benutzer beispielsweise ein Foto in Ihre Anwendung hochladen möchte, kann die Dienstanwendung eine SAS generieren und an das Gerät des Benutzers senden. Das SAS-Token kann die Berechtigung zum Schreiben in eine Azure Storage Ressource für einen bestimmten Zeitraum erteilen, nach dem das SAS-Token dann abläuft. Weitere Informationen zu SAS finden Sie unter Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signatures).
Normalerweise lassen Webbrowser nicht zu, dass JavaScript-Code auf einer Seite, die von einer Website in einer Domäne gehostet wird, bestimmte Vorgänge (z. B. Schreibvorgänge) in einer anderen Domäne ausführt. Diese als Richtlinie des gleichen Ursprungs bezeichnete Richtlinie verhindert, dass ein schädliches Skript auf einer Seite Zugriff auf Daten auf einer anderen Webseite erhält. Beim Erstellen einer Lösung in der Cloud kann sich die Richtlinie des gleichen Ursprungs jedoch als Einschränkung erweisen. CORS (Cross-Origin Resource Sharing) ist eine Browserfunktion, mit deren Hilfe die Zieldomäne dem Browser mitteilen kann, dass sie Anforderungen aus der Quelldomäne vertraut.
Angenommen, eine in Azure ausgeführte Webanwendung sendet eine Ressourcenanforderung an ein Azure Storage-Konto. Die Webanwendung ist die Quelldomäne und das Speicherkonto die Zieldomäne. Sie können CORS für alle Azure Storage-Dienste konfigurieren, um dem Webbrowser mitzuteilen, dass Azure Storage Anforderungen aus der Quelldomäne als vertrauenswürdig einstuft. Weitere Informationen zu CORS finden Sie unter Unterstützung von Cross-Origin Resource Sharing (CORS) für Azure Storage.
Sowohl SAS als auch CORS können Ihnen dabei helfen, eine unnötige Belastung Ihrer Webanwendung zu vermeiden.
.NET-Konfiguration
Für Projekte, die .NET Framework verwenden, sind in diesem Abschnitt einige Schnellkonfigurationseinstellungen aufgelistet, die eine deutliche Leistungsoptimierung bewirken. Wenn Sie eine andere Sprache als .NET verwenden, sollten Sie sich informieren, ob es ähnliche Konzepte für die jeweilige Sprache gibt.
Erhöhen des Standardverbindungslimits
Hinweis
Dieser Abschnitt gilt für Projekte, die .NET Framework verwenden, da das Verbindungspooling von der ServicePointManager-Klasse gesteuert wird. Mit .NET Core wurde eine bedeutende Änderung bei der Verwaltung von Verbindungspools eingeführt, die bewirkt, dass das Verbindungspooling auf HttpClient-Ebene erfolgt und die Poolgröße standardmäßig nicht begrenzt ist. Dies bedeutet, dass HTTP-Verbindungen automatisch skaliert werden, um Ihre Workload zu bewältigen. Es wird empfohlen, möglichst die neueste Version von .NET zu verwenden, um von Leistungsverbesserungen zu profitieren.
In Projekten, die .NET Framework verwenden, können Sie mit dem folgenden Code das Standardverbindungslimit (in der Regel 2 Verbindungen in einer Clientumgebung oder 10 in einer Serverumgebung) auf 100 erhöhen. In der Regel sollten Sie den Wert auf die ungefähre Anzahl der Threads, die von der Anwendung verwendet werden, setzen. Legen Sie das Verbindungslimit fest, bevor Sie Verbindungen öffnen.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Weitere Informationen zu den Grenzwerten für Verbindungspools in .NET Framework finden Sie unter Grenzwerte für Verbindungspools in .NET Framework und das neue Azure SDK für .NET.
Für andere Programmiersprachen erfahren Sie in der zugehörigen Dokumentation, wie Sie das Verbindungslimit festlegen.
Erhöhen der Mindestanzahl von Threads
Wenn Sie synchrone Aufrufe zusammen mit asynchronen Aufgaben verwenden, sollten Sie die Anzahl der Threads im Threadpool erhöhen:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Weitere Informationen finden Sie unter der ThreadPool.SetMinThreads-Methode.
Uneingeschränkte Parallelität
Parallelität kann sich positiv auf die Leistung auswirken. Bei der Verwendung von uneingeschränkter Parallelität ist jedoch Vorsicht geboten, da in diesem Fall keine Beschränkung für die Anzahl der Threads oder parallelen Anforderungen erzwungen wird. Beschränken Sie parallele Anforderungen zum Hoch- oder Herunterladen von Daten auf den Zugriff auf mehrere Partitionen im selben Speicherkonto oder auf mehrere Elemente in derselben Partition. Bei uneingeschränkter Parallelität können die Kapazität des Clientgeräts oder die Skalierbarkeitsziele des Speicherkontos überschritten werden, sodass es zu längeren Wartezeiten und Drosselung kommt.
Clientbibliotheken und -tools
Verwenden Sie für optimale Leistung immer die aktuellen Clientbibliotheken und -tools von Microsoft. Azure Storage-Clientbibliotheken sind für verschiedene Programmiersprachen verfügbar. Azure Storage unterstützt auch PowerShell und die Azure-Befehlszeilenschnittstelle (Azure CLI). Microsoft entwickelt diese Clientbibliotheken und -tools aktiv im Hinblick auf die Leistung, hält sie auf dem aktuellen Stand der Dienstversionen und stellt sicher, dass sie viele der bewährten Methoden für die Leistung intern umsetzen. Weitere Informationen finden Sie in der Azure Storage-Referenzdokumentation.
Behandeln von Dienstfehlern
Azure Storage gibt einen Fehler zurück, wenn der Dienst eine Anforderung nicht verarbeiten kann. Das Verständnis der Fehler, die Azure Storage in einem bestimmten Szenario zurückgeben kann, ist beim Optimieren der Leistung hilfreich.
Timeoutfehler und Fehler durch ausgelasteten Server
Azure Storage kann Ihre Anwendung drosseln, wenn sie sich den Skalierbarkeitsgrenzwerten nähert. In einigen Fällen kann Azure Storage eine Anforderung möglicherweise aufgrund vorübergehender Bedingungen nicht verarbeiten. In beiden Fällen gibt der Dienst möglicherweise einen Fehler vom Typ „503“ (Server Busy) oder „500“ (Timeout) zurück. Diese Fehler können auch auftreten, wenn der Dienst Datenpartitionen ausgleicht, um einen höheren Durchsatz zu ermöglichen. In der Regel wiederholt die Clientanwendung den Vorgang, der einen dieser Fehler verursacht. Wenn Azure Storage jedoch Ihre Anwendung drosselt, weil sie die Skalierbarkeitsziele überschreitet, oder wenn der Dienst die Anforderung aus einem anderen Grund nicht bedienen konnte, können aggressive Wiederholungsversuche das Problem verschlimmern. Aus diesem Grund wird eine Wiederholungsrichtlinie mit exponentiellem Backoff empfohlen (dies ist das Standardverhalten der Clientbibliotheken). Beispielsweise kann Ihre Anwendung nach 2 Sekunden, dann nach 4 Sekunden, nach 10 Sekunden und nach 30 Sekunden einen Wiederholungsversuch starten und dann komplett aufgeben. So kann die Anwendung die Last des Diensts deutlich reduzieren, anstatt Probleme, die zu einer Drosselung führen können, weiter zu verschärfen.
Vorgänge, die Verbindungsfehler auslösen, können sofort wiederholt werden, da diese Fehler nicht Ergebnis einer Drosselung sind und nur vorübergehend bestehen sollten.
Nicht behebbare Fehler
Die Clientbibliotheken berücksichtigen bei Wiederholungsversuchen, welche Fehler behoben werden können und welche nicht. Wenn Sie die Azure Storage-REST-API direkt aufrufen, sollten Sie bei einigen Fehlern keinen Wiederholungsversuch durchführen. Bei einem Fehler vom Typ 400 (Bad Request) hat die Clientanwendung beispielsweise eine Anforderung gesendet, die nicht verarbeitet werden konnte, weil sie nicht das erwartete Format hatte. Das erneute Senden dieser Anforderung führt jedes Mal zur selben Antwort, und daher sind Wiederholungsversuche hier nicht sinnvoll. Wenn Sie die Azure Storage-REST-API direkt aufrufen, sollten Sie die potenziellen Fehler kennen und wissen, ob ein Wiederholungsversuch durchgeführt werden sollte.
Weitere Informationen zu Azure Storage-Fehlercodes finden Sie unter Status- und Fehlercodes.
Deaktivieren des Nagle-Algorithmus
Der Nagle-Algorithmus ist in TCP/IP-Netzwerken weit verbreitet, um die Netzwerkleistung zu verbessern. Er ist jedoch nicht unter allen Umständen optimal (z. B. hoch interaktive Umgebungen). Der Nagle-Algorithmus wirkt sich auf die Leistung von Anforderungen an Azure Table Storage negativ aus. Deshalb sollten Sie ihn möglichst deaktivieren.
Nachrichtengröße
Die Leistung der Warteschlange und der Skalierbarkeit sinkt, wenn die Nachrichtengröße steigt. Fügen Sie einer Nachricht nur die Informationen hinzu, die der Empfänger benötigt.
Batchabruf
Sie können bis zu 32 Nachrichten aus einer Warteschlange in einem einzigen Vorgang abrufen. Der Batchabruf kann die Anzahl von Roundtrips aus der Clientanwendung reduzieren, was besonders bei Umgebungen mit langer Wartezeit (z. B. mobile Geräte) nützlich ist.
Abrufintervall für die Warteschlange
Die meisten Anwendungen fragen Nachrichten aus einer Warteschlange ab. Für die Anwendung kann es sich dabei um die größte Quelle für Transaktionen handeln. Wählen Sie das Abrufintervall mit Bedacht aus: Abrufe, die zu häufig stattfinden, können dazu führen, dass die Anwendung die Skalierbarkeitsziele für die Warteschlange erreicht. Bei 200.000 Transaktionen für 0,01 US-Dollar (zum Redaktionszeitpunkt) betragen die Kosten für einen einzelnen Prozessor, der im Monat einen Abruf pro Sekunde macht, jedoch weniger als 15 Cent. Daher sind Kosten üblicherweise kein Auswahlkriterium für das Abrufintervall.
Aktuelle Datenkosteninformationen finden Sie unter Preise für Azure Storage.
Ausführen eines Vorgangs zum Aktualisieren von Nachrichten
Sie können einen Vorgang zum Aktualisieren von Nachrichten ausführen, um das Unsichtbarkeits-Timeout zu erhöhen oder die Zustandsinformationen einer Nachricht zu aktualisieren. Dieser Ansatz kann effizienter sein als ein Workflow, bei dem ein Auftrag nach Abschluss jedes Auftragsschritts von einer Warteschlange in die nächste verschoben wird. Ihre Anwendung kann den Auftragsstatus in der Nachricht speichern und dann weiterarbeiten, anstatt die Nachricht jedes Mal für den nächsten Schritt erneut in die Warteschlange zu stellen. Beachten Sie, dass jeder Vorgang zum Aktualisieren von Nachrichten auf das Skalierbarkeitsziel angerechnet wird.
Anwendungsarchitektur
Verwenden Sie Warteschlangen, um die Anwendungsarchitektur skalierbar zu machen. Nachfolgend sind einige Möglichkeiten aufgelistet, wie Sie Warteschlangen verwenden können, um Ihre Anwendung skalierbarer zu gestalten:
- Sie können Warteschlangen verwenden, um Arbeits-Backlogs zur Verarbeitung zu erstellen und die Arbeitsauslastung in der Anwendung gleichmäßig zu verteilen. Sie können z. B. Benutzeranfragen in die Warteschlange stellen, um prozessorintensive Arbeiten durchzuführen, wie das Ändern der Größe hochgeladener Bilder.
- Sie können Warteschlangen verwenden, um Teile Ihrer Anwendung zu entkoppeln, damit diese unabhängig skaliert werden können. Beispielsweise kann ein Web-Front-End Umfrageergebnisse von Benutzern zur späteren Analyse und Speicherung in eine Warteschlange stellen. Sie können mehr Workerrollen-Instanzen hinzufügen, um die Warteschlangendaten nach Bedarf zu verarbeiten.