Delen via

Gelijktijdigheid in Azure Functions

  • Artikel

In dit artikel worden de gelijktijdigheidsgedragen van gebeurtenisgestuurde triggers in Azure Functions beschreven. Ook worden de statische en dynamische gelijktijdigheidsmodellen vergeleken.

Belangrijk

Het Flex Consumption-abonnement is momenteel beschikbaar als preview-versie.

In Functions kunt u meerdere uitvoeringsprocessen van een bepaalde functie tegelijk uitvoeren op één rekenproces. Denk bijvoorbeeld aan een geval waarin u drie verschillende functies in uw functie-app hebt die wordt uitgeschaald naar meerdere exemplaren om een verhoogde belasting te verwerken. In dit scenario wordt elke functie uitgevoerd als reactie op afzonderlijke aanroepen in alle drie de instanties en kan een bepaald exemplaar meerdere aanroepen van hetzelfde type verwerken. Houd er rekening mee dat de uitvoering van de functie op één exemplaar dezelfde geheugen-, CPU- en verbindingsbronnen deelt. Omdat meerdere functie-uitvoeringen gelijktijdig op elk exemplaar kunnen worden uitgevoerd, moet elke functie een manier hebben om het aantal gelijktijdige uitvoeringen te beheren.

Wanneer uw app wordt gehost in een dynamisch schaalplan (Verbruik, Flex Consumption of Premium), schaalt de host het aantal exemplaren van de functie-app omhoog of omlaag op basis van het aantal binnenkomende gebeurtenissen. Zie Gebeurtenisgestuurd schalen voor meer informatie. Wanneer u uw functies in een Dedicated (App Service)-plan host, moet u uw exemplaren handmatig configureren of een schema voor automatische schaalaanpassing instellen.

Deze schaalbeslissingen worden ook rechtstreeks beïnvloed door de gelijktijdigheid van uitvoeringen op een bepaald exemplaar. Wanneer een app in een dynamisch schaalplan een gelijktijdigheidslimiet bereikt, moet deze mogelijk worden geschaald om de binnenkomende vraag bij te houden.

Functies bieden twee belangrijke manieren om gelijktijdigheid te beheren:

Statische gelijktijdigheid

De meeste triggers ondersteunen standaard een statisch configuratiemodel op hostniveau. In dit model heeft elk triggertype een gelijktijdigheidslimiet per exemplaar. Voor de meeste triggers kunt u echter ook een specifieke gelijktijdigheid per instantie aanvragen voor dat triggertype. De Service Bus-trigger biedt bijvoorbeeld zowel een als MaxConcurrentCalls een MaxConcurrentSessions instelling in het host.json-bestand. Deze instellingen bepalen samen het maximum aantal berichten dat elke functie gelijktijdig verwerkt op elk exemplaar. Andere triggertypen hebben ingebouwde mechanismen voor taakverdelingsvocations tussen exemplaren. Event Hubs en Azure Cosmos DB maken bijvoorbeeld gebruik van een op partities gebaseerd schema.

Voor triggertypen die gelijktijdigheidsconfiguratie ondersteunen, worden de instellingen die u kiest toegepast op alle actieve exemplaren. Hiermee kunt u de maximale gelijktijdigheid voor uw functies op elk exemplaar beheren. Als uw functie bijvoorbeeld CPU of resource-intensief is, kunt u ervoor kiezen om gelijktijdigheid te beperken om exemplaren in orde te houden en te vertrouwen op schalen om verhoogde belastingen te verwerken. Als uw functie aanvragen indient naar een downstreamservice die wordt beperkt, moet u ook overwegen om gelijktijdigheid te beperken om te voorkomen dat de downstreamservice overbelast raakt.

Gelijktijdigheid van HTTP-trigger

Alleen van toepassing op het Flex Consumption-abonnement (preview)

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 grootte van het exemplaargeheugen.

Instantiegrootte (MB) Standaard gelijktijdigheid*
2048 16
4096 32

*Voor Python-apps is 1de standaard gelijktijdigheid van HTTP-triggers voor alle exemplarengrootten.

Deze standaardinstellingen moeten in de meeste gevallen goed werken en u begint met deze. 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. Voor het verlagen van de HTTP-gelijktijdigheidswaarde zijn meer exemplaren nodig om dezelfde belasting te verwerken.

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

De standaardwaarden voor gelijktijdigheid in de vorige tabel zijn alleen van toepassing wanneer u uw eigen HTTP-gelijktijdigheidsinstelling niet hebt ingesteld. Wanneer u geen INSTELLING voor HTTP-gelijktijdigheid expliciet hebt ingesteld, neemt de standaard gelijktijdigheid toe, zoals wordt weergegeven 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 statische gelijktijdigheid bepalen

Hoewel statische gelijktijdigheidsconfiguraties u de controle geven over bepaalde triggergedrag, zoals het beperken van uw functies, kan het 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 vastgesteld die voor een bepaald laadprofiel werken, kan het aantal gebeurtenissen dat afkomstig is van uw verbonden services van dag tot dag veranderen. Deze variabiliteit betekent dat uw app vaak kan worden uitgevoerd met suboptimale waarden. Uw functie-app kan bijvoorbeeld bijzonder veeleisende nettoladingen van berichten verwerken op de laatste dag van de week. Hiervoor moet u gelijktijdigheid beperken. Tijdens de rest van de week zijn de nettoladingen van het bericht echter eenvoudiger, wat betekent dat u de rest van de week een hoger gelijktijdigheidsniveau kunt gebruiken.

In het ideale geval willen we dat het systeem toestaat dat instanties zoveel mogelijk werk verwerken terwijl elk exemplaar in orde en latenties laag blijft, wat dynamische gelijktijdigheid is ontworpen.

Dynamische gelijktijdigheid

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

Notitie

Dynamische gelijktijdigheid wordt momenteel alleen ondersteund voor de Azure Blob-, Azure Queue- en Service Bus-triggers. Hiervoor moet u de versies gebruiken die worden vermeld in de sectie voor ondersteuning voor extensies hieronder.

Vergoedingen

Het gebruik van 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 van een exemplaar van een functie-app kan comfortabel worden afgehandeld. Hierdoor wordt de app beschermd 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. Hierdoor kan werk efficiënter worden verdeeld over verschillende exemplaren. 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

Dynamische gelijktijdigheid kan worden ingeschakeld op hostniveau 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. Als dynamische gelijktijdigheid is ingeschakeld, begint gelijktijdigheid bij 1 voor elke functie en wordt deze aangepast tot een optimale waarde, die wordt bepaald door de host.

U kunt dynamische gelijktijdigheid inschakelen in uw functie-app door de volgende instellingen toe te voegen in 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, zodat nieuwe exemplaren beginnen met deze waarden in plaats van vanaf 1 te beginnen en het leren opnieuw te moeten uitvoeren.

Gelijktijdigheidsbeheer

Achter de schermen, wanneer dynamische gelijktijdigheid is ingeschakeld, wordt er 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 beperkingen zijn ingeschakeld, wordt de gelijktijdigheid van de functie omlaag aangepast totdat de host weer in orde is. Wanneer beperkingen zijn uitgeschakeld, kan gelijktijdigheid worden verhoogd. 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.

Gelijktijdigheidsniveaus worden beheerd voor elke afzonderlijke functie. Als zodanig wordt het systeem verdeeld tussen resource-intensieve functies waarvoor een laag gelijktijdigheidsniveau en meer lichtgewicht functies nodig zijn die hogere gelijktijdigheid kunnen verwerken. De balans van gelijktijdigheid voor elke functie helpt bij het handhaven van de algehele status van het exemplaar van de functie-app.

Wanneer dynamische gelijktijdigheid is ingeschakeld, ziet u dynamische gelijktijdigheidsbeslissingen in uw logboeken. U ziet bijvoorbeeld logboeken wanneer verschillende beperkingen zijn ingeschakeld en wanneer 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.

Toestel Versie Beschrijving
Queue Storage versie 5.x (Opslagextensie) De Azure Queue Storage-trigger heeft een eigen pollinglus voor berichten. Wanneer u statische configuratie gebruikt, wordt gelijktijdigheid bepaald door de BatchSize/NewBatchThreshold configuratieopties. Wanneer u dynamische gelijktijdigheid gebruikt, worden deze configuratiewaarden genegeerd. Dynamische gelijktijdigheid wordt geïntegreerd in de berichtenlus, dus het aantal berichten dat per iteratie wordt opgehaald, wordt dynamisch aangepast. Wanneer beperkingen zijn ingeschakeld (host is overbelast), wordt de verwerking van berichten onderbroken totdat beperkingen zijn uitgeschakeld. Wanneer beperkingen zijn uitgeschakeld, neemt de gelijktijdigheid toe.
Blob Storage versie 5.x (Opslagextensie) Intern maakt de Azure Blob Storage-trigger gebruik van dezelfde infrastructuur als de Azure Queue Trigger. Wanneer nieuwe/bijgewerkte blobs moeten worden verwerkt, worden berichten naar een door het platform beheerde beheerwachtrij geschreven en die wachtrij wordt verwerkt met dezelfde logica die wordt gebruikt voor QueueTrigger. Wanneer dynamische gelijktijdigheid is ingeschakeld, wordt gelijktijdigheid voor de verwerking van die besturingswachtrij dynamisch beheerd.
Service Bus versie 5.x De Service Bus-trigger ondersteunt momenteel drie uitvoeringsmodellen. Dynamische gelijktijdigheid is als volgt van invloed op deze uitvoeringsmodellen:

• Eén verzendingsonderwerp/wachtrijverwerking: elke aanroep van uw functie verwerkt één bericht. Wanneer u statische configuratie gebruikt, wordt gelijktijdigheid beheerd door de MaxConcurrentCalls configuratieoptie. Wanneer u dynamische gelijktijdigheid gebruikt, wordt die configuratiewaarde genegeerd en wordt gelijktijdigheid dynamisch aangepast.
• Sessiegebaseerde verwerking van één verzendingsonderwerp/wachtrij: elke aanroep van uw functie verwerkt één bericht. Afhankelijk van het aantal actieve sessies voor uw onderwerp/wachtrij, leaset elk exemplaar een of meer sessies. Berichten in elke sessie worden serieel verwerkt om de volgorde in een sessie te garanderen. Wanneer dynamische gelijktijdigheid niet wordt gebruikt, wordt gelijktijdigheid bepaald door de MaxConcurrentSessions instelling. Als dynamische gelijktijdigheid is ingeschakeld, MaxConcurrentSessions wordt genegeerd en wordt het aantal sessies dat elke instantie verwerkt dynamisch aangepast.
• Batchverwerking: elke aanroep van uw functie verwerkt een batch berichten, die onder de MaxMessageCount instelling vallen. Omdat batch-aanroepen serieel zijn, is gelijktijdigheid voor uw door batch geactiveerde functie altijd één en dynamische gelijktijdigheid niet van toepassing.

Volgende stappen

Voor meer informatie raadpleegt u de volgende bronnen: