Samtidighet i Azure Functions
I den här artikeln beskrivs samtidighetsbeteenden för händelsedrivna utlösare i Azure Functions. Den jämför också de statiska och dynamiska samtidighetsmodellerna.
Viktigt!
Flex Consumption-planen är för närvarande i förhandsversion.
I Functions kan du ha flera körningsprocesser för en viss funktion som körs samtidigt på en enda beräkningsinstans. Tänk dig till exempel ett fall där du har tre olika funktioner i funktionsappen som skalas ut till flera instanser för att hantera en ökad belastning. I det här scenariot körs varje funktion som svar på enskilda anrop i alla tre instanserna, och en viss instans kan hantera flera anrop av samma typ. Tänk på att funktionskörningarna på en enda instans delar samma minnes-, CPU- och anslutningsresurser. Eftersom flera funktionskörningar kan köras på varje instans samtidigt måste varje funktion ha ett sätt att hantera antalet samtidiga körningar.
När din app finns i en dynamisk skalningsplan (Förbrukning, Flexförbrukning eller Premium) skalar värden upp eller ned antalet funktionsappinstanser baserat på antalet inkommande händelser. Mer information finns i Händelsedriven skalning. När du är värd för dina funktioner i en dedikerad plan (App Service) måste du manuellt konfigurera dina instanser eller konfigurera ett autoskalningsschema.
Dessa skalningsbeslut påverkas också direkt av samtidigheten av körningar på en viss instans. När en app i en dynamisk skalningsplan når en samtidighetsgräns kan den behöva skalas för att hänga med i den inkommande efterfrågan.
Functions tillhandahåller två huvudsakliga sätt att hantera samtidighet:
Statisk samtidighet: Du kan konfigurera gränser på värdnivå för samtidighet, som är specifika för enskilda utlösare. Det här ä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 samtidigheten för utlösaren i din app. Du måste välja den här samtidighetsmodellen.
Statisk samtidighet
Som standard stöder de flesta utlösare en statisk konfigurationsmodell på värdnivå. I den här modellen har varje utlösartyp en samtidighetsgräns per instans. Men för de flesta utlösare kan du också begära en specifik samtidighet per instans för den utlösartypen. Service Bus-utlösaren innehåller till exempel både en MaxConcurrentCalls och en MaxConcurrentSessions inställning i filen host.json. De här inställningarna styr tillsammans det maximala antalet meddelanden som varje funktion bearbetar samtidigt på varje instans. Andra utlösartyper har inbyggda mekanismer för belastningsutjämning av anrop mellan instanser. 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 de inställningar som du väljer på alla instanser som körs. På så sätt kan du styra maximal samtidighet för dina funktioner på varje instans. När din funktion till exempel är cpu- eller resursintensiv kan du välja att begränsa samtidigheten för att hålla instanserna felfria och förlita sig på skalning för att hantera ökad belastning. När funktionen skickar begäranden till en nedströmstjänst som begränsas bör du också överväga att begränsa samtidigheten för att undvika överbelastning av den underordnade tjänsten.
SAMTIDIGHET för HTTP-utlösare
Gäller endast för Flex Consumption-planen (förhandsversion)
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.
| Instansstorlek (MB) | Standardkonkurrering* |
|---|---|
2048 |
16 |
4096 |
32 |
*För Python-appar är 1http-utlösarens standardkonkurritet för alla instansstorlekar .
Dessa standardvärden bör fungera bra i de flesta fall och du börjar 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ävs det fler instanser för att hantera samma belastning för att minska HTTP-samtidighetsvärdet.
Om du behöver finjustera HTTP-samtidigheten kan du göra detta 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 har angett en egen HTTP-samtidighetsinställning. När du inte uttryckligen har angett en HTTP-samtidighetsinställning ökar standardkonkurrency 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.
Fastställa optimal statisk samtidighet
Även om statiska samtidighetskonfigurationer ger dig kontroll över vissa utlösarbeteenden, till exempel begränsning av dina funktioner, kan det vara svårt att fastställa de optimala värdena för dessa inställningar. 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 innebär att din app ofta kan köras med suboptimala värden. Funktionsappen kan till exempel bearbeta särskilt krävande meddelandenyttolaster den sista dagen i veckan, vilket kräver att du begränsar samtidigheten. Under resten av veckan är dock meddelandets nyttolaster enklare, vilket innebär att du kan använda en högre samtidighetsnivå resten av veckan.
Vi vill helst att systemet ska tillåta instanser att bearbeta så mycket arbete som möjligt samtidigt som varje instans hålls felfri och svarstiderna låga, vilket är vad dynamisk samtidighet är utformat för att göra.
Dynamisk samtidighet
Functions tillhandahåller nu en dynamisk samtidighetsmodell som förenklar konfigurering av samtidighet för alla funktionsappar som körs i samma plan.
Kommentar
Dynamisk samtidighet stöds för närvarande endast för Azure Blob-, Azure Queue- och Service Bus-utlösare och kräver att du använder de versioner som anges i avsnittet om tilläggsstöd nedan.
Förmåner
Med dynamisk samtidighet får du 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. Detta skyddar appen från att överbelasta sig själv genom att ta på sig mer arbete än det 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. På så sätt kan arbetet lastbalanseras 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
Dynamisk samtidighet kan aktiveras på värdnivå i host.json-filen. När det är aktiverat 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. Med dynamisk samtidighet aktiverat börjar samtidigheten vid 1 för varje funktion och justeras upp till ett optimalt värde, vilket bestäms av värden.
Du kan aktivera dynamisk samtidighet i funktionsappen genom att lägga till följande inställningar i filen host.json:
{
"version": "2.0",
"concurrency": {
"dynamicConcurrencyEnabled": true,
"snapshotPersistenceEnabled": true
}
}
När SnapshotPersistenceEnabled är true, vilket är standardvärdet sparas de inlärda samtidighetsvärdena regelbundet till lagring så att nya instanser börjar från dessa värden i stället för att starta från 1 och behöva göra om inlärningen.
Samtidighetshanterare
När dynamisk samtidighet är aktiverad 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 begränsningar är aktiverade justeras funktionens samtidighet ned tills värden är felfri igen. När begränsningar är inaktiverade tillåts samtidigheten att öka. 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å.
Samtidighetsnivåer hanteras för varje enskild funktion. Därför 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 bidrar till att upprätthålla den övergripande hälsan för funktionsappinstansen.
När dynamisk samtidighet är aktiverat visas dynamiska samtidighetsbeslut i loggarna. Du ser till exempel loggar när olika begränsningar är aktiverade och när samtidighet 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.
| Anknytning | Version | beskrivning |
|---|---|---|
| Queue Storage | version 5.x (lagringstillägg) | Azure Queue Storage-utlösaren har en egen meddelandesökningsloop. När du använder statisk konfiguration styrs samtidighet av konfigurationsalternativen BatchSize/NewBatchThreshold . När du använder dynamisk samtidighet ignoreras dessa konfigurationsvärden. Dynamisk samtidighet är integrerad i meddelandeloopen, så antalet meddelanden som hämtas per iteration justeras dynamiskt. När begränsningar är aktiverade (värden är överbelastad) pausas meddelandebearbetningen tills begränsningar inaktiveras. När begränsningar är inaktiverade ökar samtidigheten. |
| Blob Storage | version 5.x (lagringstillägg) | Internt använder Azure Blob Storage-utlösaren samma infrastruktur som Azure Queue Trigger använder. När nya/uppdaterade blobar behöver bearbetas skrivs meddelanden till en plattformshanterad kontrollkö och den kön bearbetas med samma logik som används för QueueTrigger. När dynamisk samtidighet har aktiverats hanteras samtidigheten för bearbetningen av kontrollkön dynamiskt. |
| Service Bus | version 5.x | Service Bus-utlösaren stöder för närvarande tre körningsmodeller. Dynamisk samtidighet påverkar dessa körningsmodeller på följande sätt: • Enskild sändningsämnes-/köbearbetning: Varje anrop av funktionen bearbetar ett enda meddelande. När du använder statisk konfiguration styrs samtidighet av konfigurationsalternativet MaxConcurrentCalls . När du använder dynamisk samtidighet ignoreras det konfigurationsvärdet och samtidigheten justeras dynamiskt.• Sessionsbaserat enskilt sändningsämne/köbearbetning: Varje anrop av funktionen bearbetar ett enda meddelande. Beroende på antalet aktiva sessioner för ditt ämne/din kö hyr varje instans en eller flera sessioner. Meddelanden i varje session bearbetas seriellt för att garantera beställning i en session. När dynamisk samtidighet inte används styrs samtidighet av inställningen MaxConcurrentSessions . Med dynamisk samtidighet aktiverat MaxConcurrentSessions ignoreras och antalet sessioner som varje instans bearbetar justeras dynamiskt.• Batchbearbetning: Varje anrop av din funktion bearbetar en batch med meddelanden, som styrs av MaxMessageCount inställningen. Eftersom batchanrop är seriellt är samtidighet för din batchutlösta funktion alltid en och dynamisk samtidighet gäller inte. |
Nästa steg
Mer information finns i följande resurser: