Azure Storage-provider (Azure Functions)

Det här dokumentet beskriver egenskaperna hos Durable Functions Azure Storage-providern, med fokus på prestanda- och skalbarhetsaspekter. Azure Storage-providern är standardprovidern. Den lagrar instanstillstånd och köer i ett Azure Storage-konto (klassiskt).

Anteckning

Mer information om lagringsproviders som stöds för Durable Functions och hur de jämför finns i dokumentationen om Durable Functions lagringsproviders.

I Azure Storage-providern drivs all funktionskörning av Azure Storage-köer. Orkestrerings- och entitetsstatus och -historik lagras i Azure-tabeller. Azure-blobbar och bloblån används för att distribuera orkestreringsinstanser och entiteter över flera appinstanser (kallas även arbetare eller helt enkelt virtuella datorer). Det här avsnittet innehåller mer information om de olika Azure Storage-artefakterna och hur de påverkar prestanda och skalbarhet.

Lagringsrepresentation

En aktivitetshubb bevarar varaktigt alla instanstillstånd och alla meddelanden. En snabb översikt över hur dessa används för att spåra förloppet för en orkestrering finns i körningsexemplet för aktivitetshubben.

Azure Storage-providern representerar aktivitetshubben i lagringen med hjälp av följande komponenter:

• Mellan två och tre Azure-tabeller. Två tabeller används för att representera historik och instanstillstånd. Om hanteraren för tabellpartition är aktiverad introduceras en tredje tabell för lagring av partitionsinformation.
• En Azure-kö lagrar aktivitetsmeddelandena.
• En eller flera Azure Queues lagrar instansmeddelandena. Var och en av dessa så kallade kontrollköer representerar en partition som tilldelas en delmängd av alla instansmeddelanden, baserat på instans-ID:ts hash.
• Några extra blobcontainrar som används för låneblobar och/eller stora meddelanden.

En aktivitetshubb med namnet xyz med PartitionCount = 4 innehåller till exempel följande köer och tabeller:

Härnäst beskriver vi dessa komponenter och den roll de spelar i detalj.

Historiktabell

Tabellen Historik är en Azure Storage-tabell som innehåller historikhändelser för alla orkestreringsinstanser i en aktivitetshubb. Namnet på den här tabellen är i formatet TaskHubName-historik. När instanser körs läggs nya rader till i den här tabellen. Partitionsnyckeln för den här tabellen härleds från instans-ID:t för orkestreringen. Instans-ID:t är slumpmässiga som standard, vilket säkerställer optimal distribution av interna partitioner i Azure Storage. Radnyckeln för den här tabellen är ett sekvensnummer som används för att sortera historikhändelserna.

När en orkestreringsinstans behöver köras läses motsvarande rader i tabellen Historik in i minnet med hjälp av en intervallfråga i en enda tabellpartition. Dessa historikhändelser spelas sedan upp igen i orchestrator-funktionskoden för att få tillbaka den till dess tidigare kontrollpunktstillstånd. Användningen av körningshistorik för att återskapa tillstånd på det här sättet påverkas av mönstret Händelsekällor.

Tips

Orkestreringsdata som lagras i tabellen Historik innehåller utdatanyttolaster från aktivitets- och underorkestreringsfunktioner. Nyttolaster från externa händelser lagras också i tabellen Historik. Eftersom den fullständiga historiken läses in i minnet varje gång en orkestrerare behöver köras kan en tillräckligt stor historik leda till betydande minnesbelastning på en viss virtuell dator. Orkestreringshistorikens längd och storlek kan minskas genom att dela upp stora orkestreringar i flera underorkestreringar eller genom att minska storleken på utdata som returneras av de aktivitets- och underorkestreringsfunktioner som anropas. Du kan också minska minnesanvändningen genom att sänka samtidighetsbegränsningen per virtuell dator för att begränsa hur många orkestreringar som läses in i minnet samtidigt.

Instanstabell

Tabellen Instances innehåller status för alla orkestrerings- och entitetsinstanser i en aktivitetshubb. När instanser skapas läggs nya rader till i den här tabellen. Partitionsnyckeln för den här tabellen är orkestreringsinstansens ID eller entitetsnyckel och radnyckeln är en tom sträng. Det finns en rad per orkestrering eller entitetsinstans.

Den här tabellen används för att uppfylla instansfrågebegäranden från kod samt HTTP API-anrop för statusfråga . Den hålls så småningom konsekvent med innehållet i tabellen Historik som nämnts tidigare. Användningen av en separat Azure Storage-tabell för att effektivt uppfylla frågeåtgärder för instanser på det här sättet påverkas av CQRS-mönstret (Command and Query Responsibility Segregation).

Tips

Partitioneringen av tabellen Instanser gör att den kan lagra miljontals orkestreringsinstanser utan någon märkbar inverkan på körningsprestanda eller skala. Antalet instanser kan dock ha en betydande inverkan på frågeprestanda för flera instanser . Överväg att regelbundet rensa gamla instansdata för att kontrollera mängden data som lagras i dessa tabeller.

Partitionstabell

Anteckning

Den här tabellen visas bara i aktivitetshubben när Table Partition Manager är aktiverad. Om du vill tillämpa det konfigurerar useTablePartitionManagement du inställningen i appens host.json.

Tabellen Partitioner lagrar status för partitioner för Durable Functions-appen och används för att distribuera partitioner mellan apparbetarna. Det finns en rad per partition.

Köer

Orchestrator-, entitets- och aktivitetsfunktioner utlöses av interna köer i funktionsappens aktivitetshubb. Att använda köer på det här sättet ger tillförlitliga garantier för meddelandeleverans "minst en gång". Det finns två typer av köer i Durable Functions: kontrollkön och arbetsobjektskö.

Arbetsobjektskö

Det finns en arbetsobjektskö per aktivitetshubb i Durable Functions. Det är en grundläggande kö och fungerar på samma sätt som andra queueTrigger köer i Azure Functions. Den här kön används för att utlösa tillståndslösa aktivitetsfunktioner genom att ett meddelande i taget tas bort från kön. Vart och ett av dessa meddelanden innehåller aktivitetsfunktionens indata och ytterligare metadata, till exempel vilken funktion som ska köras. När ett Durable Functions program skalar ut till flera virtuella datorer konkurrerar alla dessa virtuella datorer med att hämta uppgifter från arbetsobjektskön.

Kontrollköer

Det finns flera kontrollköer per aktivitetshubb i Durable Functions. En kontrollkö är mer avancerad än den enklare arbetsobjektskö. Kontrollköer används för att utlösa tillståndskänsliga orkestrerings- och entitetsfunktioner. Eftersom orkestrerings- och entitetsfunktionsinstanserna är tillståndskänsliga singletons är det viktigt att varje orkestrering eller entitet endast bearbetas av en arbetare i taget. För att uppnå den här begränsningen tilldelas varje orkestreringsinstans eller entitet till en enda kontrollkö. Dessa kontrollköer belastningsutjäxlas mellan arbetare för att säkerställa att varje kö endast bearbetas av en arbetare i taget. Mer information om det här beteendet finns i efterföljande avsnitt.

Kontrollköer innehåller en mängd olika typer av orkestreringslivscykelmeddelanden. Exempel är orchestrator-kontrollmeddelanden, aktivitetsfunktionssvarsmeddelanden och timermeddelanden. Så många som 32 meddelanden kommer att tas bort från en kontrollkö i en enda omröstning. Dessa meddelanden innehåller nyttolastdata samt metadata, inklusive vilken orkestreringsinstans den är avsedd för. Om flera dequeued-meddelanden är avsedda för samma orkestreringsinstans bearbetas de som en batch.

Kontrollkömeddelanden avsöks ständigt med hjälp av en bakgrundstråd. Batchstorleken för varje köundersökning styrs av controlQueueBatchSize inställningen i host.json och har som standard 32 (det högsta värde som stöds av Azure Queues). Det maximala antalet förinställda kontrollkömeddelanden som buffrats i minnet styrs av controlQueueBufferThreshold inställningen i host.json. Standardvärdet för controlQueueBufferThreshold varierar beroende på en mängd olika faktorer, inklusive typen av värdplan. Mer information om de här inställningarna finns i schemadokumentationen för host.json .

Tips

Genom att öka värdet för controlQueueBufferThreshold kan en enda orkestrering eller entitet bearbeta händelser snabbare. Men om du ökar det här värdet kan det också leda till högre minnesanvändning. Den högre minnesanvändningen beror delvis på att fler meddelanden hämtas från kön och delvis på att mer orkestreringshistorik hämtas till minnet. Att minska värdet för controlQueueBufferThreshold kan därför vara ett effektivt sätt att minska minnesanvändningen.

Kösökning

Tillägget för varaktiga uppgifter implementerar en slumpmässig exponentiell backoff-algoritm för att minska effekten av avsökning i inaktivitetskö på lagringstransaktionskostnader. När ett meddelande hittas söker körningen omedelbart efter ett annat meddelande. När inget meddelande hittas väntar det en stund innan det försöker igen. Efter efterföljande misslyckade försök att få ett kömeddelande fortsätter väntetiden att öka tills den når den maximala väntetiden, som standard är 30 sekunder.

Den maximala avsökningsfördröjningen maxQueuePollingInterval kan konfigureras via egenskapen i filen host.json. Om du ställer in den här egenskapen på ett högre värde kan det leda till längre svarstider för meddelandebearbetning. Högre svarstider förväntas först efter perioder av inaktivitet. Om du ställer in den här egenskapen på ett lägre värde kan det leda till högre lagringskostnader på grund av ökade lagringstransaktioner.

Anteckning

När du kör i Azure Functions Consumption och Premium-abonnemangen avsöks varje kontroll- och arbetsobjektskö av Azure Functions Scale Controller en gång var tionde sekund. Den här ytterligare avsökningen är nödvändig för att avgöra när funktionsappinstanser ska aktiveras och fatta skalningsbeslut. I skrivande stund är det här intervallet på 10 sekunder konstant och kan inte konfigureras.

Orkestreringsstartfördröjningar

Orkestreringsinstanser startas genom att ett ExecutionStarted meddelande placeras i en av aktivitetshubbens kontrollköer. Under vissa förhållanden kan du observera fördröjningar i flera sekunder mellan när en orkestrering är schemalagd att köras och när den faktiskt börjar köras. Under det här tidsintervallet förblir orkestreringsinstansen Pending i tillståndet . Det finns två möjliga orsaker till den här fördröjningen:

• Eftersläppta kontrollköer: Om kontrollkön för den här instansen innehåller ett stort antal meddelanden kan det ta tid innan ExecutionStarted meddelandet tas emot och bearbetas av körningen. Kvarvarande meddelandeloggar kan inträffa när orkestreringar bearbetar många händelser samtidigt. Händelser som hamnar i kontrollkön omfattar orkestreringsstarthändelser, aktivitetsslutpunkter, varaktiga timers, avslutning och externa händelser. Om den här fördröjningen inträffar under normala omständigheter bör du överväga att skapa en ny aktivitetshubb med ett större antal partitioner. Om du konfigurerar fler partitioner skapas fler kontrollköer för belastningsfördelning i körningen. Varje partition motsvarar 1:1 med en kontrollkö, med högst 16 partitioner.

• Säkerhetskopiera avsökningsfördröjningar: En annan vanlig orsak till orkestreringsfördröjningar är det tidigare beskrivna avsökningsbeteendet för kontrollköer. Den här fördröjningen förväntas dock bara när en app skalas ut till två eller flera instanser. Om det bara finns en appinstans eller om appinstansen som startar orkestreringen också är samma instans som avsöker målkontrollkön, kommer det inte att uppstå någon kösökningsfördröjning. Fördröjningar i avsökningen kan minskas genom att uppdatera host.json-inställningarna enligt beskrivningen ovan.

Blobar

I de flesta fall använder Durable Functions inte Azure Storage-blobar för att bevara data. Köer och tabeller har dock storleksgränser som kan hindra Durable Functions från att spara alla nödvändiga data i en lagringsrad eller ett kömeddelande. När en datamängd som behöver sparas i en kö är större än 45 kB när den serialiseras komprimerar Durable Functions data och lagrar dem i en blob i stället. När du sparar data till Blob Storage på det här sättet lagrar Durable Function en referens till blobben i tabellraden eller kömeddelandet. När Durable Functions behöver hämta data hämtas de automatiskt från bloben. Dessa blobar lagras i blobcontainern <taskhub>-largemessages.

Saker att tänka på gällande prestanda

De extra komprimerings- och blobåtgärdsstegen för stora meddelanden kan vara dyra när det gäller kostnader för CPU- och I/O-svarstid. Dessutom måste Durable Functions läsa in beständiga data i minnet och kan göra det för många olika funktionskörningar samtidigt. Därför kan bestående stora datanyttolaster orsaka hög minnesanvändning också. För att minimera minneskostnaderna bör du överväga att spara stora datanyttolaster manuellt (till exempel i Blob Storage) och i stället skicka runt referenser till dessa data. På så sätt kan koden bara läsa in data när det behövs för att undvika redundanta inläsningar under repetitioner av orchestrator-funktionen. Det rekommenderas dock inte att lagra nyttolaster på lokala diskar eftersom det inte är säkert att det är tillgängligt på disken eftersom funktioner kan köras på olika virtuella datorer under hela livslängden.

Val av lagringskonto

Köer, tabeller och blobar som används av Durable Functions skapas i ett konfigurerat Azure Storage-konto. Kontot som ska användas kan anges med hjälp av durableTask/storageProvider/connectionStringName inställningen (eller durableTask/azureStorageConnectionStringName inställningen i Durable Functions 1.x) i filen host.json.

Durable Functions 2.x

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "connectionStringName": "MyStorageAccountAppSetting"
      }
    }
  }
}

Durable Functions 1.x

{
  "extensions": {
    "durableTask": {
      "azureStorageConnectionStringName": "MyStorageAccountAppSetting"
    }
  }
}

Om inget anges används standardlagringskontot AzureWebJobsStorage . För prestandakänsliga arbetsbelastningar rekommenderar vi dock att du konfigurerar ett lagringskonto som inte är standard. Durable Functions använder Azure Storage kraftigt och med hjälp av ett dedikerat lagringskonto isoleras Durable Functions lagringsanvändning från den interna användningen av Azure Functions-värden.

Anteckning

Azure Storage-standardkonton för generell användning krävs när du använder Azure Storage-providern. Alla andra typer av lagringskonton stöds inte. Vi rekommenderar starkt att du använder äldre v1-lagringskonton för generell användning för Durable Functions. De nyare v2-lagringskontona kan vara betydligt dyrare för Durable Functions arbetsbelastningar. Mer information om typer av Azure Storage-konton finns i översiktsdokumentationen för Lagringskonto .

Orchestrator-utskalning

Även om aktivitetsfunktioner kan skalas ut oändligt genom att lägga till fler virtuella datorer elastiskt, begränsas enskilda orchestrator-instanser och entiteter så att de bor i en enda partition och det maximala antalet partitioner begränsas av partitionCount inställningen i din host.json.

Anteckning

I allmänhet är orkestreringsfunktioner avsedda att vara lätta och bör inte kräva stora mängder datorkraft. Det är därför inte nödvändigt att skapa ett stort antal kontrollköpartitioner för att få bra dataflöde för orkestreringar. Det mesta av det tunga arbetet bör utföras i tillståndslösa aktivitetsfunktioner, som kan skalas ut oändligt.

Antalet kontrollköer definieras i filen host.json . I följande exempel anger host.json-kodfragmentet durableTask/storageProvider/partitionCount egenskapen (eller durableTask/partitionCount i Durable Functions 1.x) till 3. Observera att det finns lika många kontrollköer som det finns partitioner.

Durable Functions 2.x

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

Durable Functions 1.x

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

En aktivitetshubb kan konfigureras med mellan 1 och 16 partitioner. Om inget anges är standardantalet för partitioner 4.

I scenarier med låg trafik skalas programmet in, så partitioner hanteras av ett litet antal arbetare. Tänk dig till exempel diagrammet nedan.

I föregående diagram ser vi att orchestrators 1 till 6 lastbalanseras mellan partitioner. På samma sätt lastbalanseras partitioner, till exempel aktiviteter, mellan arbetare. Partitioner belastningsutjämning mellan arbetare oavsett hur många orkestrerare som kommer igång.

Om du kör abonnemangen Azure Functions Consumption eller Elastic Premium, eller om du har konfigurerat belastningsbaserad automatisk skalning, allokeras fler arbetare när trafiken ökar och partitionerna kommer så småningom att belastningsutjämning för alla arbetare. Om vi fortsätter att skala ut kommer varje partition så småningom att hanteras av en enda arbetsroll. Å andra sidan fortsätter aktiviteterna att belastningsutjäxas för alla arbetstagare. Detta visas i bilden nedan.

Den övre gränsen för det maximala antalet samtidiga aktiva orkestreringar vid en given tidpunkt är lika med antalet arbetare som allokerats till programmet gånger värdet för maxConcurrentOrchestratorFunctions. Den här övre gränsen kan göras mer exakt när partitionerna skalas ut fullständigt mellan arbetare. När den är helt utskalad, och eftersom varje arbetare bara har en enda Functions-värdinstans, är det maximala antalet aktiva samtidiga orchestrator-instanser lika med antalet partitioner gånger värdet för maxConcurrentOrchestratorFunctions.

Anteckning

I det här sammanhanget innebär aktiv att en orkestrering eller entitet läses in i minnet och bearbetar nya händelser. Om orkestreringen eller entiteten väntar på fler händelser, till exempel returvärdet för en aktivitetsfunktion, tas den bort från minnet och anses inte längre vara aktiv. Orkestreringar och entiteter läses därefter bara in i minnet igen när det finns nya händelser att bearbeta. Det finns inget praktiskt maximalt antal totala orkestreringar eller entiteter som kan köras på en enda virtuell dator, även om alla är i tillståndet "Körs". Den enda begränsningen är antalet samtidiga aktiva orkestrerings- eller entitetsinstanser.

Bilden nedan illustrerar ett fullständigt utskalat scenario där fler orkestrerare läggs till men vissa är inaktiva, vilket visas i grått.

Vid utskalning kan kontrollkölån distribueras om mellan Functions-värdinstanser för att säkerställa att partitionerna distribueras jämnt. Dessa lån implementeras internt som Azure Blob Storage-lån och ser till att alla enskilda orkestreringsinstanser eller entiteter endast körs på en enda värdinstans åt gången. Om en aktivitetshubb har konfigurerats med tre partitioner (och därför tre kontrollköer) kan orkestreringsinstanser och entiteter belastningsutjäxas över alla tre värdinstanser med lån. Ytterligare virtuella datorer kan läggas till för att öka kapaciteten för aktivitetsfunktionskörning.

Följande diagram illustrerar hur den Azure Functions värden interagerar med lagringsentiteterna i en utskalad miljö.

Som du ser i föregående diagram konkurrerar alla virtuella datorer om meddelanden i arbetsobjektskö. Men endast tre virtuella datorer kan hämta meddelanden från kontrollköer och varje virtuell dator låser en enda kontrollkö.

Orkestreringsinstanser och entiteter distribueras över alla kontrollköinstanser. Distributionen görs genom att hasha instans-ID:t för orkestreringen eller entitetsnamnet och nyckelparet. Orkestreringsinstans-ID:t är som standard slumpmässiga GUID,vilket säkerställer att instanserna är jämnt fördelade över alla kontrollköer.

I allmänhet är orkestreringsfunktioner avsedda att vara lätta och bör inte kräva stora mängder datorkraft. Det är därför inte nödvändigt att skapa ett stort antal kontrollköpartitioner för att få bra dataflöde för orkestreringar. Det mesta av det tunga arbetet bör utföras i tillståndslösa aktivitetsfunktioner, som kan skalas ut oändligt.

Utökade sessioner

Utökade sessioner är en cachelagringsmekanism som håller orkestreringar och entiteter i minnet även när de har bearbetat meddelanden. Den typiska effekten av att aktivera utökade sessioner minskar I/O mot det underliggande varaktiga lagret och det övergripande förbättrade dataflödet.

Du kan aktivera utökade sessioner genom att ange durableTask/extendedSessionsEnabled till true i filen host.json . Inställningen durableTask/extendedSessionIdleTimeoutInSeconds kan användas för att styra hur länge en inaktiv session ska lagras i minnet:

Functions 2.0

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

Functions 1.0

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

Det finns två möjliga nackdelar med den här inställningen att vara medveten om:

1. Minnesanvändningen för funktionsappen ökar totalt sett eftersom inaktiva instanser inte tas bort från minnet lika snabbt.
2. Det kan finnas en total minskning av dataflödet om det finns många samtidiga, distinkta, kortlivade orkestrerings- eller entitetsfunktionskörningar.

durableTask/extendedSessionIdleTimeoutInSeconds Om är inställt på 30 sekunder upptar ett kortlivad orkestrerings- eller entitetsfunktionsavsnitt som körs på mindre än 1 sekund fortfarande minne i 30 sekunder. Den räknas också mot den durableTask/maxConcurrentOrchestratorFunctions kvot som nämnts tidigare, vilket potentiellt hindrar andra orkestrerings- eller entitetsfunktioner från att köras.

De specifika effekterna av utökade sessioner på orchestrator- och entitetsfunktioner beskrivs i nästa avsnitt.

Anteckning

Utökade sessioner stöds för närvarande endast på .NET-språk, till exempel C# eller F#. Inställningen extendedSessionsEnabled till true för andra plattformar kan leda till körningsproblem, till exempel att det inte går att köra aktivitet och orkestreringsutlösta funktioner.

Orchestrator-funktionsrepris

Som tidigare nämnts spelas orchestrator-funktioner upp med hjälp av innehållet i tabellen Historik . Som standard spelas orchestrator-funktionskoden upp varje gång en batch meddelanden tas bort från en kontrollkö. Även om du använder mönstret fan-out, fan-in och väntar på att alla uppgifter ska slutföras (till exempel i Task.WhenAll() .NET, context.df.Task.all() i JavaScript eller context.task_all() i Python), kommer det att finnas repriser som inträffar när batchar med uppgiftssvar bearbetas över tid. När utökade sessioner är aktiverade lagras orchestrator-funktionsinstanser längre i minnet och nya meddelanden kan bearbetas utan en fullständig historikrepris.

Prestandaförbättringen för utökade sessioner observeras oftast i följande situationer:

• När det finns ett begränsat antal orkestreringsinstanser som körs samtidigt.
• När orkestreringar har ett stort antal sekventiella åtgärder (till exempel hundratals aktivitetsfunktionsanrop) som slutförs snabbt.
• När orkestrering fan-out och fan-in ett stort antal åtgärder som slutförs ungefär samtidigt.
• När orchestrator-funktioner behöver bearbeta stora meddelanden eller utföra processorintensiv databearbetning.

I alla andra situationer finns det vanligtvis ingen observerbar prestandaförbättring för orchestrator-funktioner.

Anteckning

De här inställningarna bör endast användas när en orchestrator-funktion har utvecklats och testats fullt ut. Standardbeteendet för aggressiv uppspelning kan vara användbart för att identifiera överträdelser av orchestrator-funktionskodbegränsningar vid utvecklingstid och inaktiveras därför som standard.

Prestandamål

I följande tabell visas de förväntade maximala dataflödesnumren för de scenarier som beskrivs i avsnittet Prestandamål i artikeln Prestanda och skala .

"Instans" refererar till en enda instans av en orchestrator-funktion som körs på en enda liten (A1) virtuell dator i Azure App Service. I samtliga fall förutsätts det att utökade sessioner är aktiverade. Faktiska resultat kan variera beroende på processor- eller I/O-arbete som utförs av funktionskoden.

Scenario	Maximalt dataflöde
Körning av sekventiell aktivitet	5 aktiviteter per sekund, per instans
Parallell aktivitetskörning (utfasning)	100 aktiviteter per sekund, per instans
Parallell svarsbearbetning (inbyggt)	150 svar per sekund, per instans
Extern händelsebearbetning	50 händelser per sekund, per instans
Bearbetning av entitetsåtgärder	64 åtgärder per sekund

Om du inte ser de dataflödesnummer du förväntar dig och processor- och minnesanvändningen verkar felfri kontrollerar du om orsaken är relaterad till hälsotillståndet för ditt lagringskonto. Det Durable Functions tillägget kan lägga stor belastning på ett Azure Storage-konto och tillräckligt hög belastning kan leda till begränsning av lagringskontot.

Tips

I vissa fall kan du avsevärt öka dataflödet för externa händelser, inaktiv aktivitet och entitetsåtgärder genom att öka värdet för controlQueueBufferThreshold inställningen i host.json. Om du ökar det här värdet utöver standardvärdet används mer minne från Durable Task Framework-lagringsprovidern för att förinstallera dessa händelser mer aggressivt, vilket minskar fördröjningar som är associerade med att ta bort meddelanden från Azure Storage-kontrollköerna. Mer information finns i referensdokumentationen för host.json .

Bearbetning med högt dataflöde

Arkitekturen för Azure Storage-serverdelen begränsar den maximala teoretiska prestandan och skalbarheten för Durable Functions. Om dina tester visar att Durable Functions i Azure Storage inte uppfyller dina dataflödeskrav bör du i stället överväga att använda Netherite-lagringsprovidern för Durable Functions.

Om du vill jämföra det uppnåeliga dataflödet för olika grundläggande scenarier kan du läsa avsnittet Grundläggande scenarier i dokumentationen om netheritelagringsprovider.

Netherite Storage-serverdelen har utformats och utvecklats av Microsoft Research. Den använder Azure Event Hubs och FASTER-databastekniken ovanpå Azure Page Blobs. Netherite-designen möjliggör betydligt högre dataflödesbearbetning av orkestreringar och entiteter jämfört med andra leverantörer. I vissa benchmark-scenarier visade sig dataflödet öka med mer än en storleksordning jämfört med standardprovidern för Azure Storage.

Mer information om vilka lagringsprovidrar som stöds för Durable Functions och hur de jämförs finns i dokumentationen om Durable Functions lagringsproviders.

Nästa steg

Lär dig mer om haveriberedskap och geodistribution