Azure Storage-provider (Azure Functions)

In dit document worden de kenmerken van de Durable Functions Azure Storage-provider beschreven, met een focus op prestatie- en schaalbaarheidsaspecten. De Azure Storage-provider is de standaardprovider. Er worden exemplaarstatussen en wachtrijen opgeslagen in een Azure Storage-account (klassiek).

Notitie

Zie de documentatie van de Durable Functions-opslagproviders voor meer informatie over de ondersteunde opslagproviders voor Durable Functions en hoe deze zich verhouden.

In de Azure Storage-provider wordt alle uitvoering van functies aangestuurd door Azure Storage-wachtrijen. Indeling en entiteitsstatus en -geschiedenis worden opgeslagen in Azure Tables. Azure Blobs en blob-leases worden gebruikt voor het distribueren van indelingsexemplaren en entiteiten over meerdere app-exemplaren (ook wel werkrollen of virtuele machines genoemd). In deze sectie wordt dieper ingegaan op de verschillende Azure Storage-artefacten en hoe deze van invloed zijn op de prestaties en schaalbaarheid.

Opslagweergave

Een taakhub bewaart duurzaam alle exemplaarstatussen en alle berichten. Zie het voorbeeld van de uitvoering van de taakhub voor een beknopt overzicht van hoe deze worden gebruikt om de voortgang van een indeling bij te houden.

De Azure Storage-provider vertegenwoordigt de taakhub in opslag met behulp van de volgende onderdelen:

• Tussen twee en drie Azure Tables. Er worden twee tabellen gebruikt om geschiedenissen en instantiestatussen weer te geven. Als Tabelpartitiebeheer is ingeschakeld, wordt er een derde tabel geïntroduceerd om partitiegegevens op te slaan.
• In één Azure-wachtrij worden de activiteitsberichten opgeslagen.
• In een of meer Azure Queues worden de exemplaarberichten opgeslagen. Elk van deze zogenaamde besturingswachtrijen vertegenwoordigt een partitie waaraan een subset van alle exemplaarberichten is toegewezen, op basis van de hash van de exemplaar-id.
• Enkele extra blobcontainers die worden gebruikt voor lease-blobs en/of grote berichten.

Een taakhub met de naam xyz bevat PartitionCount = 4 bijvoorbeeld de volgende wachtrijen en tabellen:

Vervolgens beschrijven we deze onderdelen en de rol die ze spelen in meer detail.

Geschiedenistabel

De tabel Geschiedenis is een Azure Storage-tabel met de geschiedenis gebeurtenissen voor alle indelingsexemplaren in een taakhub. De naam van deze tabel staat in de vorm TaskHubNameHistory. Wanneer exemplaren worden uitgevoerd, worden er nieuwe rijen aan deze tabel toegevoegd. De partitiesleutel van deze tabel is afgeleid van de exemplaar-id van de indeling. Exemplaar-id's zijn standaard willekeurig, waardoor een optimale distributie van interne partities in Azure Storage wordt gegarandeerd. De rijsleutel voor deze tabel is een volgnummer dat wordt gebruikt voor het ordenen van de geschiedenisevenementen.

Wanneer een indelingsexemplaar moet worden uitgevoerd, worden de bijbehorende rijen van de tabel Geschiedenis in het geheugen geladen met behulp van een bereikquery binnen één tabelpartitie. Deze geschiedenisgebeurtenissen worden vervolgens opnieuw afgespeeld in de orchestratorfunctiecode om deze terug te krijgen in de eerder controlepuntstatus. Het gebruik van de uitvoeringsgeschiedenis om de status op deze manier opnieuw op te bouwen, wordt beïnvloed door het patroon Gebeurtenisbronnen.

Tip

Indelingsgegevens die zijn opgeslagen in de tabel Geschiedenis, bevatten uitvoerpayloads van activiteits- en suborchestratorfuncties. Nettoladingen van externe gebeurtenissen worden ook opgeslagen in de tabel Geschiedenis. Omdat de volledige geschiedenis wordt geladen in het geheugen telkens wanneer een orchestrator moet worden uitgevoerd, kan een groot genoeg geschiedenis leiden tot aanzienlijke geheugenbelasting op een bepaalde VIRTUELE machine. De lengte en grootte van de indelingsgeschiedenis kunnen worden verkleind door grote indelingen te splitsen in meerdere subindelingen of door de grootte van de uitvoer die wordt geretourneerd door de activiteit en suborchestratorfuncties te verkleinen die worden aanroepen. U kunt ook het geheugengebruik verminderen door gelijktijdigheidsbeperkingen per VM te verlagen om te beperken hoeveel indelingen gelijktijdig in het geheugen worden geladen.

Tabel Exemplaren

De tabel Exemplaren bevat de statussen van alle indelings- en entiteitsexemplaren binnen een taakhub. Wanneer exemplaren worden gemaakt, worden nieuwe rijen toegevoegd aan deze tabel. De partitiesleutel van deze tabel is de id van het indelingsexemplaar of de entiteitssleutel en de rijsleutel is een lege tekenreeks. Er is één rijindeling of entiteitsexemplaar.

Deze tabel wordt gebruikt om te voldoen aan queryaanvragen van exemplaren van code , evenals http-API-aanroepen van statusquery's. Deze wordt uiteindelijk consistent gehouden met de inhoud van de eerder genoemde geschiedenistabel . Het gebruik van een afzonderlijke Azure Storage-tabel om op deze manier efficiënt te voldoen aan exemplaarquerybewerkingen, wordt beïnvloed door het patroon Command and Query Responsibility Segregation (CQRS).

Tip

Met de partitionering van de tabel Instances kunnen miljoenen indelingsexemplaren worden opgeslagen zonder merkbare invloed op runtimeprestaties of -schaal. Het aantal exemplaren kan echter een aanzienlijke invloed hebben op de prestaties van query's met meerdere exemplaren. Als u de hoeveelheid gegevens wilt beheren die in deze tabellen zijn opgeslagen, kunt u overwegen om oude exemplaargegevens periodiek op te lossen.

Partitiestabel

Notitie

Deze tabel wordt alleen weergegeven in de taakhub wanneer Table Partition Manager deze is ingeschakeld. Als u deze wilt toepassen, configureert u useTablePartitionManagement de instelling in de host.json van uw app.

De tabel Partities slaat de status van partities voor de Durable Functions-app op en wordt gebruikt om partities over de werkrollen van uw app te distribueren. Er is één rij per partitie.

Wachtrijen

Orchestrator-, entiteits- en activiteitsfuncties worden allemaal geactiveerd door interne wachtrijen in de taakhub van de functie-app. Het gebruik van wachtrijen op deze manier biedt betrouwbare garanties voor 'ten minste één keer'-berichtbezorging. Er zijn twee soorten wachtrijen in Durable Functions: de besturingswachtrij en de werkitemwachtrij.

De werkitemwachtrij

Er is één werkitemwachtrij per taakhub in Durable Functions. Het is een eenvoudige wachtrij en gedraagt zich op dezelfde manier als elke andere queueTrigger wachtrij in Azure Functions. Deze wachtrij wordt gebruikt om stateless activiteitsfuncties te activeren door één bericht tegelijk in de wachtrij te plaatsen. Elk van deze berichten bevat invoer van activiteitsfuncties en aanvullende metagegevens, zoals welke functie moet worden uitgevoerd. Wanneer een Durable Functions-toepassing wordt uitgeschaald naar meerdere VM's, concurreren deze VM's allemaal om taken te verkrijgen uit de werkitemwachtrij.

Wachtrij(en) beheren

Er zijn meerdere besturingswachtrijen per taakhub in Durable Functions. Een besturingswachtrij is geavanceerder dan de eenvoudigere werkitemwachtrij . Besturingswachtrijen worden gebruikt om de stateful orchestrator- en entiteitsfuncties te activeren. Omdat de orchestrator- en entiteitsfunctieinstanties stateful singletons zijn, is het belangrijk dat elke indeling of entiteit slechts door één werkrol tegelijk wordt verwerkt. Om deze beperking te bereiken, wordt elk indelingsexemplaar of elke entiteit toegewezen aan één besturingswachtrij. Deze besturingswachtrijen worden verdeeld over werkrollen om ervoor te zorgen dat elke wachtrij slechts door één werkrol tegelijk wordt verwerkt. Meer informatie over dit gedrag vindt u in volgende secties.

Beheerwachtrijen bevatten verschillende indelingslevenscyclusberichtentypen. Voorbeelden hiervan zijn orchestratorbeheerberichten, reactieberichten van activiteitsfuncties en timerberichten. In één peiling worden maximaal 32 berichten uit een controlewachtrij verwijderd. Deze berichten bevatten nettoladinggegevens en metagegevens, waaronder het indelingsexemplaar waarvoor deze is bedoeld. Als meerdere berichten in de wachtrij zijn bedoeld voor hetzelfde indelingsexemplaar, worden ze verwerkt als een batch.

Berichten in de wachtrij beheren worden voortdurend gepolerd met behulp van een achtergrondthread. De batchgrootte van elke wachtrijpeiling wordt bepaald door de controlQueueBatchSize instelling in host.json en heeft een standaardwaarde van 32 (de maximale waarde die wordt ondersteund door Azure Queues). Het maximum aantal vooraf geplaatste berichten in de controlewachtrij die in het geheugen worden gebufferd, wordt bepaald door de controlQueueBufferThreshold instelling in host.json. De standaardwaarde voor controlQueueBufferThreshold varieert afhankelijk van verschillende factoren, waaronder het type hostingabonnement. Zie de documentatie host.json schema voor meer informatie over deze instellingen.

Tip

Door de waarde voor één controlQueueBufferThreshold indeling of entiteit te verhogen, kunnen gebeurtenissen sneller worden verwerkt. Het verhogen van deze waarde kan echter ook leiden tot een hoger geheugengebruik. Het hogere geheugengebruik is deels te wijten aan het ophalen van meer berichten uit de wachtrij en deels door het ophalen van meer indelingsgeschiedenissen in het geheugen. Het verminderen van de waarde hiervoor controlQueueBufferThreshold kan daarom een effectieve manier zijn om het geheugengebruik te verminderen.

Polling van wachtrijen

De duurzame taakextensie implementeert een willekeurig exponentieel uitstelalgoritme om het effect van inactieve wachtrijen op de opslagtransactiekosten te verminderen. Wanneer er een bericht wordt gevonden, controleert de runtime onmiddellijk op een ander bericht. Wanneer er geen bericht wordt gevonden, wacht het even voordat u het opnieuw probeert. Na volgende mislukte pogingen om een wachtrijbericht te krijgen, blijft de wachttijd toenemen totdat de maximale wachttijd is bereikt, wat standaard 30 seconden is.

De maximale pollingvertraging kan worden geconfigureerd via de maxQueuePollingInterval eigenschap in het host.json bestand. Als u deze eigenschap instelt op een hogere waarde, kan dit leiden tot een hogere latentie voor berichtverwerking. Hogere latenties worden alleen verwacht na perioden van inactiviteit. Als u deze eigenschap instelt op een lagere waarde, kan dit leiden tot hogere opslagkosten vanwege verhoogde opslagtransacties.

Notitie

Wanneer u in de Azure Functions Consumption- en Premium-abonnementen werkt, controleert de Azure Functions Scale Controller elke controle- en werkitemwachtrij één keer per 10 seconden. Deze aanvullende polling is nodig om te bepalen wanneer functie-app-exemplaren moeten worden geactiveerd en om schaalbeslissingen te nemen. Op het moment van schrijven is dit interval van 10 seconden constant en kan niet worden geconfigureerd.

Startvertragingen voor indeling

Orchestrations-exemplaren worden gestart door een bericht in een ExecutionStarted van de besturingswachtrijen van de taakhub te plaatsen. Onder bepaalde omstandigheden kunt u vertragingen van meerdere seconden observeren tussen wanneer een indeling wordt uitgevoerd en wanneer deze daadwerkelijk wordt uitgevoerd. Gedurende dit tijdsinterval blijft het indelingsexemplaar in de Pending status. Er zijn twee mogelijke oorzaken van deze vertraging:

• Backlogged control queues: Als de besturingswachtrij voor dit exemplaar een groot aantal berichten bevat, kan het enige tijd duren voordat het ExecutionStarted bericht wordt ontvangen en verwerkt door de runtime. Er kunnen berichtenachterstanden optreden wanneer indelingen veel gebeurtenissen gelijktijdig verwerken. Gebeurtenissen die naar de besturingswachtrij gaan, omvatten begingebeurtenissen voor indelingen, voltooiing van activiteiten, duurzame timers, beëindiging en externe gebeurtenissen. Als deze vertraging zich onder normale omstandigheden voordoet, kunt u overwegen een nieuwe taakhub te maken met een groter aantal partities. Als u meer partities configureert, zorgt u ervoor dat de runtime meer controlewachtrijen voor belastingdistributie maakt. Elke partitie komt overeen met 1:1 met een besturingswachtrij, met maximaal 16 partities.

• Uitstel van pollingvertragingen: Een andere veelvoorkomende oorzaak van indelingsvertragingen is het eerder beschreven back-off pollinggedrag voor controlewachtrijen. Deze vertraging wordt echter alleen verwacht wanneer een app wordt uitgeschaald naar twee of meer exemplaren. Als er slechts één app-exemplaar is of als het app-exemplaar dat de indeling start, ook hetzelfde exemplaar is dat de doelbeheerwachtrij peilt, is er geen pollingvertraging in de wachtrij. Uitstel van pollingvertragingen kan worden verminderd door de host.json-instellingen bij te werken, zoals eerder is beschreven.

Blobs

In de meeste gevallen gebruikt Durable Functions geen Azure Storage-blobs om gegevens vast te houden. Wachtrijen en tabellen hebben echter groottelimieten waardoor Durable Functions niet alle vereiste gegevens in een opslagrij of wachtrijbericht kan persistent maken. Als een stukje gegevens dat moet worden bewaard in een wachtrij bijvoorbeeld groter is dan 45 kB wanneer ze worden geserialiseerd, worden de gegevens door Durable Functions gecomprimeerd en opgeslagen in een blob. Wanneer gegevens op deze manier worden bewaard in blobopslag, slaat Durable Function een verwijzing naar die blob op in de tabelrij of wachtrijbericht. Wanneer Durable Functions de gegevens moet ophalen, worden deze automatisch opgehaald uit de blob. Deze blobs worden opgeslagen in de blobcontainer <taskhub>-largemessages.

Prestatieoverwegingen

De extra compressie- en blobbewerkingsstappen voor grote berichten kunnen duur zijn in termen van CPU- en I/O-latentiekosten. Daarnaast moet Durable Functions persistente gegevens in het geheugen laden en dit mogelijk doen voor veel verschillende functie-uitvoeringen tegelijk. Als gevolg hiervan kan het behouden van grote gegevenspayloads ook een hoog geheugengebruik veroorzaken. U kunt geheugenoverhead minimaliseren door grote nettoladingen van gegevens handmatig te bewaren (bijvoorbeeld in blobopslag) en in plaats daarvan verwijzingen naar deze gegevens door te geven. Op deze manier kunnen de gegevens alleen worden geladen wanneer dat nodig is om redundante belasting te voorkomen tijdens het opnieuw afspelen van orchestratorfuncties. Het opslaan van nettoladingen naar lokale schijven wordt echter niet aanbevolen omdat de status op de schijf niet gegarandeerd beschikbaar is, omdat functies gedurende hun levensduur op verschillende VM's kunnen worden uitgevoerd.

Selectie van opslagaccount

De wachtrijen, tabellen en blobs die door Durable Functions worden gebruikt, worden gemaakt in een geconfigureerd Azure Storage-account. Het te gebruiken account kan worden opgegeven met behulp van de durableTask/storageProvider/connectionStringName instelling (of durableTask/azureStorageConnectionStringName instelling in Durable Functions 1.x) in het host.json bestand.

Durable Functions 2.x

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "connectionStringName": "MyStorageAccountAppSetting"
      }
    }
  }
}

Durable Functions 1.x

{
  "extensions": {
    "durableTask": {
      "azureStorageConnectionStringName": "MyStorageAccountAppSetting"
    }
  }
}

Als dit niet is opgegeven, wordt het standaardopslagaccount AzureWebJobsStorage gebruikt. Voor prestatiegevoelige workloads wordt het configureren van een niet-standaardopslagaccount echter aanbevolen. Durable Functions maakt intensief gebruik van Azure Storage en het gebruik van een toegewezen opslagaccount isoleert het opslaggebruik van Durable Functions van het interne gebruik door de Azure Functions-host.

Notitie

Azure Storage-accounts voor algemeen gebruik zijn vereist wanneer u de Azure Storage-provider gebruikt. Alle andere typen opslagaccounts worden niet ondersteund. We raden u ten zeerste aan verouderde v1-opslagaccounts voor algemeen gebruik te gebruiken voor Durable Functions. De nieuwere v2-opslagaccounts kunnen aanzienlijk duurder zijn voor Durable Functions-workloads. Zie de overzichtsdocumentatie van het Opslagaccount voor meer informatie over Azure Storage-accounttypen.

Orchestrator uitschalen

Hoewel activiteitsfuncties oneindig kunnen worden uitgeschaald door meer VM's elastisch toe te voegen, worden afzonderlijke orchestratorexemplaren en entiteiten beperkt tot één partitie en wordt het maximum aantal partities gebonden door de partitionCount instelling in uw host.json.

Notitie

Over het algemeen zijn orchestratorfuncties bedoeld om lichtgewicht te zijn en mogen geen grote hoeveelheden rekenkracht vereisen. Het is daarom niet nodig om een groot aantal partities in de besturingswachtrij te maken om een grote doorvoer voor indelingen te krijgen. Het grootste deel van het zware werk moet worden uitgevoerd in staatloze activiteitsfuncties, die oneindig kunnen worden uitgeschaald.

Het aantal besturingswachtrijen wordt gedefinieerd in het host.json-bestand . In het volgende voorbeeld host.json codefragment de durableTask/storageProvider/partitionCount eigenschap (of durableTask/partitionCount in Durable Functions 1.x) instelt op 3. Houd er rekening mee dat er zoveel besturingswachtrijen zijn als er partities zijn.

Durable Functions 2.x

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

Durable Functions 1.x

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

Een taakhub kan worden geconfigureerd met 1 tot 16 partities. Als dit niet is opgegeven, is het standaardaantal partities 4.

Tijdens scenario's met weinig verkeer wordt uw toepassing ingeschaald, zodat partities worden beheerd door een klein aantal werkrollen. Bekijk bijvoorbeeld het onderstaande diagram.

In het vorige diagram zien we dat orchestrators 1 tot en met 6 taakverdeling hebben tussen partities. Op dezelfde manier worden partities, zoals activiteiten, verdeeld over werkrollen. Partities worden verdeeld over werkrollen, ongeacht het aantal orchestrators dat aan de slag gaat.

Als u gebruikmaakt van de Azure Functions Consumption- of Elastic Premium-abonnementen, of als u automatisch schalen op basis van belasting hebt geconfigureerd, worden er meer werkrollen toegewezen wanneer verkeer toeneemt en partities uiteindelijk taakverdeling krijgen voor alle werknemers. Als we blijven uitschalen, wordt uiteindelijk elke partitie uiteindelijk beheerd door één werkrol. Aan de andere kant blijven activiteiten gelijkmatig verdeeld over alle werknemers. Dit wordt weergegeven in de onderstaande afbeelding.

De bovengrens van het maximum aantal gelijktijdige actieve indelingen op een bepaald moment is gelijk aan het aantal werknemers dat aan uw toepassing is toegewezen, en de waarde voor maxConcurrentOrchestratorFunctions. Deze bovengrens kan nauwkeuriger worden gemaakt wanneer uw partities volledig zijn uitgeschaald tussen werkrollen. Wanneer de schaal volledig is uitgeschaald en omdat elke werkrol slechts één Functions-hostexemplaren heeft, is het maximum aantal actieve gelijktijdige orchestrator-exemplaren gelijk aan het aantal partities dat uw waarde voor maxConcurrentOrchestratorFunctions.

Notitie

In deze context betekent actief dat een indeling of entiteit wordt geladen in het geheugen en nieuwe gebeurtenissen verwerkt. Als de indeling of entiteit wacht op meer gebeurtenissen, zoals de retourwaarde van een activiteitsfunctie, wordt deze uit het geheugen verwijderd en wordt deze niet langer als actief beschouwd. Indelingen en entiteiten worden vervolgens alleen opnieuw in het geheugen geladen wanneer er nieuwe gebeurtenissen moeten worden verwerkt. Er is geen praktisch maximumaantal indelingen of entiteiten dat kan worden uitgevoerd op één virtuele machine, zelfs als ze allemaal de status Actief hebben. De enige beperking is het aantal gelijktijdig actieve orchestration- of entiteitsexemplaren.

In de onderstaande afbeelding ziet u een volledig uitgeschaald scenario waarin meer orchestrators worden toegevoegd, maar sommige inactief zijn, weergegeven in grijs.

Tijdens uitschalen kunnen leases van beheerwachtrijen opnieuw worden gedistribueerd over functions-hostexemplaren om ervoor te zorgen dat partities gelijkmatig worden gedistribueerd. Deze leases worden intern geïmplementeerd als Azure Blob Storage-leases en zorgen ervoor dat elk afzonderlijk indelingsexemplaar of elke entiteit slechts op één hostexemplaar tegelijk wordt uitgevoerd. Als een taakhub is geconfigureerd met drie partities (en dus drie besturingswachtrijen), kunnen indelingsexemplaren en entiteiten worden verdeeld over alle drie de lease-holding hostinstanties. Er kunnen extra VM's worden toegevoegd om de capaciteit voor de uitvoering van de activiteitsfunctie te vergroten.

In het volgende diagram ziet u hoe de Azure Functions-host communiceert met de opslagentiteiten in een uitgeschaalde omgeving.

Zoals in het vorige diagram wordt weergegeven, concurreren alle VM's voor berichten in de wachtrij met werkitems. Er kunnen echter slechts drie VM's berichten ophalen uit beheerwachtrijen en elke VIRTUELE machine vergrendelt één besturingswachtrij.

Indelingsexemplaren en entiteiten worden verdeeld over alle exemplaren van de beheerwachtrij. De distributie wordt uitgevoerd door de instantie-id van de orchestration of de naam en sleutelpaar van de entiteit te hashen. Indelingsexemplaar-id's zijn standaard willekeurige GUID's, zodat exemplaren gelijkmatig worden verdeeld over alle besturingswachtrijen.

Over het algemeen zijn orchestratorfuncties bedoeld om lichtgewicht te zijn en mogen geen grote hoeveelheden rekenkracht vereisen. Het is daarom niet nodig om een groot aantal beheerwachtrijpartities te maken om een grote doorvoer voor indelingen te krijgen. Het grootste deel van het zware werk moet worden uitgevoerd in staatloze activiteitsfuncties, die oneindig kunnen worden uitgeschaald.

Uitgebreide sessies

Uitgebreide sessies is een cachingmechanisme waarmee indelingen en entiteiten in het geheugen worden bewaard, zelfs nadat ze klaar zijn met het verwerken van berichten. Het typische effect van het inschakelen van uitgebreide sessies is verminderde I/O ten opzichte van de onderliggende duurzame opslag en de algehele verbeterde doorvoer.

U kunt uitgebreide sessies inschakelen door deze in te stellen durableTask/extendedSessionsEnabled true in het host.json-bestand . De durableTask/extendedSessionIdleTimeoutInSeconds instelling kan worden gebruikt om te bepalen hoe lang een niet-actieve sessie in het geheugen wordt gehouden:

Functions 2.0

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

Functions 1.0

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

Er zijn twee mogelijke nadelen van deze instelling om rekening mee te houden:

1. Er is een algehele toename van het geheugengebruik van de functie-app, omdat niet-actieve exemplaren niet zo snel uit het geheugen worden verwijderd.
2. Er kan een algehele afname van de doorvoer zijn als er veel gelijktijdige, afzonderlijke, kortstondige orchestrator- of entiteitsfunctieuitvoeringen zijn.

Als een voorbeeld durableTask/extendedSessionIdleTimeoutInSeconds is ingesteld op 30 seconden, neemt een kortdurende orchestrator- of entiteitsfunctieaflevering die in minder dan 1 seconde wordt uitgevoerd nog steeds geheugen in beslag gedurende 30 seconden. Het telt ook mee op basis van het durableTask/maxConcurrentOrchestratorFunctions eerder genoemde quotum, waardoor andere orchestrator- of entiteitsfuncties mogelijk niet kunnen worden uitgevoerd.

De specifieke effecten van uitgebreide sessies op orchestrator- en entiteitsfuncties worden beschreven in de volgende secties.

Notitie

Uitgebreide sessies worden momenteel alleen ondersteund in .NET-talen, zoals C# (alleen in-process model) of F#. true Het instellen extendedSessionsEnabled op andere platforms kan leiden tot runtimeproblemen, zoals het op de achtergrond niet uitvoeren van activiteiten en door orchestration geactiveerde functies.

Orchestrator-functie opnieuw afspelen

Zoals eerder vermeld, worden orchestratorfuncties opnieuw afgespeeld met behulp van de inhoud van de tabel Geschiedenis . Standaard wordt de orchestratorfunctiecode telkens opnieuw afgespeeld wanneer een batch berichten uit een besturingswachtrij wordt verwijderd. Zelfs als u het fan-out-, fan-in-patroon gebruikt en wacht tot alle taken zijn voltooid (bijvoorbeeld in Task.WhenAll() .NET, context.df.Task.all() in JavaScript of context.task_all() in Python), worden er herhalingen uitgevoerd wanneer batches met taakantwoorden in de loop van de tijd worden verwerkt. Wanneer uitgebreide sessies zijn ingeschakeld, worden exemplaren van orchestratorfuncties langer in het geheugen bewaard en kunnen nieuwe berichten worden verwerkt zonder dat er een volledige geschiedenis opnieuw wordt afgespeeld.

De prestatieverbetering van uitgebreide sessies wordt meestal waargenomen in de volgende situaties:

• Wanneer er een beperkt aantal indelingsexemplaren gelijktijdig wordt uitgevoerd.
• Wanneer indelingen een groot aantal opeenvolgende acties (bijvoorbeeld honderden activiteitsfunctieoproepen) hebben die snel worden voltooid.
• Wanneer orchestrations fan-out en fan-in een groot aantal acties die rond dezelfde tijd voltooien.
• Wanneer orchestratorfuncties grote berichten moeten verwerken of cpu-intensieve gegevensverwerking moeten uitvoeren.

In alle andere situaties is er doorgaans geen waarneembare prestatieverbetering voor orchestratorfuncties.

Notitie

Deze instellingen mogen alleen worden gebruikt nadat een orchestratorfunctie volledig is ontwikkeld en getest. Het standaard agressieve herhalingsgedrag kan nuttig zijn voor het detecteren van schendingen van orchestrator-functiecodebeperkingen tijdens de ontwikkeling en is daarom standaard uitgeschakeld.

Prestatiedoelen

In de volgende tabel ziet u de verwachte maximumdoorvoeraantallen voor de scenario's die worden beschreven in de sectie Prestatiedoelen van het artikel Prestatie- en schaalaanpassing.

'Exemplaar' verwijst naar één exemplaar van een orchestratorfunctie die wordt uitgevoerd op één kleine VM (A1) in Azure-app Service. In alle gevallen wordt ervan uitgegaan dat uitgebreide sessies zijn ingeschakeld. De werkelijke resultaten kunnen variëren, afhankelijk van de CPU- of I/O-werkzaamheden die door de functiecode worden uitgevoerd.

Scenario	Maximale doorvoer
Uitvoering van sequentiële activiteit	5 activiteiten per seconde, per exemplaar
Parallelle uitvoering van activiteit (fan-out)	100 activiteiten per seconde, per exemplaar
Parallelle responsverwerking (fan-in)	150 antwoorden per seconde, per exemplaar
Externe gebeurtenisverwerking	50 gebeurtenissen per seconde, per exemplaar
Verwerking van entiteitsbewerkingen	64 bewerkingen per seconde

Als u de verwachte doorvoernummers niet ziet en het CPU- en geheugengebruik in orde wordt weergegeven, controleert u of de oorzaak is gerelateerd aan de status van uw opslagaccount. De Durable Functions-extensie kan een aanzienlijke belasting voor een Azure Storage-account tot gevolg hebben dat er voldoende hoge belastingen worden geladen, wat kan leiden tot beperking van het opslagaccount.

Tip

In sommige gevallen kunt u de doorvoer van externe gebeurtenissen, activiteitenventilatie en entiteitsbewerkingen aanzienlijk verhogen door de waarde van de controlQueueBufferThreshold instelling in host.json te verhogen. Als u deze waarde verder verhoogt dan de standaardwaarde, zorgt u ervoor dat de Durable Task Framework-opslagprovider meer geheugen gebruikt om deze gebeurtenissen agressief toe te passen, waardoor vertragingen worden verminderd die zijn gekoppeld aan het verwijderen van berichten uit de Azure Storage-besturingswachtrijen. Zie de host.json referentiedocumentatie voor meer informatie.

Flex Consumption Plan

Het Flex Consumption-abonnement is een Azure Functions-hostingabonnement dat veel van de voordelen van het Verbruiksabonnement biedt, waaronder een serverloos factureringsmodel, terwijl er ook nuttige functies worden toegevoegd, zoals privénetwerken, selectie van instantiegeheugengrootte en volledige ondersteuning voor verificatie van beheerde identiteiten.

Azure Storage is momenteel de enige ondersteunde opslagprovider voor Durable Functions wanneer deze wordt gehost in het Flex Consumption-abonnement.

Volg deze aanbevelingen voor prestaties bij het hosten van Durable Functions in het Flex Consumption-abonnement:

• Stel het aantal exemplaren dat altijd gereed is voor de durable groep in op 1. Dit zorgt ervoor dat er altijd één exemplaar gereed is voor het verwerken van aanvragen met betrekking tot Durable Functions, waardoor de koude start van de toepassing wordt verminderd.
• Verminder het polling-interval van de wachtrij tot 10 seconden of minder. Omdat dit type plan gevoeliger is voor pollingvertragingen in de wachtrij, zal het verlagen van het polling-interval helpen de frequentie van pollingbewerkingen te verhogen, zodat aanvragen sneller worden verwerkt. Frequentere pollingbewerkingen leiden echter tot hogere kosten voor een Azure Storage-account.

Verwerking van hoge doorvoer

De architectuur van de Back-end van Azure Storage brengt bepaalde beperkingen met zich mee voor de maximale theoretische prestaties en schaalbaarheid van Durable Functions. Als uw test laat zien dat Durable Functions in Azure Storage niet voldoet aan uw doorvoervereisten, moet u in plaats daarvan overwegen om de Netherite-opslagprovider voor Durable Functions te gebruiken.

Als u de haalbare doorvoer voor verschillende basisscenario's wilt vergelijken, raadpleegt u de sectie Basisscenario's van de documentatie van de Netherite-opslagprovider.

De back-end van Netherite Storage is ontworpen en ontwikkeld door Microsoft Research. Het maakt gebruik van Azure Event Hubs en de SNELLERE databasetechnologie boven op Azure Page Blobs. Het ontwerp van Netherite maakt een aanzienlijk hogere doorvoerverwerking van indelingen en entiteiten mogelijk vergeleken met andere providers. In sommige benchmarkscenario's werd de doorvoer met meer dan een groottevolgorde weergegeven in vergelijking met de standaard Azure Storage-provider.

Zie de documentatie van de Durable Functions-opslagproviders voor meer informatie over de ondersteunde opslagproviders voor Durable Functions en hoe deze zich verhouden.

Volgende stappen

Meer informatie over herstel na noodgevallen en geo-distributie