Samtidighet i Azure Functions

I Azure Functions gör en enda funktionsappinstans att flera händelser kan bearbetas samtidigt. Eftersom dessa körs på samma beräkningsinstans delar de minnes-, CPU- och anslutningsresurser. I vissa värdplaner gör hög efterfrågan på en specifik instans att funktionvärden automatiskt skapar nya instanser för att hantera den ökade belastningen. I dessa dynamiska skalningsplaner finns det en kompromiss mellan samtidighets- och skalningsbeteenden. För att ge mer kontroll över hur din app körs ger Functions ett sätt att hantera antalet samtidiga körningar.

Functions tillhandahåller två huvudsakliga sätt att hantera samtidighet:

• Fast samtidighet per instans: Du kan konfigurera gränser på värdnivå för samtidighet som är specifika för enskilda utlösare. Den här modellen är standardbeteendet för samtidighet för Functions.
• Dynamisk samtidighet: För vissa utlösartyper kan Functions-värden automatiskt fastställa den bästa nivån av samtidighet för utlösaren i funktionsappen. Du måste välja den här samtidighetsmodellen.

I den här artikeln beskrivs samtidighetsbeteenden för händelsedrivna utlösare i Functions och hur dessa beteenden påverkar skalning i dynamiska planer. Den jämför även modellerna för fast per instans och dynamisk samtidighet.

Skalning kontra samtidighet

För funktioner som använder händelsebaserade utlösare eller svarar på HTTP-begäranden kan du snabbt nå gränserna för samtidiga körningar under perioder med hög efterfrågan. Under sådana perioder måste du kunna skala funktionsappen genom att lägga till instanser för att undvika kvarvarande uppgifter vid bearbetning av inkommande begäranden. Hur vi skalar din app beror på din värdplan:

Innan någon skalning kan inträffa försöker funktionsappen hantera ökad belastning genom att hantera flera anrop av samma typ i en enda instans. Dessa samtidiga körningar på en given instans har direkt inverkan på skalningsbeslut. När en app i en dynamisk skalningsplan till exempel, når en samtidighetsgräns, kan den behöva skalas för att hålla jämna steg med stigande efterfrågan.

Balansen mellan skala och samtidighet som du försöker uppnå i din app beror på var flaskhalsar kan uppstå: vid bearbetning (processorintensiva processbegränsningar) eller i en nedströmstjänst (I/O-baserade begränsningar).

Fastställd samtidighet per instans

Som standard stöder de flesta utlösare en fast konfigurationsmodell för samtidighet per instans via målbaserad skalning. I den här modellen har varje utlösartyp en samtidighetsgräns per instans.

Du kan åsidosätta standardvärdena för samtidighet för de flesta utlösare genom att ange en specifik samtidighet per instans för den utlösartypen. För många utlösare konfigurerar du samtidighetsinställningar i filenhost.json. Azure Service Bus-utlösaren innehåller till exempel både en MaxConcurrentCalls och en MaxConcurrentSessions inställning i host.json. De här inställningarna fungerar tillsammans för att styra det maximala antalet meddelanden som varje funktionsapp bearbetar samtidigt på varje instans.

I vissa målbaserade skalningsscenarier, till exempel när du använder en Apache Kafka- eller Azure Cosmos DB-utlösare, finns samtidighetskonfigurationen i funktionsdeklarationen, inte i host.json-filen . Andra utlösartyper har inbyggda mekanismer för belastningsutjämning av anrop mellan instanser. Azure Event Hubs och Azure Cosmos DB använder till exempel båda ett partitionsbaserat schema.

För utlösartyper som stöder samtidighetskonfiguration tillämpas samtidighetsinställningarna på alla instanser som körs. På så sätt kan du styra den maximala samtidigheten för dina funktioner på varje instans. När din funktion till exempel är CPU-intensiv eller resursintensiv kan du välja att begränsa samtidigheten för att hålla instanserna felfria. I det här fallet kan du förlita dig på skalning för att hantera ökade belastningar. Liknande, när din funktion gör förfrågningar till en nedströmstjänst som är strypt, bör du också överväga att begränsa samtidigheten för att undvika att överbelasta den tjänsten.

SAMTIDIGHET för HTTP-utlösare

Gäller endast för Flex Consumption-planen

SAMTIDIGHET för HTTP-utlösare är en särskild typ av fast samtidighet per instans. När det gäller samtidighet vid HTTP-utlösaren beror standardvärdet för samtidighet också på instansstorleken.

Flex Consumption-planen skalar alla HTTP-utlösarfunktioner tillsammans som en grupp. Mer information finns i Skalning per funktion.

Följande tabell anger standardinställningen för samtidighet för HTTP-utlösare på en viss instans, baserat på den konfigurerade minnesstorleken för instansen:

^*I Python-appar använder alla instansstorlekar en samtidighetsnivå för HTTP-utlösare på en som standard.

Dessa standardvärden bör fungera bra i de flesta fall och du kan börja med dem. Tänk på att vid ett visst antal HTTP-begäranden minskar det antal instanser som krävs för att hantera HTTP-begäranden genom att öka HTTP-samtidighetsvärdet. På samma sätt kräver en minskning av HTTP-samtidighetsvärdet fler instanser för att hantera samma belastning.

Om du behöver finjustera HTTP-samtidigheten kan du göra det med hjälp av Azure CLI. Mer information finns i Ange HTTP-samtidighetsgränser.

Standardvärdena för samtidighet i föregående tabell gäller endast när du inte anger en egen HTTP-samtidighetsinställning. Om du inte explicit anger en HTTP-samtidighetsinställning, ökar den förvalda samtidigheten enligt tabellen när du ändrar instansstorleken. När du har angett ett HTTP-samtidighetsvärde bibehålls det värdet trots ändringar i instansstorleken.

Bestäm optimal samtidighetsnivå per instans

Konfigurationer för samtidighet per instans ger dig kontroll över vissa utlösarbeteenden, till exempel begränsning av dina funktioner. Men det kan vara svårt att fastställa de optimala värdena för de här inställningarna. I allmänhet måste du komma fram till godtagbara värden genom en iterativ process för belastningstestning. Även när du har fastställt en uppsättning värden som fungerar för en viss belastningsprofil kan antalet händelser som kommer från dina anslutna tjänster ändras från dag till dag. Den här variabiliteten kan göra att appen körs med suboptimala värden. Funktionsappen kan till exempel bearbeta krävande meddelandenyttolaster den sista dagen i veckan, vilket kräver att du begränsar samtidigheten. Men under resten av veckan kan meddelandelasten vara lättare, vilket innebär att du kan använda en högre nivå av samtidighet.

Helst bör systemet tillåta instanser att bearbeta så mycket arbete som möjligt samtidigt som varje instans hålls felfri och svarstiderna låga. Dynamisk samtidighet är utformad för detta ändamål.

Dynamisk samtidighet

Functions tillhandahåller en modell för dynamisk samtidighet som förenklar konfigurering av samtidighet för alla funktionsappar som körs i samma plan.

Förmåner

Dynamisk samtidighet ger följande fördelar:

• Förenklad konfiguration: Du behöver inte längre fastställa samtidighetsinställningar per utlösare manuellt. Systemet lär sig de optimala värdena för din arbetsbelastning över tid.
• Dynamiska justeringar: Samtidighet justeras upp eller ned dynamiskt i realtid, vilket gör att systemet kan anpassa sig till ändrade belastningsmönster över tid.
• Hälsoskydd för instanser: Körningen begränsar samtidigheten till nivåer som en funktionsappinstans bekvämt kan hantera. Dessa gränser skyddar appen från att överbelasta sig själv genom att ta på sig mer arbete än den borde.
• Förbättrat dataflöde: Det övergripande dataflödet förbättras eftersom enskilda instanser inte hämtar mer arbete än de snabbt kan bearbeta. Därför lastbalanseras arbetet mer effektivt mellan instanser. För funktioner som kan hantera högre belastningar kan högre dataflöde hämtas genom att öka samtidigheten till värden över standardkonfigurationen.

Konfiguration av dynamisk samtidighet

Du kan aktivera dynamisk samtidighet på värdnivå i host.json-filen . När den är aktiverad justeras samtidighetsnivåerna för alla bindningstillägg som stöder den här funktionen automatiskt efter behov. I dessa fall åsidosätter dynamiska samtidighetsinställningar alla manuellt konfigurerade samtidighetsinställningar.

Som standard inaktiveras dynamisk samtidighet. När du aktiverar dynamisk samtidighet börjar samtidigheten på en nivå av en för varje funktion. Samtidighetsnivån justeras till ett optimalt värde som servervärden bestämmer.

Du kan aktivera dynamisk samtidighet i funktionsappen genom att lägga till följande inställningar i dinhost.json-fil :

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

När snapshotPersistenceEnabled är true, vilket är standardvärdet, sparas de inlärda samtidighetsvärdena regelbundet i lagringen. Nya instanser börjar från dessa värden i stället för att börja från nivå ett och behöver göra om inlärningen.

Samtidighetshanterare

När dynamisk samtidighet aktiveras körs en samtidighetshanterare i bakgrunden. Den här chefen övervakar ständigt hälsomått för instanser, till exempel processor- och trådanvändning, och ändrar begränsningar efter behov. När en eller flera strypningar är aktiverade justeras funktioners samtidighet ned tills värden är i gott skick igen. När throttlar är avstängda kan samtidigheten ökas. Olika heuristiker används för att på ett intelligent sätt justera samtidighet uppåt eller nedåt efter behov baserat på dessa begränsningar. Med tiden stabiliseras samtidigheten för varje funktion till en viss nivå. Eftersom det kan ta tid att fastställa det optimala samtidighetsvärdet använder du endast dynamisk samtidighet om ett suboptimalt värde är acceptabelt för din lösning från början eller efter en period av inaktivitet.

Samtidighetsnivåer hanteras för varje enskild funktion. Mer specifikt balanserar systemet mellan resursintensiva funktioner som kräver en låg samtidighetsnivå och enklare funktioner som kan hantera högre samtidighet. Balansen mellan samtidighet för varje funktion hjälper till att bevara den övergripande hälsan för funktion applikationsinstansen.

När dynamisk samtidighet är aktiverat hittar du dynamiska samtidighetsbeslut i loggarna. Till exempel läggs loggposter till när olika reglage aktiveras, och när parallell bearbetning justeras upp eller ned för varje funktion. Dessa loggar skrivs under loggkategorin Host.Concurrency i spårningstabellen .

Tilläggsstöd

Dynamisk samtidighet är aktiverat för en funktionsapp på värdnivå och eventuella tillägg som stöder dynamisk samtidighet körs i det läget. Dynamisk samtidighet kräver samarbete mellan värden och enskilda utlösartillägg. Endast de angivna versionerna av följande tillägg stöder dynamisk samtidighet.

Nästa steg

Mer information finns i följande resurser:

• Metodtips för tillförlitliga Azure Functions
• Utvecklarguide för Azure Functions
• Azure Functions-utlösare och bindningar