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.
In Azure Functions kann eine einzelne Funktions-App-Instanz mehrere Ereignisse gleichzeitig verarbeiten. Da diese auf derselben Computeinstanz ausgeführt werden, teilen sie Arbeitsspeicher, CPU und Verbindungsressourcen. Bei bestimmten Hostingplänen führt die hohe Nachfrage nach einer bestimmten Instanz dazu, dass der Functions-Host automatisch neue Instanzen erstellt, um die erhöhte Last zu verarbeiten. In diesen dynamischen Skalierungsplänen gibt es einen Kompromiss zwischen Parallelität und Skalierungsverhalten. Um mehr Kontrolle über die Ausführung Ihrer App zu bieten, bietet Funktionen eine Möglichkeit, die Anzahl der gleichzeitigen Ausführungen zu verwalten.
Azure Functions bietet zwei Hauptmethoden zur Verwaltung der Gleichzeitigkeit:
- Feste Parallelität pro Instanz: Sie können Grenzwerte auf Hostebene für Parallelität konfigurieren, die spezifisch für einzelne Trigger sind. Dieses Modell ist das Standardmäßige Parallelitätsverhalten für Funktionen.
- Dynamische Parallelität: Bei bestimmten Triggertypen kann der Funktionshost automatisch die beste Parallelitätsstufe für diesen Trigger in Ihrer Funktions-App ermitteln. Sie müssen sich für dieses Parallelitätsmodell abonnieren.
In diesem Artikel werden die Parallelitätsverhalten von ereignisgesteuerten Triggern in Funktionen und die Auswirkungen dieser Verhaltensweisen auf die Skalierung in dynamischen Plänen beschrieben. Außerdem werden die festen pro-Instanz- und dynamischen Nebenläufigkeitsmodelle verglichen.
Skalierung im Vergleich zur Parallelität
Für Funktionen, die ereignisbasierte Trigger verwenden oder auf HTTP-Anforderungen reagieren, können Sie schnell die Grenzen gleichzeitiger Ausführungen in Zeiträumen mit hoher Nachfrage erreichen. Während dieser Zeiträume müssen Sie ihre Funktions-App skalieren können, indem Sie Instanzen hinzufügen, um einen Backlog bei der Verarbeitung eingehender Anforderungen zu vermeiden. Die Art und Weise, wie ihre App skaliert wird, hängt von Ihrem Hostingplan ab:
| Skalierungstyp | Hostingpläne | BESCHREIBUNG |
|---|---|---|
| Dynamische Skalierung (ereignisgesteuert) |
Verbrauch Flex-Verbrauch Prämie |
In einem dynamischen Skalierungsplan skaliert der Host die Anzahl der Funktions-App-Instanzen basierend auf der Anzahl der eingehenden Ereignisse nach oben oder unten. Weitere Informationen finden Sie unter ereignisgesteuerte Skalierung in Azure Functions. |
| Manuelle Skalierung | Dedizierte Pläne (App Service) | Wenn Sie Ihre Funktions-App in einem dedizierten Plan hosten, müssen Sie Ihre Instanzen in Zeiträumen mit höherer Auslastung manuell konfigurieren oder ein Schema für die automatische Skalierung einrichten. |
Bevor eine Skalierung auftreten kann, versucht Ihre Funktions-App, erhöhungen der Auslastung zu behandeln, indem mehrere Aufrufe desselben Typs in einer einzigen Instanz behandelt werden. Daher wirken sich diese gleichzeitigen Ausführungen in einer bestimmten Instanz direkt auf Skalierungsentscheidungen aus. Wenn beispielsweise eine App in einem dynamischen Skalierungsplan auf einen Parallelitätsgrenzwert trifft, muss sie möglicherweise skaliert werden, um die eingehende Nachfrage zu erfüllen.
Die Balance zwischen Skalierung und Parallelität, die Sie in Ihrer App erreichen möchten, hängt davon ab, wo Engpässe auftreten können: bei der Verarbeitung (CPU-intensive Prozessbeschränkungen) oder in einem nachgeschalteten Dienst (E/A-basierte Einschränkungen).
Feste Konkurrenz pro Instanz
Standardmäßig unterstützen die meisten Trigger ein festes Parallelitätskonfigurationsmodell pro Instanz über die zielbasierte Skalierung. In diesem Modell hat jeder Auslösertyp einen Parallelitätsgrenzwert für jede Instanz.
Sie können die Standardwerte für die Parallelität für die meisten Trigger außer Kraft setzen, indem Sie eine bestimmte Parallelität pro Instanz für diesen Triggertyp festlegen. Für viele Trigger konfigurieren Sie Parallelitätseinstellungen in der host.json Datei. Der Azure Service Bus-Trigger stellt beispielsweise eine MaxConcurrentCalls und eine MaxConcurrentSessions Einstellung in host.jsonbereit. Diese Einstellungen arbeiten zusammen, um die maximale Anzahl von Nachrichten zu steuern, die jede Funktions-App gleichzeitig für jede Instanz verarbeitet.
In bestimmten zielbasierten Skalierungsszenarien, z. B. wenn Sie einen Apache Kafka- oder Azure Cosmos DB-Trigger verwenden, befindet sich die Parallelitätskonfiguration in der Funktionsdeklaration, nicht in der dateihost.json . Andere Triggertypen verfügen über integrierte Mechanismen für den Instanzübergreifenden Lastenausgleich von Aufrufen. Beispielsweise verwenden Azure Event Hubs und Azure Cosmos DB beide ein partitionsbasiertes Schema.
Bei Triggertypen, die die Parallelitätskonfiguration unterstützen, werden die Parallelitätseinstellungen auf alle ausgeführten Instanzen angewendet. Auf diese Weise können Sie die maximale Parallelität für Ihre Funktionen in jeder Instanz steuern. Wenn Ihre Funktion beispielsweise CPU-intensiv oder ressourcenintensiv ist, können Sie die Parallelität einschränken, um Instanzen fehlerfrei zu halten. In diesem Fall können Sie sich auf die Skalierung verlassen, um erhöhte Lasten zu verarbeiten. Wenn Ihre Funktion Anforderungen an einen nachgeschalteten Dienst sendet, der gedrosselt wird, sollten Sie auch die Parallelität einschränken, um eine Überlastung des nachgeschalteten Diensts zu vermeiden.
HTTP-Auslöserparallelität
Gilt nur für den Flex-Verbrauchsplan
DIE HTTP-Trigger-Parallelität ist ein spezieller Typ fester Parallelität pro Instanz. In HTTP-Trigger-Parallelität hängt die Standardkoncurrency auch von der Instanzgröße ab.
Der Flex-Verbrauchsplan skaliert alle HTTP-Auslöserfunktionen als Gruppe. Weitere Informationen finden Sie unter Skalierung pro Funktion.
Die folgende Tabelle gibt die Standardeinstellung für Parallelitätseinstellungen für HTTP-Trigger für eine bestimmte Instanz basierend auf der konfigurierten Instanzspeichergröße an:
| Instanzgröße (MB) | Standardparalelität* |
|---|---|
| 512 | 4 |
| 2,048 | 16 |
| 4.096 | 32 |
*In Python-Apps verwenden alle Instanzen standardmäßig eine HTTP-Trigger-Parallelitätsebene von 1.
Diese Standardwerte sollten für die meisten Fälle gut funktionieren, und Sie können damit beginnen. Bedenken Sie, dass bei einer bestimmten Anzahl von HTTP-Anforderungen eine Erhöhung des HTTP- Parallelitätswertes die Anzahl der für die Bearbeitung von HTTP-Anforderungen erforderlichen Instanzen reduziert. Ebenso erfordert das Verringern des HTTP-Parallelitätswerts mehr Instanzen, um dieselbe Last zu verarbeiten.
Wenn Sie die HTTP-Parallelität optimieren müssen, können Sie dies mithilfe der Azure CLI tun. Weitere Informationen finden Sie unter Festlegen von HTTP-Parallelitätsgrenzwerten.
Die Standardkoncurrencywerte in der vorherigen Tabelle gelten nur, wenn Sie keine eigene HTTP-Parallelitätseinstellung festlegen. Wenn Sie keine HTTP-Parallelitätseinstellung explizit festlegen, erhöht sich die Standardkonkurrenz, wie in der Tabelle dargestellt, wenn Sie die Größe der Instanz ändern. Nachdem Sie einen HTTP-Parallelitätswert spezifisch festgelegt haben, wird dieser Wert trotz Änderungen der Instanzgröße beibehalten.
Ermitteln der optimalen Parallelität pro Instanz
Feste Parallelitätskonfigurationen ermöglichen Ihnen die Kontrolle über bestimmte Triggerverhalten, z. B. das Drosseln Ihrer Funktionen. Es kann jedoch schwierig sein, die optimalen Werte für diese Einstellungen zu ermitteln. In der Regel müssen Sie über einen iterativen Prozess zu akzeptablen Werten der Auslastungstests gelangen. Auch nachdem Sie einen Satz von Werten ermittelt haben, die für ein bestimmtes Ladeprofil funktionieren, kann sich die Anzahl der Ereignisse, die von Ihren verbundenen Diensten empfangen werden, von Tag zu Tag ändern. Diese Variabilität kann dazu führen, dass Ihre App mit suboptimalen Werten ausgeführt wird. Beispielsweise kann Ihre Funktions-App anspruchsvolle Nachrichtennutzlasten am letzten Tag der Woche verarbeiten. Daher müssen Sie die Parallelität drosseln. Während der restlichen Woche sind die Nachrichtennutzlasten jedoch möglicherweise geringer, was bedeutet, dass Sie einen höheren Grad der Gleichzeitigkeit verwenden können.
Im Idealfall sollte es Instanzen ermöglichen, so viel Arbeit wie möglich zu verarbeiten, während jede Instanz fehlerfrei und latenzarm bleibt. Dynamische Parallelität ist für diesen Zweck konzipiert.
Dynamische Parallelität
Funktionen bieten ein dynamisches Parallelitätsmodell, das die Konfiguration der Parallelität für alle Funktions-Apps vereinfacht, die im selben Plan ausgeführt werden.
Hinweis
Dynamische Parallelität wird derzeit nur für die Trigger Azure Blob Storage, Azure Queue Storage und Service Bus unterstützt. Außerdem müssen Sie die erweiterungsversionen verwenden, die in der Erweiterungsunterstützung aufgeführt sind, weiter unten in diesem Artikel.
Vorteile
Dynamische Parallelität bietet die folgenden Vorteile:
- Eine vereinfachte Konfiguration: Sie müssen die Parallelitätseinstellungen pro Trigger nicht mehr manuell bestimmen. Das System lernt im Laufe der Zeit die optimalen Werte für Ihre Workload.
- Dynamische Anpassungen: Parallelität wird dynamisch in Echtzeit nach oben oder unten angepasst. Dadurch kann das System im Laufe der Zeit die sich ändernden Auslastungsmuster übernehmen.
- Instanzintegritätsschutz: Die Laufzeit beschränkt die Parallelität auf Ebenen, die eine Funktions-App-Instanz bequem verarbeiten kann. Diese Grenzwerte schützen die App davor, sich selbst zu überlasten, indem sie mehr Arbeit übernimmt, als sie sollte.
- Verbesserter Durchsatz: Der Gesamtdurchsatz wird verbessert, da einzelne Instanzen nicht mehr Arbeit abrufen, als sie schnell verarbeiten können. Daher wird die Lastverteilung über Instanzen effektiver gestaltet. Bei Funktionen, die höhere Lasten bewältigen können, kann ein höherer Durchsatz erzielt werden, indem die Parallelität auf Werte oberhalb der Standardkonfiguration erhöht wird.
Konfigurationen für die Dynamische Parallelität
Sie können die dynamische Parallelität auf Hostebene in der dateihost.json aktivieren. Wenn sie aktiviert ist, werden die Parallelitätsebenen aller Bindungserweiterungen, die dieses Feature unterstützen, bei Bedarf automatisch angepasst. In diesen Fällen haben die dynamischen Einstellungen für die Parallelität Vorrang vor allen manuell konfigurierten Einstellungen für die Parallelität.
Standardmäßig ist die dynamische Parallelität deaktiviert. Wenn Sie die dynamische Parallelität aktivieren, beginnt die Parallelität auf einer Ebene von 1 für jede Funktion. Die Parallelitätsebene wird an einen optimalen Wert angepasst, den der Host bestimmt.
Sie können die dynamische Parallelität in Ihrer Funktions-App aktivieren, indem Sie ihrer host.json Datei die folgenden Einstellungen hinzufügen:
{
"version": "2.0",
"concurrency": {
"dynamicConcurrencyEnabled": true,
"snapshotPersistenceEnabled": true
}
}
Wenn snapshotPersistenceEnabled dies der Standardwert ist true, werden die gelernten Parallelitätswerte regelmäßig im Speicher beibehalten. Neue Instanzen beginnen mit diesen Werten, anstatt von einer Ebene von 1 zu beginnen und das Lernen wiederholen zu müssen.
Parallelitäts-Manager
Wenn die dynamische Parallelität aktiviert ist, wird hinter den Kulissen ein Parallelitäts-Manager-Prozess im Hintergrund ausgeführt. Dieser Verwalter überwacht ständig die Integritätsmetriken für Instanzen, wie z. B. die CPU- und Threadauslastung und ändert die Drosselungen bei Bedarf. Wenn eine oder mehrere Drosselungen eingeschaltet sind, wird die Funktionsparallelität nach unten angepasst, bis der Host wieder fehlerfrei ist. Wenn Drosselmechanismen ausgeschaltet sind, kann die Parallelität erhöht werden. Verschiedene Heuristiken werden verwendet, um die Parallelität basierend auf diesen Drosselungen intelligent nach oben oder unten anzupassen. Im Laufe der Zeit wird die Parallelität für jede Funktion auf eine bestimmte Ebene stabilisiert. Da es Zeit dauern kann, um den optimalen Parallelitätswert zu ermitteln, verwenden Sie dynamische Parallelität nur, wenn ein suboptimaler Wert für Ihre Lösung anfangs oder nach einer Zeit der Inaktivität akzeptabel ist.
Die Parallelitätsebenen werden für jede einzelne Funktion verwaltet. Genauer gesagt: Das System gleicht zwischen ressourcenintensiven Funktionen ab, die eine geringe Parallelität und einfachere Funktionen erfordern, die eine höhere Parallelität verarbeiten können. Das Gleichgewicht der Parallelität für jede Funktion hilft, die allgemeine Integrität der Funktions-App-Instanz zu erhalten.
Wenn die dynamische Parallelität aktiviert ist, finden Sie dynamische Parallelitätsentscheidungen in Ihren Protokollen. Zum Beispiel werden Protokolleinträge hinzugefügt, wenn verschiedene Steuerungen aktiviert werden, und immer dann, wenn die Parallelität für jede Funktion erhöht oder verringert wird. Diese Protokolle werden unter der Log-Kategorie Host.Concurrency in der traces-Tabelle geschrieben.
Unterstützung für Erweiterung
Die dynamische Parallelität ist für eine Funktions-App auf der Hostebene aktiviert und alle Erweiterungen, die die dynamische Parallelität unterstützen, werden in diesem Modus ausgeführt. Die dynamische Parallelität erfordert die Zusammenarbeit zwischen dem Host und den einzelnen Triggererweiterungen. Nur die aufgeführten Versionen der folgenden Erweiterungen unterstützen die dynamische Parallelität.
| Durchwahl | Version | BESCHREIBUNG |
|---|---|---|
| Queuespeicher | Version 5.x (Speichererweiterung) | Der Warteschlangenspeichertrigger verfügt über eine eigene Nachrichtenabfragungsschleife. Wenn Sie eine feste Konfiguration pro Instanz verwenden, steuern die BatchSize Optionen und NewBatchThreshold Konfigurationsoptionen die Parallelität. Wenn Sie dynamische Parallelität verwenden, werden diese Konfigurationswerte ignoriert. Dynamische Parallelität ist in die Nachrichtenschleife integriert, sodass die Anzahl der pro Iteration abgerufenen Nachrichten dynamisch angepasst wird. Wenn Drosselungsmechanismen aktiviert sind, wird der Host überlastet. Die Nachrichtenverarbeitung wird angehalten, bis die Throttles abgeschaltet sind. Wenn die Drosselungen deaktiviert sind, erhöht sich die Gleichzeitigkeit. |
| Blob Storage | Version 5.x (Speichererweiterung) | Intern verwendet der Blob-Storage-Trigger dieselbe Infrastruktur, die der Warteschlangen-Speicher-Trigger verwendet. Wenn neue oder aktualisierte Blobs verarbeitet werden müssen, werden Nachrichten in eine plattformverwaltete Steuerwarteschlange geschrieben. Diese Warteschlange wird mithilfe der gleichen Logik verarbeitet, die für den Queue Storage-Trigger verwendet wird. Wenn dynamische Parallelität eingeschaltet ist, ist Parallelität für die Verarbeitung dieser Steuerungswarteschlange dynamisch verwaltet. |
| Servicebus | Version 5.x | Der Service Bus Trigger unterstützt derzeit drei Ausführungsmodelle. Dynamische Gleichzeitigkeit wirkt sich auf diese Ausführungsmodelle auf folgende Weise aus:MaxConcurrentCalls Konfigurationsoption die Parallelität. Wenn Sie dynamische Parallelität verwenden, wird dieser Konfigurationswert ignoriert, und die Parallelität wird dynamisch angepasst.MaxConcurrentSessions Einstellung die Parallelität. Wenn die dynamische Parallelität aktiviert ist, wird der MaxConcurrentSessions Wert ignoriert, und die Anzahl der Sitzungen, die jede Instanz verarbeitet, wird dynamisch angepasst.MaxMessageCount Einstellung gesteuert werden. Da Batchaufrufe seriell sind, ist die Parallelität für Ihre batchauslöste Funktion immer eine, und die dynamische Parallelität wird nicht angewendet. |
Nächste Schritte
Weitere Informationen finden Sie in den folgenden Ressourcen: