Share via


Gelijktijdigheid in Azure Functions

In dit artikel worden de gelijktijdigheidsgedragen van gebeurtenisgestuurde triggers in Azure Functions beschreven. Ook wordt een nieuw dynamisch model beschreven voor het optimaliseren van gelijktijdigheidsgedrag.

Met het hostingmodel voor Functions kunnen meerdere functieaanroepen gelijktijdig worden uitgevoerd op één rekenproces. Denk bijvoorbeeld aan een geval waarin u drie verschillende functies in uw functie-app hebt, die wordt uitgeschaald en uitgevoerd op meerdere exemplaren. In dit scenario verwerkt elke functie aanroepen op elk VM-exemplaar waarop uw functie-app wordt uitgevoerd. De functieaanroepen op één exemplaar delen dezelfde VM-rekenresources, zoals geheugen, CPU en verbindingen. Wanneer uw app wordt gehost in een dynamisch abonnement (Verbruik of Premium), wordt het aantal functie-app-exemplaren omhoog of omlaag geschaald op basis van het aantal binnenkomende gebeurtenissen. Zie Gebeurtenisgestuurd schalen voor meer informatie. Wanneer u uw functies in een Dedicated (App Service)-plan host, configureert u uw exemplaren handmatig of stelt u een schema voor automatische schaalaanpassing in.

Omdat meerdere functieaanroepen gelijktijdig op elk exemplaar kunnen worden uitgevoerd, moet elke functie een manier hebben om te beperken hoeveel gelijktijdige aanroepen op een bepaald moment worden verwerkt.

Statische gelijktijdigheid

Veel van de triggers ondersteunen een statisch configuratiemodel op hostniveau, dat wordt gebruikt om gelijktijdigheid per exemplaar op te geven 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, is er een standaardgedrag dat u kunt overschrijven in het host.json-bestand voor uw functie-app. Met deze instellingen, die van toepassing zijn op alle actieve exemplaren, kunt u de maximale gelijktijdigheid voor uw functies voor 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. Op dezelfde manier moet u overwegen om gelijktijdigheid te beperken wanneer uw functie aanvragen indient naar een downstreamservice die wordt beperkt.

Hoewel dergelijke 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 via een proef- en foutproces van belastingstests. Zelfs wanneer u een set waarden bepaalt 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 gelijktijdigheid worden verhoogd tot waarden buiten de standaardconfiguratiewaarden, wat een hogere doorvoer oplevert.

Dynamische gelijktijdigheidsconfiguratie

Dynamische gelijktijdigheid kan worden ingeschakeld op hostniveau in het host.json-bestand. Wanneer u bindingsextensies hebt ingeschakeld die worden gebruikt door uw functie-app die dynamische gelijktijdigheid ondersteunen, past u de gelijktijdigheid zo nodig dynamisch aan. Dynamische gelijktijdigheidsinstellingen overschrijven handmatig geconfigureerde gelijktijdigheidsinstellingen voor triggers die dynamische gelijktijdigheid ondersteunen.

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.

Azure-wachtrijen

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.

Als u dynamische gelijktijdigheid voor wachtrijen wilt gebruiken, moet u versie 5.x van de opslagextensie gebruiken.

Azure-blobs

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.

Als u dynamische gelijktijdigheid voor blobs wilt gebruiken, moet u versie 5.x van de opslagextensie gebruiken.

Service Bus

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 u geen dynamische gelijktijdigheid gebruikt, wordt gelijktijdigheid beheerd 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.

Als u wilt dat uw Service Bus-trigger dynamische gelijktijdigheid gebruikt, moet u versie 5.x van de Service Bus-extensie gebruiken.

Volgende stappen

Voor meer informatie raadpleegt u de volgende bronnen: