Prestanda och skalning i Durable Functions

Använd den här artikeln om du vill justera prestanda och skalningsbeteende för din Durable Functions-app . Den täcker huvudspakarna som du kan justera:

• Arbetsskalning: Hur Azure Functions-värden lägger till och tar bort arbetare baserat på belastning.
• Samtidighetsbegränsningar: Så här begränsar du antalet funktioner som körs samtidigt på varje arbetare.
• Cachelagring av instanser: Så här minskar du omspelningskostnaderna genom att cachelagra orkestreringstillståndet i arbetsminnet.
• Antal partitioner: Konfigurera partitionering för utskalning och lokalitet.

Skalning av arbetare

En viktig fördel med konceptet med uppgiftshubben är att antalet arbetare som bearbetar arbetsobjekt i aktivitetshubben skalas upp och ned. Program lägger till arbetare (skala ut) för att bearbeta arbete snabbare och ta bort arbetare (skala in) när det inte finns tillräckligt med arbete för att hålla dem upptagna. Du kan till och med skala till noll när aktivitetshubben är inaktiv. När du skalar till noll körs inga arbetare. Endast skalningskontrollanten och lagringen förblir aktiva.

Följande diagram illustrerar det här konceptet:

Automatisk skalning

I förbruknings- och Elastic Premium-abonnemangen stöder Durable Functions automatisk skalning via Azure Functions skalningskontrollant. Skalningskontrollanten övervakar hur länge meddelanden och uppgifter väntar innan bearbetningen. Baserat på dessa svarstider lägger den till eller tar bort arbetare.

I Premium-planen håller automatisk skalning antalet arbetare (och driftskostnader) ungefär proportionella mot programmets belastning.

Samtidighetsbegränsningar

En enskild arbetsinstans kan köra flera arbetsobjekt samtidigt. Detta ökar parallelliteten och använder arbetsresurser mer effektivt. Men om en arbetare bearbetar för många arbetsobjekt samtidigt kan den tömma resurser som CPU, nätverksanslutningar och minne.

Om du vill hindra en enskild medarbetare från att överbelasta kan du behöva begränsa antalet samtidiga instanser. Genom att begränsa antalet funktioner som körs samtidigt på varje arbetare kan du undvika att nå den arbetarens resursgränser.

Konfigurera samtidighetsbegränsningar

Konfigurera aktivitets-, orchestrator- och entitetsfunktionens samtidighetsgränser i host.json-filen . Används durableTask/maxConcurrentActivityFunctions för aktivitetsfunktioner och durableTask/maxConcurrentOrchestratorFunctions för orkestrerings- och entitetsfunktioner. De här inställningarna begränsar hur många orkestrerings-, entitets- och aktivitetsfunktioner som en arbetare läser in i minnet.

{
  "extensions": {
    "durableTask": {
      "maxConcurrentActivityFunctions": 10,
      "maxConcurrentOrchestratorFunctions": 10
    }
  }
}

Språkkörningsmiljööverväganden

Den språkens körmiljö som du väljer kan pålägga strikta samtidighetsbegränsningar för dina funktioner. Till exempel kan Durable Functions appar som skrivits i Python eller PowerShell bara köra en funktion i taget på en enda virtuell dator. Detta kan orsaka prestandaproblem om du inte tar hänsyn till det. Om en orkestrerare sprider ut till 10 aktiviteter men programkörningen tillåter endast en funktion att köras, har nio av de 10 aktivitetsfunktionerna fastnat och väntar på att få köras. Dessutom kan dessa väntande aktiviteter inte hanteras som en del av lastbalansering med andra arbetare eftersom körningen av Durable Functions redan har läst in dem i minnet. Detta är särskilt problematiskt när aktivitetsfunktionerna körs länge.

Om språkkörningen begränsar samtidigheten uppdaterar du Durable Functions samtidighetsinställningar så att de matchar den. Detta gör att Durable Functions-körningen inte kan köra fler funktioner samtidigt än vad språkkörningen tillåter och låter väntande aktiviteter lastbalanseras till andra virtuella datorer. Om en Python-app till exempel begränsar samtidighet till fyra funktioner (till exempel 4 trådar i en arbetsprocess på ett språk eller en tråd på 4 språkprocesser) konfigurerar du både maxConcurrentOrchestratorFunctions och maxConcurrentActivityFunctions till 4.

För rekommendationer för Python-prestanda, se Förbättra genomströmningsprestanda för Python-appar i Azure Functions. Dessa tekniker kan avsevärt förbättra Durable Functions prestanda och skalbarhet.

Cachelagring av instanser

För att bearbeta ett orkestreringsarbetsobjekt gör en arbetare två saker:

1. Hämta orkestreringshistoriken.
2. Spela upp orchestrator-koden igen med hjälp av historiken.

Om samma arbetare bearbetar flera arbetsobjekt för samma orkestrering kan lagringsprovidern cachelagrar historiken i arbetarminnet för att eliminera det första steget. Den kan också cachelagra orkestreringen under pågående utförande för att undvika att återupprepa historiken för kommande arbetsuppgifter.

Aktivera cachelagring när orkestreringarna har många avsnitt och du får höga omkostnader för repriser. Cachelagring minskar vanligtvis I/O till den underliggande lagringstjänsten och förbättrar dataflödet och svarstiden, men det ökar också användningen av arbetsminnet.

Cachelagring av lagringsprovider

I följande tabell jämförs stöd för cachelagring av instanser mellan leverantörer och sammanfattar hur du konfigurerar var och en.

Utökade sessioner (Azure Storage-provider) håller dirigeringsorkestrerare i minnet tills de är inaktiva under en viss tid. Aktivera och justera det här beteendet med extendedSessionsEnabled och extendedSessionIdleTimeoutInSeconds i dinhost.json-fil :

{
  "extensions": {
    "durableTask": {
      "extendedSessionsEnabled": true,
      "extendedSessionIdleTimeoutInSeconds": 30
    }
  }
}

Instanscache (Netherite-lagringsleverantör) behåller instanstillstånd och historik i worker-processens minne och spårar den totala minnesanvändningen. Om cachen överskrider InstanceCacheSizeMB-gränsen, avlägsnas den minst nyligen använda instansdata. Om du anger CacheOrchestrationCursors till true lagrar cachen även orkestratorer för mellankörningar.

Antal partitioner

Vissa lagringsproviders stöder partitionering och låter dig ange partitionCount.

Med partitionering konkurrerar inte arbetare om enskilda arbetsobjekt. Partitionering grupperar arbetsobjekt i partitionCount partitioner och körningen tilldelar partitioner till arbetare. Den här metoden minskar det totala antalet lagringsåtkomster. Det möjliggör även cachelagring av instanser och förbättrar lokaliteten genom att skapa tillhörighet: samma arbetsprocess bearbetar alla arbetsobjekt för samma instans.

För de flesta appar räcker det med standardpartitionsantalet. Öka om du förväntar dig att skala utöver standardantalet arbetare för orkestreringar, eftersom antalet partitioner begränsar antalet arbetare som kan bearbeta orkestreringsmeddelanden från en partitionerad kö.

Följande tabell visar vilka köer varje lagringsleverantör partitionerar och det tillåtna intervallet och standardvärdena för partitionCount.

Konfigurera antalet partitioner

Ange partitionCount i filen host.json. Följande host.json kodfragment anger durableTask/storageProvider/partitionCount till 3.

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "partitionCount": 3
      }
    }
  }
}

Funktionskörningsbeteende

Det här avsnittet beskriver exekveringsdetaljer som påverkar prestanda: vad varje funktionstyp bör hantera, hur timeout-funktioner fungerar och hur entitetsåtgärder batchas.

Arbetsplacering efter funktionstyp

Orchestrator-funktioner kör sin logik flera gånger eftersom de spelas upp igen. Därför är det viktigt att orchestrator-funktionstrådar inte utför processorintensiva uppgifter, utför I/O eller blockerar. Flytta arbete som kan kräva I/O, blockering eller flera trådar till aktivitetsfunktioner.

Aktivitetsfunktioner fungerar som vanliga köutlösta funktioner. De stöder I/O, processorintensiva åtgärder och flera trådar. Eftersom aktivitetsutlösare är tillståndslösa skalas de ut till många virtuella datorer.

Entitetsfunktioner körs också på en enda tråd och bearbetar operationer en i taget. Entitetsfunktioner har inga begränsningar för vilken typ av kod de kör.

Funktionstidsgränser

Aktivitets-, orchestrator- och entitetsfunktioner omfattas av samma funktionstimeouter som andra Azure Functions. Durable Functions behandlar en funktionstimeout som ett ohanterat undantag i koden.

När en aktivitet till exempel överskrider tidsgränsen registrerar Durable Functions körningen som misslyckad och meddelar orkestratorn. Orkestreraren hanterar tidsgränsen som alla andra undantag: körs om ifall anropet anger återförsök, eller så körs en undantagshanterare.

Batchbearbetning för entitetsoperation

För att förbättra prestanda och minska kostnaderna kan ett enskilt arbetsobjekt köra en batch med entitetsåtgärder. I förbrukningsplanen faktureras varje batch som en enda funktionskörning.

Som standard är den maximala batchstorleken 50 i förbrukningsplanen och 5 000 för andra planer. Du kan också konfigurera den maximala batchstorleken i host.json-filen . Om den maximala batchstorleken är 1 inaktiveras batchbearbetningen effektivt.

Prestandamål

När du planerar en produktionsapp med Durable Functions bör du överväga prestandakrav tidigt. Dessa grundläggande användningsscenarier hjälper dig att planera:

• Körning av sekventiell aktivitet: I det här scenariot beskrivs en orkestreringsfunktion som kör en serie aktivitetsfunktioner i sekvens. Den liknar mest exemplet på funktionell kedjning.
• Parallell aktivitetskörning: I det här scenariot beskrivs en orkestreringsfunktion som kör många aktivitetsfunktioner parallellt med mönstret Fan-out, fan-in .
• Parallell svarsbearbetning: Det här scenariot är den andra halvan av fan-out, fan-in-mönstret. Den fokuserar på prestanda för fläktar. Till skillnad från fan-out körs fan-in i en enda orchestrator-funktionsinstans, så den körs på en enda virtuell dator.
• Extern händelsebearbetning: Det här scenariot representerar en enskild orchestrator-funktionsinstans som väntar på externa händelser, en i taget.
• Bearbetning av entitetsåtgärd: I det här scenariot testas hur snabbt en enskildräknarenhet kan bearbeta en konstant åtgärdsström.

Dataflödesnummer för dessa scenarier finns i dokumentationen för lagringsprovidern. Framför allt:

• För Azure Storage-providern, se Performance-mål.
• Information om Netherite-lagringsprovidern finns i Grundläggande scenarier.
• Information om MSSQL-lagringsprovidern finns i Benchmarks för orkestreringens genomströmning.

Nästa steg