Leistung und Skalierung in dauerhaften Funktionen

Verwenden Sie diesen Artikel, um das Leistungs- und Skalierungsverhalten Ihrer App für dauerhafte Funktionen zu optimieren. Es deckt die Haupthebel ab, die Sie anpassen können:

• Worker scaling: Wie der Azure Functions-Host basierend auf der Auslastung Worker hinzufügt und entfernt.
• Konkurrenzauslastungen: Begrenzung der Anzahl der Funktionen, die gleichzeitig auf jedem Worker ausgeführt werden.
• Zwischenspeicherung von Instanzen: Reduzieren des Wiedergabeaufwands durch Zwischenspeichern des Orchestrierungszustands im Arbeitsspeicher des Mitarbeiters.
• Partitionsanzahl: Wie die Partitionierung für Skalierung und Lokalität konfiguriert wird.

Workerskalierung

Ein wichtiger Vorteil des Aufgabenhub-Konzepts ist, dass die Anzahl der Mitarbeiter, die Aufgabenhubarbeitselemente verarbeiten, nach oben und unten skaliert wird. Anwendungen fügen Instanzen hinzu (Skalieren nach außen), um die Verarbeitung der Arbeit zu beschleunigen, und entfernen Instanzen (Skalieren nach innen), wenn nicht genügend Arbeit vorhanden ist, um sie auszulasten. Sie können sogar auf Null skalieren , wenn der Aufgabenhub im Leerlauf ist. Wenn Sie auf Null skalieren, werden keine Worker ausgeführt. Nur der Skalierungscontroller und speicher bleiben aktiv.

Dieses Konzept wird im folgenden Diagramm veranschaulicht:

Autoskalierung

In den Plänen "Verbrauch" und "Elastic Premium" unterstützt Durable Functions die Automatische Skalierung über den Azure Functions Scale Controller. Der Skalierungscontroller überwacht, wie lange Nachrichten und Aufgaben vor der Verarbeitung warten. Basierend auf diesen Latenzen werden Mitarbeiter hinzugefügt oder entfernt.

Im Premium-Plan hält die automatische Skalierung die Anzahl der Mitarbeiter (und Betriebskosten) ungefähr proportional zur Auslastung der Anwendung.

Drosselungen der Parallelität

Eine einzelne Arbeitsinstanz kann mehrere Arbeitsaufgaben gleichzeitig ausführen. Dies erhöht Parallelität und nutzt Arbeitsressourcen effizienter. Wenn ein Worker jedoch zu viele Arbeitsaufgaben gleichzeitig verarbeitet, kann er Ressourcen wie CPU, Netzwerkverbindungen und Arbeitsspeicher ausschöpfen.

Damit ein einzelner Worker nicht überlastet wird, müssen Sie möglicherweise die Parallelität pro Instanz drosseln. Die Anzahl der gleichzeitig auf jedem Arbeiter ausgeführten Funktionen einzuschränken, hilft zu vermeiden, dass die Ressourcengrenzen dieses Arbeiters erreicht werden.

Parallelitätsdrosselungen konfigurieren

Konfigurieren Von Aktivitäts-, Orchestrator- und Entitätsfunktions-Parallelitätsgrenzwerten in der host.json Datei. Verwenden Sie durableTask/maxConcurrentActivityFunctions für Aktivitätsfunktionen und durableTask/maxConcurrentOrchestratorFunctions für Orchestrator- und Entitätsfunktionen. Diese Einstellungen beschränken die Anzahl der Orchestrator-, Entitäts- und Aktivitätsfunktionen, die ein Worker in den Arbeitsspeicher lädt.

{
  "extensions": {
    "durableTask": {
      "maxConcurrentActivityFunctions": 10,
      "maxConcurrentOrchestratorFunctions": 10
    }
  }
}

Sprachlaufzeitüberlegungen

Die ausgewählte Sprachlaufzeit kann strenge Parallelitätseinschränkungen für Ihre Funktionen festlegen. Beispielsweise können Durable Functions Apps, die in Python oder PowerShell geschrieben wurden, jeweils nur eine Funktion auf einer einzelnen VM ausführen. Dies kann zu Leistungsproblemen führen, wenn Sie dies nicht berücksichtigen. Wenn ein Orchestrator zehn Aktivitäten vorsieht, die Sprach-Laufzeit aber nur eine Funktion zulässt, müssen neun der zehn Aktivitätsfunktionen warten, bis sie ausgeführt werden können. Außerdem können diese wartenden Aktivitäten nicht per Load Balancing auf andere Prozesse verteilt werden, da die Durable Functions-Laufzeit sie bereits in den Arbeitsspeicher lädt. Dies ist besonders problematisch, wenn die Aktivitätsfunktionen lange andauern.

Wenn ihre Sprachlaufzeit die Parallelität einschränkt, aktualisieren Sie Durable Functions Parallelitätseinstellungen, um sie abzugleichen. Dadurch wird verhindert, dass die Laufzeitumgebung von Durable Functions mehr Funktionen gleichzeitig ausführt, als von der Sprachlaufzeit erlaubt wird, und ausstehende Aktivitäten auf andere VMs verteilt werden können. Wenn eine Python-App beispielsweise die Parallelität auf vier Funktionen einschränkt (z. B. 4 Threads in einem Arbeitsprozess mit einer Sprache oder 1 Thread für 4 Spracharbeitsprozesse), konfigurieren Sie sowohl maxConcurrentOrchestratorFunctions als auch maxConcurrentActivityFunctions auf 4.

Informationen zu Python Leistungsempfehlungen finden Sie unter Improve throughput performance of Python apps in Azure Functions. Diese Techniken können Durable Functions Leistung und Skalierbarkeit erheblich verbessern.

Zwischenspeicherung von Instanzen

Zum Verarbeiten einer Orchestrierungsarbeitsaufgabe führt ein Worker zwei Dinge aus:

1. Orchestrierungshistorie abrufen.
2. Wiederholung des Orchestratorcodes mithilfe des Verlaufs.

Wenn derselbe Arbeiter mehrere Arbeitselemente für dieselbe Orchestrierung verarbeitet, kann der Speicheranbieter den Verlauf im Arbeitsspeicher des Arbeiters zwischenspeichern, um den ersten Schritt zu überspringen. Es kann auch den Orchestrator während der Ausführung zwischenspeichern, um zu vermeiden, dass der Verlauf für nachfolgende Arbeitselemente erneut abgespielt wird.

Aktivieren Sie das Zwischenspeichern, wenn Ihre Orchestrierungen viele Instanzen aufweisen und Sie einen hohen Replay-Overhead feststellen. Das Caching reduziert typischerweise die E/A-Anforderungen für den zugrunde liegenden Speicherdienst und verbessert Durchsatz und Latenz, erhöht jedoch auch die Speicherauslastung der Arbeitseinheit.

Zwischenspeichern nach Speicheranbieter

In der folgenden Tabelle wird die Unterstützung für das Zwischenspeichern von Instanzen zwischen Anbietern verglichen und die Konfiguration der einzelnen Instanzen zusammengefasst.

Erweiterte Sitzungen (Azure Storage-Anbieter) behalten Mid-Execution-Orchestratoren im Arbeitsspeicher bei, bis sie für eine festgelegte Zeit im Leerlauf sind. Aktivieren und optimieren Sie dieses Verhalten mit extendedSessionsEnabled und extendedSessionIdleTimeoutInSeconds in Ihrer host.json Datei:

{
  "extensions": {
    "durableTask": {
      "extendedSessionsEnabled": true,
      "extendedSessionIdleTimeoutInSeconds": 30
    }
  }
}

Der Instanzcache (Netherite Storage Provider) behält den Instanzstatus und den Verlauf im Arbeitsspeicher des Mitarbeiters bei und verfolgt die Gesamtspeichernutzung. Wenn der Cache den InstanceCacheSizeMB Grenzwert überschreitet, werden die zuletzt verwendeten Instanzdaten entfernt. Wenn Sie CacheOrchestrationCursors auf true setzen, speichert der Cache auch die Mid-Execution-Orchestratoren.

Partitionsanzahl

Einige Speicheranbieter unterstützen die Partitionierung und ermöglichen ihnen das Festlegen partitionCount.

Bei der Partitionierung konkurrieren Die Mitarbeiter nicht um einzelne Arbeitsaufgaben. Das Partitionieren gruppiert Arbeitselemente in partitionCount Partitionen, und der Ladevorgang weist diese Partitionen den Workern zu. Dieser Ansatz reduziert die Gesamtanzahl der Speicherzugriffe. Außerdem kann er Instanzspeicherung aktivieren und die Lokalität verbessern, da Affinität erschaffen wird: Der gleiche Worker verarbeitet alle Workitems für dieselbe Instanz.

Für die meisten Apps reicht die Standardpartitionsanzahl aus. Erhöhen Sie die Partitionsanzahl, wenn Sie erwarten, dass über die Standardanzahl der Workers für Orchestrierungsvorgänge hinaus skaliert werden soll, da die Partitionsanzahl die Anzahl der Workers einschränkt, die Orchestrierungsnachrichten aus einer partitionierten Warteschlange verarbeiten können.

Die folgende Tabelle zeigt, welche Warteschlangen von jedem Speicheranbieter partitioniert werden, sowie den zulässigen Bereich und die Standardwerte für partitionCount.

Konfigurieren der Partitionsanzahl

Geben Sie in der Datei partitionCount an. Der folgende host.json-Ausschnitt setzt durableTask/storageProvider/partitionCount auf 3.

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "partitionCount": 3
      }
    }
  }
}

Funktionsausführungsverhalten

In diesem Abschnitt werden Die Ausführungsdetails behandelt, die sich auf die Leistung auswirken: welche Art von Arbeit jeder Funktionstyp verarbeiten soll, wie Timeouts funktionieren und wie Entitätsvorgänge batchweise verarbeitet werden.

Arbeitsplatzverteilung nach Funktionstyp

Orchestrator-Funktionen führen ihre Logik mehrmals aus, da sie wiederholt werden. Daher ist es wichtig, dass Orchestrator-Funktionsthreads keine CPU-intensiven Aufgaben ausführen, keine E/A durchführen oder blockieren. Verschieben Sie Arbeit, die E/A, Blockierung oder mehrere Threads erfordern kann, in Aktivitätsfunktionen.

Aktivitätsfunktionen verhalten sich wie normale, in der Warteschlange ausgelöste Funktionen. Sie unterstützen E/A, CPU-intensive Vorgänge und mehrere Threads. Da Aktivitätstrigger zustandslos sind, skalieren sie auf viele VMs.

Entitätsfunktionen laufen auch auf einem einzelnen Thread und führen Operationen nacheinander aus. Entitätsfunktionen haben keine Einschränkungen für den Codetyp, den sie ausführen.

Funktion-Timeouts

Aktivitäts-, Orchestrator- und Entitätsfunktionen unterliegen den gleichen Funktionstimeouts wie den anderen Azure Functions. Durable Functions behandelt ein Funktionstimeout wie eine unbehandelte Ausnahme im Code.

Wenn z. B. bei einer Aktivität eine Zeitüberschreitung auftritt, zeichnet Durable Functions die Ausführung als fehlgeschlagen auf und benachrichtigt den Orchestrator. Der Orchestrator behandelt die Zeitüberschreitung wie jede andere Ausnahme: Die Laufzeit versucht, den Vorgang zu wiederholen, wenn der Aufruf dies angibt, oder es wird ein Exception Handler ausgeführt.

Batchverarbeitung von Entitätsvorgängen

Um die Leistung zu verbessern und Kosten zu senken, kann eine einzelne Arbeitsaufgabe eine Reihe von Entitätsvorgängen ausführen. Im Verbrauchsplan wird jeder Batch als einzelne Funktionsausführung abgerechnet.

Standardmäßig beträgt die maximale Batchgröße 50 im Verbrauchsplan und 5.000 für andere Pläne. Sie können auch die maximale Batchgröße in der host.json Datei konfigurieren. Wenn die maximale Batchgröße auf „1“ festgelegt wird, ist die Batchverarbeitung faktisch deaktiviert.

Leistungsziele

Wenn Sie eine Produktions-App mit Durable Functions planen, sollten Sie die Leistungsanforderungen frühzeitig berücksichtigen. Diese grundlegenden Nutzungsszenarien helfen Ihnen bei der Planung:

• Sequenzielle Aktivitätsausführung: In diesem Szenario wird eine Orchestratorfunktion beschrieben, die eine Reihe von Aktivitätsfunktionen sequenziell ausführt. Es ähnelt am ehesten dem Funktionskettenbeispiel .
• Parallele Aktivitätsausführung: In diesem Szenario wird eine Orchestratorfunktion beschrieben, die viele Aktivitätsfunktionen parallel mithilfe des Fan-out-, Fan-In-Musters ausführt.
• Parallele Antwortverarbeitung: Dieses Szenario ist die zweite Hälfte des Fan-out-Fan-In-Musters. Es konzentriert sich auf die Fan-in-Leistung. Im Gegensatz zu Fanout wird fan-in in einer einzigen Orchestratorfunktionsinstanz ausgeführt, sodass sie auf einer einzelnen VM ausgeführt wird.
• Externe Ereignisverarbeitung: Dieses Szenario stellt eine einzelne Orchestratorfunktionsinstanz dar, die jeweils auf externe Ereignisse wartet.
• Verarbeitung von Entitätsvorgängen: In diesem Szenario wird getestet, wie schnell eine einzelneCounter-Entität einen konstanten Vorgangsstrom verarbeiten kann.

Durchsatznummern für diese Szenarien befinden sich in der Dokumentation des Speicheranbieters. Dies gilt insbesondere für:

• Informationen zum Azure Storage-Anbieter finden Sie unter Performance targets.
• Informationen zum Netherite-Speicheranbieter finden Sie unter "Grundlegende Szenarien".
• Informationen zum MSSQL-Speicheranbieter finden Sie unter Orchestration-Durchsatz-Benchmarks.

Nächste Schritte