Gelijktijdigheid in Azure Functions

In Azure Functions kan één exemplaar van een functie-app meerdere gebeurtenissen gelijktijdig worden verwerkt. Omdat deze worden uitgevoerd op hetzelfde rekenproces, delen ze geheugen, CPU en verbindingsresources. In bepaalde hostingabonnementen zorgt een hoge vraag naar een specifiek exemplaar ervoor dat de Functions-host automatisch nieuwe exemplaren maakt om de verhoogde belasting af te handelen. In deze dynamische schaalplannen is er een afweging tussen gelijktijdigheid en schaalgedrag. Om meer controle te bieden over hoe uw app wordt uitgevoerd, biedt Functions een manier om het aantal gelijktijdige uitvoeringen te beheren.

Functies bieden twee belangrijke manieren om gelijktijdigheid te beheren:

• Vaste gelijktijdigheid per instantie: U kunt limieten instellen op het niveau van de host voor gelijktijdigheid die specifiek zijn voor individuele triggers. Dit model is het standaardgedrag voor gelijktijdigheid voor Functions.
• Dynamische gelijktijdigheid: voor bepaalde triggertypen kan de Functions-host automatisch het beste gelijktijdigheidsniveau voor die trigger in uw functie-app bepalen. U moet zich aanmelden voor dit gelijktijdigheidsmodel.

In dit artikel worden de gelijktijdigheidsgedragen van gebeurtenisgestuurde triggers in Functions beschreven en hoe dit gedrag van invloed is op schalen in dynamische plannen. Ook worden de vaste modellen per exemplaar en dynamische gelijktijdigheidsmodellen vergeleken.

Schaalbaarheid versus gelijktijdigheid

Voor functies die gebruikmaken van triggers op basis van gebeurtenissen of reageren op HTTP-aanvragen, kunt u snel de limieten van gelijktijdige uitvoeringen bereiken tijdens perioden met een hoge vraag. Tijdens dergelijke perioden moet u uw functie-app kunnen schalen door instanties toe te voegen om een achterstand te voorkomen bij het verwerken van binnenkomende aanvragen. De manier waarop we uw app schalen, is afhankelijk van uw hostingabonnement:

Voordat er schalen kunnen optreden, probeert uw functie-app toenames in belasting af te handelen door meerdere aanroepen van hetzelfde type in één exemplaar af te handelen. Als gevolg hiervan zijn deze gelijktijdige uitvoeringen op een bepaald exemplaar rechtstreeks van invloed op schaalbeslissingen. Wanneer een app in een dynamisch schaalplan bijvoorbeeld een gelijktijdigheidslimiet bereikt, moet deze mogelijk worden geschaald om de binnenkomende vraag bij te houden.

De balans tussen schaal en gelijktijdigheid die u in uw app probeert te bereiken, is afhankelijk van waar knelpunten kunnen optreden: bij verwerking (CPU-intensieve procesbeperkingen) of in een downstreamservice (op I/O gebaseerde beperkingen).

Gelijktijdigheid per instantie opgelost

De meeste triggers ondersteunen standaard een vast gelijktijdigheidsconfiguratiemodel per exemplaar via schaalaanpassing op basis van doel. In dit model heeft elk triggertype een gelijktijdigheidslimiet per exemplaar.

U kunt de standaardwaarden voor gelijktijdigheid voor de meeste triggers overschrijven door een specifieke gelijktijdigheid per instantie in te stellen voor dat triggertype. Voor veel triggers configureert u gelijktijdigheidsinstellingen in het host.json-bestand. De Azure Service Bus-trigger biedt bijvoorbeeld zowel een MaxConcurrentCalls als een MaxConcurrentSessions instelling in host.json. Deze instellingen werken samen om het maximum aantal berichten te beheren dat elke functie-app gelijktijdig op elk exemplaar verwerkt.

In bepaalde scenario's voor schaalaanpassing op basis van doel, zoals wanneer u een Apache Kafka- of Azure Cosmos DB-trigger gebruikt, bevindt de gelijktijdigheidsconfiguratie zich in de functiedeclaratie, niet in het host.json bestand. Andere triggertypen hebben ingebouwde mechanismen voor taakverdeling van uitvoeringen over verschillende instanties. Azure Event Hubs en Azure Cosmos DB maken bijvoorbeeld gebruik van een schema op basis van partities.

Voor triggertypen die ondersteuning bieden voor gelijktijdigheidsconfiguratie, worden de gelijktijdigheidsinstellingen toegepast op alle actieve exemplaren. Op deze manier kunt u de maximale gelijktijdigheid voor uw functies op elk exemplaar beheren. Als uw functie bijvoorbeeld CPU-intensief of een hoge belasting van middelen heeft, kunt u ervoor kiezen om de gelijktijdigheid te beperken om de gezondheid van de exemplaren te waarborgen. In dit geval kunt u vertrouwen op schaalvergroting om verhoogde werkbelasting te verwerken. Als uw functie aanvragen indient naar een downstream service die wordt beperkt, moet u ook overwegen gelijktijdigheid te beperken om te voorkomen dat de downstream service overbelast raakt.

Gelijktijdigheid van HTTP-trigger

Alleen van toepassing op het Flex Consumption-abonnement

Gelijktijdigheid van HTTP-triggers is een speciaal soort vaste gelijktijdigheid per exemplaar. In gelijktijdigheid van HTTP-triggers is de standaard gelijktijdigheid ook afhankelijk van de instantiegrootte.

Het Flex Consumption-plan schaalt alle HTTP-triggers samen als een groep. Zie Schalen per functie voor meer informatie.

De volgende tabel geeft de standaardinstelling voor gelijktijdigheid aan voor HTTP-triggers op een bepaald exemplaar, op basis van de geconfigureerde geheugengrootte van het exemplaar:

^*In Python-apps gebruiken alle instantiegrootten standaard een HTTP-triggergelijktijdigheidsniveau van één.

Deze standaardwaarden moeten in de meeste gevallen goed werken en u kunt ermee beginnen. Houd er rekening mee dat het verhogen van de HTTP-gelijktijdigheidswaarde bij een bepaald aantal HTTP-aanvragen het aantal instanties vermindert dat nodig is om HTTP-aanvragen te verwerken. Op dezelfde manier vereist het verlagen van de HTTP-gelijktijdigheidswaarde meer exemplaren om dezelfde belasting te verwerken.

Als u de HTTP-gelijktijdigheid wilt verfijnen, kunt u dit doen met behulp van de Azure CLI. Zie Http-gelijktijdigheidslimieten instellen voor meer informatie.

De standaardwaarden voor gelijktijdigheid in de voorgaande tabel zijn alleen van toepassing wanneer u uw eigen INSTELLING voor HTTP-gelijktijdigheid niet instelt. Wanneer u niet expliciet een HTTP-gelijktijdigheidsinstelling instelt, neemt de standaard gelijktijdigheid toe. Dit is te zien in de tabel wanneer u de grootte van het exemplaar wijzigt. Nadat u specifiek een HTTP-gelijktijdigheidswaarde hebt ingesteld, blijft die waarde behouden ondanks wijzigingen in de instantiegrootte.

Optimale vaste gelijktijdigheid per instantie bepalen

Vaste gelijktijdigheidsconfiguraties per exemplaar bieden u controle over bepaald triggergedrag, zoals het beperken van uw functies. Maar het kan lastig zijn om de optimale waarden voor deze instellingen te bepalen. Over het algemeen moet u acceptabele waarden bereiken door een iteratief proces van belastingstests. Zelfs nadat u een set waarden hebt bepaald die voor een bepaald laadprofiel werken, kan het aantal gebeurtenissen dat afkomstig is van uw verbonden services van dag tot dag veranderen. Deze variabiliteit kan ertoe leiden dat uw app wordt uitgevoerd met suboptimale waarden. Uw functie-app kan bijvoorbeeld veeleisende berichtbelastingen verwerken op de laatste dag van de week, waardoor u concurrentie moet beperken. Tijdens de rest van de week kunnen de berichtbelasting echter lichter zijn, wat betekent dat u de rest van de week een hoger niveau van gelijktijdigheid kunt gebruiken.

In het ideale geval moet het systeem toestaan dat instanties zoveel mogelijk werk verwerken terwijl elk exemplaar gezond blijft en latenties laag blijven. Dynamische gelijktijdigheid is hiervoor ontworpen.

Dynamische gelijktijdigheid

Functions biedt een dynamisch gelijktijdigheidsmodel dat het configureren van gelijktijdigheid vereenvoudigt voor alle functie-apps die in hetzelfde plan worden uitgevoerd.

Vergoedingen

Dynamische gelijktijdigheid biedt de volgende voordelen:

• Vereenvoudigde configuratie: u hoeft de gelijktijdigheidsinstellingen per trigger niet meer handmatig te bepalen. Het systeem leert de optimale waarden voor uw workload in de loop van de tijd.
• Dynamische aanpassingen: Gelijktijdigheid wordt dynamisch in realtime omhoog of omlaag aangepast, waardoor het systeem zich kan aanpassen aan veranderende belastingpatronen in de loop van de tijd.
• Instantiestatusbeveiliging: De runtime beperkt gelijktijdigheid tot niveaus die een exemplaar van een functie-app comfortabel kan verwerken. Deze limieten beschermen de app tegen overbelasting door meer werk te doen dan het zou moeten.
• Verbeterde doorvoer: de algehele doorvoer wordt verbeterd, omdat afzonderlijke exemplaren niet meer werk trekken dan ze snel kunnen verwerken. Als gevolg hiervan wordt het werk effectiever gebalanceerd over instances. Voor functies die hogere belastingen kunnen verwerken, kan een hogere doorvoer worden verkregen door de gelijktijdigheid van waarden boven de standaardconfiguratie te verhogen.

Dynamische gelijktijdigheidsconfiguratie

U kunt dynamische gelijktijdigheid op hostniveau inschakelen in het host.json-bestand . Wanneer deze optie is ingeschakeld, worden de gelijktijdigheidsniveaus van bindingsextensies die ondersteuning bieden voor deze functie, indien nodig automatisch aangepast. In deze gevallen overschrijven dynamische gelijktijdigheidsinstellingen alle handmatig geconfigureerde gelijktijdigheidsinstellingen.

Dynamische gelijktijdigheid is standaard uitgeschakeld. Wanneer u dynamische gelijktijdigheid inschakelt, begint gelijktijdigheid op een niveau van één voor elke functie. Het gelijktijdigheidsniveau wordt aangepast tot een optimale waarde, die door de host wordt bepaald.

U kunt dynamische gelijktijdigheid inschakelen in uw functie-app door de volgende instellingen toe te voegen aan uw host.json-bestand :

    { 
        "version": "2.0", 
        "concurrency": { 
            "dynamicConcurrencyEnabled": true, 
            "snapshotPersistenceEnabled": true 
        } 
    } 

Wanneer snapshotPersistenceEnabled is true, wat de standaardwaarde is, worden de geleerde gelijktijdigheidswaarden periodiek bewaard in de opslag. Nieuwe exemplaren beginnen met deze waarden in plaats van te beginnen op een niveau van één en het opnieuw te moeten leren.

Gelijktijdigheidsbeheer

Achter de schermen, wanneer dynamische gelijktijdigheid is ingeschakeld, wordt een gelijktijdigheidsbeheerproces op de achtergrond uitgevoerd. Deze manager bewaakt voortdurend metrische gegevens over de status van exemplaren, zoals cpu- en threadgebruik, en wijzigingen worden naar behoefte beperkt. Wanneer een of meer regelaars zijn ingeschakeld, wordt de gelijktijdigheid van de functie verlaagd totdat de host weer gezond is. Wanneer begrenzers zijn uitgeschakeld, kan de gelijktijdigheid toenemen. Verschillende heuristieken worden gebruikt om op intelligente wijze gelijktijdigheid naar behoefte omhoog of omlaag aan te passen op basis van deze beperkingen. In de loop van de tijd wordt gelijktijdigheid voor elke functie gestabiliseerd tot een bepaald niveau. Omdat het tijd kan duren om de optimale gelijktijdigheidswaarde te bepalen, gebruikt u dynamische gelijktijdigheid alleen als een suboptimale waarde in eerste instantie of na een periode van inactiviteit acceptabel is voor uw oplossing.

Gelijktijdigheidsniveaus worden beheerd voor elke afzonderlijke functie. Het systeem balanceert met name tussen resource-intensieve functies waarvoor een laag gelijktijdigheidsniveau en meer lichtgewicht functies nodig zijn die hogere gelijktijdigheid kunnen verwerken. De concurrentiebalans voor elke functie helpt de algehele gezondheid van de functie-app instantie te behouden.

Wanneer dynamische gelijktijdigheid is ingeschakeld, vindt u dynamische gelijktijdigheidsbeslissingen in uw logboeken. Logboekvermeldingen worden bijvoorbeeld toegevoegd wanneer verschillende drempels zijn ingeschakeld en telkens wanneer de gelijktijdigheid voor elke functie omhoog of omlaag wordt aangepast. Deze logboeken worden geschreven onder de logboekcategorie Host.Concurrency in de tabel traces .

Ondersteuning voor extensies

Dynamische gelijktijdigheid is ingeschakeld voor een functie-app op hostniveau en eventuele extensies die ondersteuning bieden voor dynamische gelijktijdigheid die in die modus worden uitgevoerd. Dynamische gelijktijdigheid vereist samenwerking tussen de host en afzonderlijke triggerextensies. Alleen de vermelde versies van de volgende extensies ondersteunen dynamische gelijktijdigheid.

Volgende stappen

Voor meer informatie raadpleegt u de volgende bronnen:

• Aanbevolen procedures voor betrouwbare Azure Functions
• Ontwikkelaarshandleiding voor Azure Functions
• Azure Functions-triggers en -bindingen