Abrechnung von Durable Functions
Durable Functions wird auf dieselbe Weise wie Azure Functions in Rechnung gestellt. Weitere Informationen finden Sie unter Azure Functions – Preise.
Beim Ausführen von Orchestratorfunktionen im Nutzungsplan von Azure Functions sind einige Verhaltensweisen zu beachten, die bei der Abrechnung auftreten. In den folgenden Abschnitten werden diese Verhaltensweisen und ihre Auswirkungen ausführlicher beschrieben.
Abrechnung für die Wiedergabe von Orchestratorfunktionen
Orchestratorfunktionen werden unter Umständen während der gesamten Lebensdauer der Orchestrierung mehrmals wiedergegeben. Jede Wiedergabe wird von der Azure Functions-Runtime als eigenständiger Funktionsaufruf gesehen. Aus diesem Grund wird Ihnen im Azure Functions-Nutzungsplan jede Wiedergabe der Orchestratorfunktion in Rechnung gestellt. Bei anderen Plantypen wird die Wiedergabe von Orchestratorfunktionen nicht berechnet.
Warten und Anhalten in Orchestratorfunktionen
Wenn eine Orchestratorfunktion auf den Abschluss einer asynchronen Aufgabe wartet, geht die Runtime davon aus, dass bestimmte Funktionsaufrufe abgeschlossen sind. An diesem Punkt wird die Abrechnung für die Orchestratorfunktion beendet. Sie wird erst wieder aufgenommen, wenn die nächste Orchestratorfunktion wiedergegeben wird. Die Zeit, in der Sie warten oder die eine Orchestratorfunktion angehalten ist, wird Ihnen nicht in Rechnung gestellt.
Hinweis
Funktionen, die andere Funktionen aufrufen, werden manchmal als serverlose Antimuster betrachtet. Der Grund dafür ist die sogenannte doppelte Abrechnung. Wenn eine Funktion eine andere Funktion direkt aufruft, werden beide gleichzeitig ausgeführt. Die aufgerufene Funktion führt aktiv Code aus, während die aufrufende Funktion auf eine Antwort wartet. In dem Fall wird Ihnen die Zeit in Rechnung gestellt, während der die aufrufende Funktion auf die Ausführung der aufgerufenen Funktion wartet.
Es gibt keine doppelte Abrechnung für Orchestratorfunktionen. Die Abrechnung der Orchestratorfunktion wird angehalten, während sie auf das Ergebnis einer Aktivitätsfunktion oder einer untergeordneten Orchestrierung wartet.
Durable HTTP-Abruf
Orchestratorfunktionen können HTTP-Aufrufe mit langer Ausführungszeit an externe Endpunkte durchführen, wie im Artikel HTTP-Features beschrieben. Die call HTTP-APIs können intern einen HTTP-Endpunkt abfragen, während sie das asynchrone 202-Muster befolgen.
Für interne HTTP-Abrufvorgänge gibt es derzeit keine direkte Abrechnung. Interne Abrufe können jedoch bewirken, dass die Orchestratorfunktion regelmäßig wiedergegeben wird. Ihnen werden Standardgebühren für diese internen Funktionswiedergaben in Rechnung gestellt.
Transaktionen in Azure Storage
Durable Functions verwendet standardmäßig Azure Storage, um den Zustand beizubehalten, Nachrichten zu verarbeiten und Partitionen über Blobleases zu verwalten. Da sich dieses Speicherkonto in Ihrem Besitz befindet, werden alle Transaktionskosten in Ihrem Azure-Abonnement abgerechnet. Weitere Informationen zu den von Durable Functions verwendeten Azure Storage Artefakten finden Sie im Artikel Aufgabenhubs.
Mehrere Faktoren tragen zu den tatsächlichen Azure Storage-Kosten bei, die durch Ihre Durable Functions-App entstehen:
- Eine einzelne Funktions-App ist einem einzelnen Aufgabenhub zugeordnet, der einen Azure Storage-Ressourcensatz nutzt. Diese Ressourcen werden von allen Durable Functions in einer Funktions-App gemeinsam verwendet. Die tatsächliche Anzahl von Funktionen in der Funktions-App wirkt sich nicht auf Azure Storage-Transaktionskosten aus.
- Jede Funktions-App-Instanz ruft mithilfe eines Abrufalgorithmus für exponentielles Backoff intern mehrere Warteschlangen im Speicherkonto ab. Eine App-Instanz im Leerlauf ruft die Warteschlangen seltener als eine aktive App ab, wodurch geringere Transaktionskosten anfallen. Weitere Informationen zum Verhalten des Warteschlangenabrufs von Durable Functions beim Verwenden des Azure Storage-Anbieters finden Sie im Abschnitt "Warteschlangenabruf" der Azure Storage-Anbieterdokumentation.
- Wenn die Ausführung im Nutzungs- oder Premium-Plan von Azure Functions erfolgt, ruft der Azure Functions-Skalierungscontroller in regelmäßigen Abständen alle Aufgabenhubwarteschlangen im Hintergrund ab. Bei einer leichten bis mittleren Skalierung einer Funktions-App werden diese Warteschlangen nur von einer einzelnen Skalierungscontroller-Instanz abgefragt. Wenn die Funktions-App auf eine große Anzahl von Instanzen erweitert wird, können weitere Skalierungscontroller-Instanzen hinzugefügt werden. Diese zusätzlichen Skalierungscontroller-Instanzen können die Gesamtkosten für die Warteschlangentransaktion erhöhen.
- Jede Funktions-App-Instanz konkurriert um einen Satz von Blob-Leases. Diese Instanzen rufen in regelmäßigen Abständen den Azure-Blob-Dienst auf, um gehaltene Leases zu erneuern oder um neue Leases abzurufen. Die Anzahl der Blobleases hängt von der konfigurierten Partitionsanzahl des Aufgabenhubs ab. Das horizontale Hochskalieren auf eine größere Anzahl von Funktions-App-Instanzen erhöht wahrscheinlich die Azure Storage-Transaktionskosten für diese Leasevorgänge.
Weitere Informationen zu den Preisen für Azure Storage finden Sie in der Übersicht über die Preise für Azure Storage.