Verbessern der Leistung und Zuverlässigkeit von Azure Functions

Dieser Artikel enthält Anleitungen zur Verbesserung der Leistung und Zuverlässigkeit Ihrer serverlosen Funktions-Apps . Eine allgemeinere Reihe von Azure Functions bewährten Methoden finden Sie unter Azure Functions bewährte Methoden.

Im Folgenden werden bewährte Methoden zum Erstellen und Entwerfen ihrer serverlosen Lösungen mithilfe von Azure Functions beschrieben.

Vermeiden Sie Funktionen mit langer Ausführungszeit

Große, länger laufende Funktionen können zu unerwarteten Timeout-Problemen führen. Weitere Informationen zu den Timeouts für einen bestimmten Hostingplan finden Sie unter Funktionsapp-Timeoutdauer.

Eine Funktion kann aufgrund vieler Node.js Abhängigkeiten groß werden. Das Import von Abhängigkeiten kann auch zu erhöhten Ladezeiten führen, die unerwartete Timeouts verursachen. Abhängigkeiten werden sowohl explizit als auch implizit geladen. Ein einzelnes vom Code geladenes Modul kann eigene zusätzliche Module laden.

Gestalten Sie große Funktionen wann immer möglich in kleinere Funktionssätze um, die schnell zusammenarbeiten und Antworten zurückgeben. Eine Webhook- oder HTTP-Triggerfunktion kann z. B. eine Bestätigungsantwort innerhalb eines bestimmten Zeitlimits erfordern; Es ist üblich, dass Webhooks eine sofortige Antwort erfordern. Sie können die HTTP-Triggernutzlast an eine Warteschlange übergeben, die von einer Warteschlangentriggerfunktion verarbeitet werden soll. Mit diesem Ansatz können Sie die eigentliche Arbeit zurückstellen und eine sofortige Antwort zurückgeben.

Sicherstellen, dass Hintergrundaufgaben abgeschlossen sind

Wenn Ihre Funktion Aufgaben wie Rückrufe, Threads oder Prozesse startet, müssen diese abgeschlossen sein, bevor Ihr Funktionscode zurückkehrt. Da Azure Functions diese Hintergrundthreads nicht nachverfolgt, kann das Herunterfahren der Website unabhängig vom Status der Hintergrundthreads stattfinden, was zu unerwarteten Verhaltensweisen in Ihren Funktionen führen kann.

Wenn z. B. eine Funktion eine Hintergrundaufgabe startet und eine erfolgreiche Antwort zurückgibt, bevor die Aufgabe abgeschlossen wird, berücksichtigt die Funktionslaufzeit die Ausführung als erfolgreich abgeschlossen, unabhängig vom Ergebnis der Hintergrundaufgabe. Wenn diese Hintergrundaufgabe wesentliche Arbeiten ausführt, kann sie durch die Abschaltung der Website unterbrochen werden, sodass diese Arbeit in einem unbekannten Zustand bleibt.

Funktionsübergreifende Kommunikation

Durable Functions und Azure Logic Apps werden entwickelt, um Zustandsübergänge und die Kommunikation zwischen mehreren Funktionen zu verwalten.

Wenn Sie nicht Durable Functions oder Logik-Apps für die Integration mit mehreren Funktionen verwenden, sollten Sie Speicherwarteschlangen für die funktionsübergreifende Kommunikation verwenden. Der Hauptgrund dafür ist, dass Speicherwarteschlangen billiger und viel einfacher bereitzustellen sind als andere Speicheroptionen.

Einzelne Nachrichten in einer Speicherwarteschlange sind auf 64 KB begrenzt. Wenn Sie größere Nachrichten zwischen Funktionen übergeben müssen, kann eine Azure Service Bus Warteschlange verwendet werden, um Nachrichtengrößen bis zu 256 KB in der Standardebene und bis zu 100 MB in der Premium-Ebene zu unterstützen.

Service Bus Themen sind nützlich, wenn Sie vor der Verarbeitung nachrichtenfiltern müssen.

Event Hubs sind nützlich, um die Kommunikation mit hohem Volumen zu unterstützen.

Schreiben Sie Funktionen, die zustandslos sind

Funktionen sollten nach Möglichkeit zustandslos und idempotent sein. Ordnen Sie alle erforderlichen Statusinformationen Ihren Daten zu. Beispielsweise würde eine bestellung, die verarbeitet wird, wahrscheinlich über ein zugeordnetes state Mitglied verfügen. Eine Funktion kann eine Reihenfolge basierend auf diesem Zustand verarbeiten, während die Funktion selbst zustandslos bleibt.

Idempotent-Funktionen werden besonders bei Timertriggern empfohlen. Wenn Sie beispielsweise etwas haben, das unbedingt einmal pro Tag ausgeführt werden muss, schreiben Sie es, damit es jederzeit während des Tages mit denselben Ergebnissen ausgeführt werden kann. Die Funktion kann beendet werden, wenn es für einen bestimmten Tag keine Arbeit gibt. Auch wenn eine vorherige Ausführung nicht abgeschlossen wurde, sollte die nächste Ausführung an der Stelle aufgenommen werden, an der sie unterbrochen wurde. Dies ist besonders wichtig für nachrichtenbasierte Bindungen, die bei einem Fehler erneut versuchen. Weitere Informationen finden Sie unter Entwerfen von Azure Functions für identische Eingaben.

Schreiben von defensiven Funktionen

Angenommen, Ihre Funktion kann jederzeit eine Ausnahme haben. Entwerfen Sie Ihre Funktionen mit der Möglichkeit, während der nächsten Ausführung von einem vorherigen Fehlerpunkt fortzufahren. Betrachten Sie ein Szenario, das die folgenden Aktionen erfordert:

1. Abfrage für 10.000 Zeilen in einer Datenbank.
2. Erstellen Sie eine Warteschlangennachricht für jeden dieser Datensätze, die später verarbeitet werden sollen.

Je nachdem, wie komplex Ihr System ist, können Sie folgendes haben: Nachgeschaltete Dienste verhalten sich schlecht, Netzwerkausfälle oder Kontingentgrenzwerte erreicht usw. All diese Können ihre Funktion jederzeit beeinflussen. Sie müssen Ihre Funktionen so gestalten, dass sie darauf vorbereitet werden.

Wie reagiert Ihr Code, wenn nach dem Einfügen von 5.000 dieser Elemente in eine Warteschlange zur Verarbeitung ein Fehler auftritt? Verfolgen von Elementen in einem Set, das Sie abgeschlossen haben. Andernfalls können Sie sie beim nächsten Mal erneut einfügen. Diese Doppeleinfügung kann einen schwerwiegenden Einfluss auf Ihren Arbeitsablauf haben, also machen Sie Ihre Funktionen idempotent.

Wenn ein Warteschlangenelement bereits verarbeitet wurde, können Sie die Funktion als no-opverwenden.

Nutzen Sie abwehrende Maßnahmen, die bereits für Komponenten vorgesehen sind, die Sie in der Azure Functions Plattform verwenden. Siehe zum Beispiel Verarbeitung von Poison-Queue-Nachrichten in der Dokumentation zu Azure Storage Queue-Auslösern und -Bindungen.

Bei HTTP-basierten Funktionen sollten Sie API-Versionsverwaltungsstrategien mit Azure API Management in Betracht ziehen. Wenn Sie beispielsweise Ihre HTTP-basierte Funktions-App aktualisieren müssen, stellen Sie das neue Update in einer separaten Funktions-App bereit und verwenden API-Verwaltungsrevisionen oder -versionen, um Clients an die neue Version oder Revision zu leiten. Sobald alle Clients die Version oder Überarbeitung verwenden und keine weiteren Ausführungen in der vorherigen Funktions-App verbleiben, können Sie die vorherige Funktions-App aufheben.

Bewährte Methoden der Funktionsorganisation

Im Rahmen Ihrer Lösung können Sie mehrere Funktionen entwickeln und veröffentlichen. Diese Funktionen werden häufig in einer einzelnen Funktions-App zusammengefasst, können aber auch in separaten Funktions-Apps ausgeführt werden. In Premium- und dedizierten Hostingplänen (App Service) können mehrere Funktions-Apps auch die gleichen Ressourcen gemeinsam nutzen, indem sie im selben Plan ausgeführt werden. Wie Sie Ihre Funktionen und Funktions-Apps gruppieren, kann sich auf die Leistung, Skalierung, Konfiguration, Bereitstellung und Sicherheit Ihrer Gesamtlösung auswirken. Es gibt keine Regeln, die für jedes Szenario gelten. Berücksichtigen Sie daher die Informationen in diesem Abschnitt, wenn Sie Ihre Funktionen planen und entwickeln.

Organisieren von Funktionen für Leistung und Skalierung

Jede von Ihnen erstellte Funktion verfügt über einen Speicherbedarf. Obwohl der Ressourcenbedarf in der Regel gering ist, kann das Vorhandensein zu vieler Funktionen innerhalb einer Funktions-App zu einem langsameren Start Ihrer App auf neuen Instanzen führen. Dies bedeutet auch, dass die Gesamtspeicherauslastung Ihrer Funktions-App möglicherweise höher ist. Es ist schwer zu sagen, wie viele Funktionen in einer einzelnen App sein sollen, was von Ihrer jeweiligen Arbeitsauslastung abhängt. Wenn Ihre Funktion jedoch viele Daten im Arbeitsspeicher speichert, sollten Sie in einer einzelnen App weniger Funktionen verwenden.

Wenn Sie mehrere Funktions-Apps in einem einzigen Premium-Plan oder einem dedizierten Plan (App Service) ausführen, teilen diese Apps alle die gleichen Ressourcen, die dem Plan zugeordnet sind. Wenn Sie über eine Funktions-App verfügen, die eine viel höhere Speicheranforderung als die anderen aufweist, wird für jede Instanz, für die die App bereitgestellt wird, eine unverhältnismäßige Menge an Arbeitsspeicherressourcen verwendet. Da dadurch weniger Arbeitsspeicher für die anderen Apps in jeder Instanz verfügbar sein könnte, sollten Sie eine Funktions-App mit hohem Arbeitsspeicher wie diesem in ihrem eigenen separaten Hostingplan ausführen.

Überlegen Sie, ob Sie Funktionen mit unterschiedlichen Ladeprofilen gruppieren möchten. Wenn Sie beispielsweise über eine Funktion verfügen, die viele Tausende von Warteschlangennachrichten verarbeitet, und eine andere, die nur gelegentlich aufgerufen wird, aber hohe Speicheranforderungen aufweist, sollten Sie sie in separaten Funktions-Apps bereitstellen, damit sie ihre eigenen Ressourcengruppen erhalten und unabhängig voneinander skaliert werden.

Organisieren von Funktionen für Konfiguration und Bereitstellung

Funktions-Apps verfügen über eine host.json-Datei, die zum Konfigurieren des erweiterten Verhaltens von Funktionstriggern und der Azure Functions Laufzeit verwendet wird. Änderungen an der host.json Datei gelten für alle Funktionen innerhalb der App. Wenn Sie über einige Funktionen verfügen, die benutzerdefinierte Konfigurationen benötigen, sollten Sie sie in ihre eigene Funktions-App verschieben.

Alle Funktionen in Ihrem lokalen Projekt werden zusammen als Eine Reihe von Dateien für Ihre Funktions-App in Azure bereitgestellt. Möglicherweise müssen Sie einzelne Funktionen separat bereitstellen oder Features wie Bereitstellungsplätze für einige Funktionen und nicht für andere verwenden. In solchen Fällen sollten Sie diese Funktionen (in separaten Codeprojekten) für verschiedene Funktions-Apps bereitstellen.

Organisieren von Funktionen nach Berechtigungen

Verbindungszeichenfolgen und andere in den Anwendungseinstellungen gespeicherte Anmeldeinformationen geben allen Funktionen in der Funktions-App den gleichen Satz von Berechtigungen in der zugehörigen Ressource. Erwägen Sie, die Anzahl der Funktionen mit Zugriff auf bestimmte Anmeldeinformationen zu minimieren, indem Sie Funktionen, die diese Anmeldeinformationen nicht nutzen, in eine separate Funktions-App verlagern. Sie können stets Techniken wie Funktionsverkettung nutzen, um Daten in verschiedenen Funktions-Apps zwischen Funktionen zu übergeben.

Bewährte Methoden für Skalierbarkeit

Es gibt eine Reihe von Faktoren, die sich darauf auswirken, wie Instanzen Ihrer Funktions-App skaliert werden. Die Details werden in der Dokumentation zur Funktionsskalierung bereitgestellt. Im Folgenden sind einige bewährte Methoden aufgeführt, um eine optimale Skalierbarkeit einer Funktions-App zu gewährleisten.

Freigeben und Verwalten von Verbindungen

Wiederverwenden von Verbindungen zu externen Ressourcen, wenn möglich. Siehe how to manage connections in Azure Functions.

Vermeiden der Freigabe von Speicherkonten

Wenn Sie eine Funktions-App erstellen, müssen Sie sie einem Speicherkonto zuordnen. Die Speicherkontoverbindung wird in der AzureWebJobsStorage-Anwendungseinstellung verwaltet.

Verwenden Sie für jede Funktions-App ein separates Speicherkonto, um die Leistung zu maximieren. Dieser Ansatz ist besonders wichtig, wenn Sie über Durable Functions- oder Event Hubs ausgelöste Funktionen verfügen, die beide ein hohes Volumen von Speichertransaktionen generieren. Wenn Ihre Anwendungslogik mit Azure Storage interagiert, entweder direkt (mit dem Storage SDK) oder über eine der Speicherbindungen, sollten Sie ein dediziertes Speicherkonto verwenden. Wenn Sie z. B. über eine Ereignishub-ausgelöste Funktion verfügen, die Daten in den Blob-Speicher schreibt, verwenden Sie zwei Speicherkonten: eines für die Funktions-App und ein weiteres für die Blobs, die die Funktion speichert.

Kombinieren Sie Test- und Produktionscode in derselben Funktions-App nicht

Funktionen in einer Funktions-App teilen Ressourcen. Der Arbeitsspeicher wird beispielsweise freigegeben. Wenn Sie eine Funktions-App in der Produktion verwenden, fügen Sie keine testbezogenen Funktionen und Ressourcen hinzu. Es kann zu unerwartetem Aufwand bei der Ausführung von Produktionscode führen.

Achten Sie darauf, was Sie in Ihren Produktionsfunktions-Apps laden. Der Speicher wird über jede Funktion in der App gemittelt.

Wenn in mehreren .NET Funktionen auf eine freigegebene Assembly verwiesen wird, fügen Sie sie in einen gemeinsamen freigegebenen Ordner ein. Andernfalls könnten Sie versehentlich mehrere Versionen derselben Binärdatei bereitstellen, die sich zwischen Funktionen unterschiedlich verhalten.

Verwenden Sie keine ausführliche Protokollierung im Produktionscode, was sich negativ auf die Leistung auswirkt.

Verwenden sie asynchronen Code, vermeiden Sie jedoch das Blockieren von Aufrufen.

Die asynchrone Programmierung ist eine empfohlene bewährte Methode, insbesondere beim Blockieren von E/A-Vorgängen.

Vermeiden Sie in C# immer, auf die Result-Eigenschaft zu verweisen oder die Methode Wait auf einer Task-Instanz aufzurufen. Dieser Ansatz kann zu Thread-Erschöpfung führen.

Verwenden mehrerer Arbeitsprozesse

Standardmäßig verwendet jede Hostinstanz für Funktionen einen einzelnen Arbeitsprozess. Um die Leistung zu verbessern, insbesondere bei Einzelthreadlaufzeiten wie Python, verwenden Sie die FUNCTIONS_WORKER_PROCESS_COUNT, um die Anzahl der Arbeitsprozesse pro Host (bis zu 10) zu erhöhen. Azure Functions versucht dann, gleichzeitige Funktionsaufrufe über diese Mitarbeiter hinweg gleichmäßig zu verteilen.

Die FUNCTIONS_WORKER_PROCESS_COUNT gilt für jeden Host, den Azure Functions erstellt, wenn die Anwendung zur Bedarfsdeckung skaliert wird.

Empfang von Nachrichten im Stapel, immer wenn möglich.

Einige Trigger wie Event Hub ermöglichen das Empfangen eines Batches von Nachrichten in einem einzigen Aufruf. Das Batching von Nachrichten hat eine wesentlich bessere Leistung. Sie können die maximale Batchgröße in der host.json Datei so konfigurieren, wie in der host.json Referenzdokumentation beschrieben.

Bei C#-Funktionen können Sie den Typ in ein stark typiertes Array ändern. Statt EventData sensorEvent könnte die Methodensignatur z. B. EventData[] sensorEvent lauten. Für andere Sprachen müssen Sie die Kardinalitätseigenschaft in Ihrem function.json explizit auf many festlegen, um die Batchverarbeitung as hier gezeigt zu aktivieren.

Konfigurieren von Hostverhalten zur besseren Behandlung der Parallelität

Die host.json Datei in der Funktions-App ermöglicht die Konfiguration von Hostlaufzeit und Triggerverhalten. Zusätzlich zu Batchverhalten können Sie die Parallelität für eine Reihe von Triggern verwalten. Eine häufige Anpassung der Werte in diesen Optionen kann die Skalierung der Instanz an die Anforderungen der aufgerufenen Funktionen vereinfachen.

Einstellungen in der host.json Datei gelten für alle Funktionen innerhalb der App innerhalb einer einzigen Instanz der Funktion. Wenn Sie beispielsweise eine Funktions-App mit zwei HTTP-Funktionen und maxConcurrentRequests Anforderungen auf 25 festgelegt haben, zählt eine Anforderung an einen der beiden HTTP-Trigger zu den freigegebenen 25 gleichzeitigen Anforderungen. Wenn diese Funktions-App auf 10 Instanzen skaliert wird, ermöglichen die zehn Funktionen effektiv 250 gleichzeitige Anforderungen (10 Instanzen * 25 gleichzeitige Anforderungen pro Instanz).

Weitere Hostkonfigurationsoptionen finden Sie im host.json Konfigurationsartikel.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Wie verbindungen in Azure Functions
• Azure App Service bewährte Methoden