Výkon a škálování v Durable Functions

Important

Support pro model v procesu skončí 10. listopadu 2026. Důrazně doporučujeme migrovat aplikace do izolovaného modelu pracovních procesů pro plnou podporu.

Tento článek slouží k ladění výkonu a škálování aplikace Durable Functions . Pokrývá hlavní páky, které můžete upravit:

  • Škálování pracovního procesu: Jak hostitel Azure Functions přidává a odebírá pracovní procesy na základě zatížení.
  • Omezení souběžnosti: Jak omezit počet funkcí spuštěných současně na každém pracovníkovi.
  • Mezipaměť instance: Jak omezit náklady na opětovné přehrání díky ukládání stavu orchestrace do mezipaměti v paměti pracovníka.
  • Počet oddílů: Jak nakonfigurovat dělení pro škálování na více uzlů a lokálnost.

Important

Pokud používáte Python nebo PowerShell, přečtěte si úvahy o modulu runtime před konfigurací nastavení souběžnosti. Chybně nakonfigurovaná souběžnost může způsobit zastavení aktivit na jednom pracovníkovi.

Škálování pracovníků

Klíčovou výhodou konceptu centra úloh je, že počet pracovníků, kteří zpracovávají úlohy centra úloh, se může navyšovat a snižovat. Aplikace přidávají pracovníky (horizontální navýšení kapacity) pro rychlejší zpracování a odstraňují pracovníky (horizontální snížení kapacity), když není dostatek práce, aby je zaměstnaly. Pokud je centrum úloh nečinné, můžete dokonce škálovat na nulu . Při škálování na nulu neběží žádné pracovní procesy. Aktivní zůstává pouze kontroler škálování a úložiště.

Následující diagram znázorňuje tento koncept:

Diagram znázorňující škálování pracovních procesů Durable Functions ven, dovnitř a na nulu pro task hub.

Automatické škálování

V plánech Consumption a Elastic Premium Durable Functions podporuje automatické škálování prostřednictvím kontroleru škálování Azure Functions. Kontroler škálování monitoruje, jak dlouho zprávy a úlohy čekají před zpracováním. Na základě těchto latencí přidává nebo odebírá pracovníky.

Note

Počínaje verzí Durable Functions 2.0 můžete nakonfigurovat aplikace funkcí tak, aby běžely v koncových bodech služeb chráněných virtuální sítí v plánu Elastic Premium. V této konfiguraci Durable Functions spustí žádosti o škálování místo kontroleru škálování. Další informace naleznete v tématu Monitorování škálování modulu runtime.

V plánu Premium automatické škálování udržuje počet pracovníků (a provozní náklady) zhruba úměrný zatížení aplikace.

Omezení souběžnosti

Jedna instance pracovního procesu může souběžně spouštět více pracovních položek . Tím se zvyšuje paralelismus a efektivněji se používají pracovní prostředky. Pokud ale pracovní proces zpracuje příliš mnoho pracovních položek najednou, může vyčerpat prostředky, jako jsou procesory, síťová připojení a paměť.

Pokud chcete zabránit přetěžování jednotlivých pracovníků, možná budete muset omezit souběžnost instancí. Omezení počtu funkcí spuštěných současně na každém pracovníkovi pomáhá vyhnout se dosažení jeho limitů na zdroje.

Note

Omezení souběžnosti platí jenom místně a omezují zpracování na pracovníka. Neomevají tedy celkovou propustnost systému.

Tip

V některých případech může omezení souběžného zpracování na pracovníka skutečně zvýšit celkovou propustnost systému. K tomu může dojít, když každý pracovník vykonává méně práce, což způsobí, že škálovací kontroler přidá další pracovníky, aby udržel krok s frontami, což pak zvýší celkovou propustnost.

Konfigurace omezení souběžnosti

Nakonfigurujte omezení souběžnosti aktivit, orchestrátoru a funkce entity v souboruhost.json . Použijte durableTask/maxConcurrentActivityFunctions pro funkce aktivit a durableTask/maxConcurrentOrchestratorFunctions pro orchestrační a entitní funkce. Tato nastavení omezují počet funkcí orchestrátoru, entity a aktivity, které pracovník načte do paměti.

Note

Orchestrace a entity se načítají do paměti pouze při zpracování událostí nebo operací nebo při povolení ukládání do mezipaměti instance . Po spuštění logiky a následném čekání (například await v jazyce C# nebo yield v JavaScriptu a Python) můžou uvolnit paměť. Neaktivní orchestrace a entity se nezapočítávají do maxConcurrentOrchestratorFunctions omezení. I když jsou miliony instancí ve stavu Spuštěno, započítávají se do limitu omezení pouze instance v paměti. Orchestrace, která čeká na dokončení aktivity, se také nezapočítává do omezení výkonu.

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

Úvahy o běhovém prostředí jazyka

Jazykový modul runtime, který vyberete, může u vašich funkcí uplatňovat striktní omezení souběžnosti. Například Durable Functions aplikace napsané v Python nebo PowerShellu můžou na jednom virtuálním počítači spustit jenom jednu funkci najednou. To může způsobit problémy s výkonem, pokud ho nezapočítáte. Pokud orchestrátor podporuje 10 aktivit, ale modul runtime jazyka umožňuje spustit pouze jednu funkci, devět z 10 funkcí aktivity se zablokuje a čeká na spuštění. Tyto čekající aktivity navíc nemohou být rozloženy na jiných pracovnících, protože prostředí runtime Durable Functions je již má načtené v paměti. To je obzvláště problematické, pokud jsou funkce dlouho trvající.

Pokud vaše běhové prostředí jazyka omezuje souběžnost, aktualizujte nastavení souběžnosti Durable Functions tak, aby odpovídalo. Tím se zabrání tomu, aby modul runtime Durable Functions spouštěl více funkcí souběžně, než umožňuje modul runtime jazyka, a umožňuje, aby čekající aktivity byly rozděleny na zátěž do jiných virtuálních počítačů. Pokud například aplikace Python omezuje souběžnost na čtyři funkce (například 4 vlákna v pracovním procesu jednoho jazyka nebo 1 vlákno na 4 jazykové pracovní procesy), nakonfigurujte maxConcurrentOrchestratorFunctions i maxConcurrentActivityFunctions na 4.

Doporučení ke zlepšení výkonu Pythonu najdete v tématu Zlepšení propustnosti aplikací Python v Azure Functions. Tyto techniky mohou výrazně zlepšit výkon a škálovatelnost Durable Functions.

Ukládání do mezipaměti instance

Pracovník zpracovává pracovní položku orchestrace a dělá dvě věci:

  1. Načíst historii orchestrace.
  2. Zopakujte kód orchestrátoru pomocí historie.

Pokud stejný pracovník zpracovává více pracovních položek pro stejnou orchestraci, může poskytovatel úložiště uložit historii do mezipaměti pracovníka, aby se vynechal první krok. Orchestrátor může být během spuštění uložen do mezipaměti, aby se předešlo opakovanému zpracování historie následných položek.

Ukládání do mezipaměti můžete povolit, když vaše orchestrace mají mnoho epizod a dochází k vysoké režii přehrávání. Ukládání do mezipaměti obvykle snižuje vstupně-výstupní operace do základní služby úložiště a zlepšuje propustnost a latenci, ale zvyšuje také využití paměti pracovníka.

Tip

Ukládání do mezipaměti může snížit četnost přehrání historie modulu runtime, ale nemůže eliminovat opakované přehrávání. Během vývoje testujte orchestrátory s deaktivovaným ukládáním do mezipaměti. Vynucené přehrání pomáhá zjišťovat porušení omezení kódu funkce orchestrátoru.

Ukládání do mezipaměti podle poskytovatele úložiště

Následující tabulka porovnává podporu ukládání instancí do mezipaměti mezi poskytovateli a shrnuje, jak nakonfigurovat jednotlivé z nich.

Plánovač úloh Durable poskytovatel Azure Storage Zprostředkovatel úložiště Netherite Poskytovatel úložiště MSSQL
Ukládání do mezipaměti instance Spravováno interně Podporováno
(pouze interní pracovník .NET)		 Podporováno Nepodporováno
Výchozí nastavení není k dispozici Disabled Enabled není k dispozici
Mechanismus Spravováno interně Rozšířené relace Mezipaměť instancí není k dispozici

Note

Plánovač úloh Durable spravuje ukládání do mezipaměti interně. Následující podrobnosti konfigurace platí jenom pro poskytovatele úložiště BYO.

Rozšířené relace (zprostředkovatel Azure Storage)

Prodloužené sezení udržují orchestrátory během provedení v paměti, dokud nejsou nečinní po určitou dobu. Povolte a vylaďte toto chování pomocí extendedSessionsEnabled a extendedSessionIdleTimeoutInSeconds ve vašem souboru host.json:

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

Note

Rozšířené relace jsou podporovány pouze v pracovním procesu .NET. Podrobnosti najdete v Rozšířených relacích v dokumentaci poskytovatele Azure Storage.

Mezipaměť instance (zprostředkovatel úložiště Netherite)

Cache instance uchovává stav instance a historii v paměťi pracovníka a sleduje celkové využití paměť. Pokud mezipaměť překročí InstanceCacheSizeMB limit, vyřadí instance dat, která byla použita nejméně nedávno. Pokud nastavíte CacheOrchestrationCursors na true, mezipaměť ukládá také orchestrátory během spuštění.

Note

Mezipaměti instance fungují se všemi jazykovými sadami SDK, ale možnost CacheOrchestrationCursors je k dispozici pouze pro pracovníka .NET běžícího v procesu. Podrobnosti najdete v části mezipaměti instance v dokumentaci k poskytovateli úložiště Netherite.

Počet oddílů

Někteří poskytovatelé úložiště podporují dělení a umožňují nastavit partitionCount.

Při rozdělení pracovníci nesoutěží o jednotlivé pracovní položky. Dělení pracovních položek partitionCount do oddílů a modul runtime přiřazuje oddíly pracovním procesům. Tento přístup snižuje celkový počet přístupů k úložišti. Umožňuje také ukládání instancí do mezipaměti a zlepšuje lokalitu vytvořením spřažení: stejný pracovník zpracuje všechny pracovní položky pro stejnou instanci.

Note

Plánovač úloh Durable spravuje dělení interně. Následující podrobnosti konfigurace platí jenom pro poskytovatele úložiště BYO.

U většiny aplikací stačí výchozí počet oddílů. Pokud očekáváte, že budete muset škálovat nad rámec výchozího počtu pracovníků pro orchestrace, zvyšte ho, protože počet oddílů omezuje počet pracovníků, kteří mohou zpracovávat orchestrační zprávy z dělené fronty.

Následující tabulka ukazuje, jaké fronty každý zprostředkovatel úložiště rozděluje a jaký je povolený rozsah a výchozí hodnoty pro partitionCount.

Plánovač úloh Durable poskytovatel Azure Storage Zprostředkovatel úložiště Netherite Poskytovatel úložiště MSSQL
Zprávy instance Spravováno interně Rozděleno Rozděleno Není dělené
Zprávy o aktivitách Spravováno interně Není dělené Rozděleno Není dělené
Výchozí partitionCount není k dispozici 4 12 není k dispozici
Maximální partitionCount není k dispozici 16 32 není k dispozici
Dokumentace Viz Trvalý plánovač úloh Viz Orchestrator scale-out. Viz Úvahy o počtu oddílů není k dispozici

Warning

Po vytvoření centra úloh nemůžete počet oddílů změnit. Nastavte ji dostatečně vysokou, aby splňovala očekávané požadavky na škálování pro instanci centra úloh.

Nakonfigurujte počet oddílů

Zadejte partitionCount v souboruhost.json . Následující host.json fragment kódu se nastaví durableTask/storageProvider/partitionCount na 3.

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

Chování při provádění funkce

Tato část popisuje podrobnosti o provádění, které ovlivňují výkon: jaký druh práce by měl každý typ funkce zpracovávat, jak fungují časové limity a jak se operace entit dávkovají.

Umístění práce podle typu funkce

Funkce orchestrátoru spouštějí svoji logiku opakovaně, protože se přehrávají. Proto je důležité, aby vlákna funkcí orchestrace neprováděly úlohy náročné na procesor, neprováděly vstupně-výstupní operace ani neblokovaly. Přesuňte práci, která může vyžadovat vstupně-výstupní operace, blokování nebo více vláken, do funkcí zaměřených na aktivity.

Funkce aktivit se chovají jako běžné funkce spuštěné frontou. Podporují vstupně-výstupní operace, operace náročné na procesor a více vláken. Vzhledem k tomu, že triggery aktivit jsou bezstavové, škálují se na více virtuálních počítačů.

Funkce entit se také spouští na jednom vlákně a zpracovávají operace postupně jednu po druhé. Funkce entit nemají žádná omezení pro typ kódu, který spouští.

Časové limity funkcí

Na aktivity, orchestrátor a funkce entit se vztahují stejné časové limity funkcí jako jiné Azure Functions. Durable Functions zpracovává časový limit funkce jako neošetřenou výjimku v kódu.

Pokud například vyprší časový limit aktivity, Durable Functions zaznamenává spuštění jako neúspěšné a oznámí orchestrátoru. Orchestrátor zpracovává časový limit jako jakoukoli jinou výjimku: modul runtime opakuje, pokud volání určuje opakování, nebo spustí obslužnou rutinu výjimky.

Dávkování operací entit

Aby se zlepšil výkon a snížily náklady, může jedna pracovní položka provádět dávku operací entit. V plánu Consumption se každá dávka účtuje jako jedno spuštění funkce.

Ve výchozím nastavení je maximální velikost dávky 50 v plánu Consumption a 5 000 v jiných plánech. Můžete také nakonfigurovat maximální velikost dávky v souboruhost.json . Pokud je maximální velikost dávky 1, je dávkování účinně zakázáno.

Note

Pokud spuštění jednotlivých operací entit trvá dlouho, může být užitečné omezit velikost maximální dávky, aby se snížilo riziko vypršení časových limitů funkcí, zejména v plánu spotřeby.

Cíle výkonu

Při plánování produkční aplikace s Durable Functions zvažte požadavky na výkon na začátku. Tyto základní scénáře použití vám pomůžou naplánovat:

  • Provádění sekvenčních aktivit: Tento scénář popisuje funkci orchestrátoru, která spouští řadu funkcí aktivity v posloupnosti. Nejvíce připomíná ukázku zřetězení funkcí.
  • Paralelní provádění aktivit: Tento scénář popisuje funkci orchestrátoru, která paralelně spouští mnoho funkcí aktivity pomocí modelu Fan-out a fan-in .
  • Paralelní zpracování odpovědí: Tento scénář představuje druhou polovinu vzoru fan-out, fan-in. Zaměřuje se na výkon ventilátorů. Na rozdíl od "fan-out" běží "fan-in" v jednom instance funkce orchestrátoru, takže běží na jednom virtuálním počítači.
  • Zpracování externích událostí: Tento scénář představuje jednu instanci funkce orchestrátoru, která čeká na externí události po jednom.
  • Zpracování operací entit: Tento scénář testuje, jak rychle může jednaentita čítače zpracovat konstantní datový proud operací.

Čísla propustnosti pro tyto scénáře jsou v dokumentaci poskytovatele úložiště. Zejména jde o toto:

Tip

Na rozdíl od operací typu "fan-out" jsou operace typu "fan-in" omezeny na jeden virtuální počítač. Pokud vaše aplikace používá model fan-out, fan-in a máte obavy o výkon ventilátorů, zvažte rozdělení ventilátoru funkce aktivity mezi několik dílčích orchestrací.

Další kroky

Přehled poskytovatelů úložišť

  • Last updated on