Poskytovatel služby Azure Storage (Azure Functions)

Tento dokument popisuje charakteristiky poskytovatele Durable Functions Azure Storage se zaměřením na aspekty výkonu a škálovatelnosti. Zprostředkovatel služby Azure Storage je výchozím poskytovatelem. Ukládá stavy instancí a fronty do účtu Azure Storage (Classic).

Poznámka

Další informace o podporovaných poskytovatelích úložiště pro Durable Functions a jejich porovnání najdete v dokumentaci k poskytovatelům Durable Functions úložiště.

Ve zprostředkovateli Azure Storage je veškeré spouštění funkcí řízeno frontami služby Azure Storage. Stav a historie orchestrace a entity jsou uložené v tabulkách Azure. Objekty blob Azure a zapůjčení objektů blob se používají k distribuci instancí orchestrace a entit napříč několika instancemi aplikací (označované také jako pracovní procesy nebo jednoduše virtuální počítače). V této části najdete podrobnější informace o různých artefaktech Azure Storage a o tom, jak ovlivňují výkon a škálovatelnost.

Reprezentace úložiště

Centrum úloh trvale uchovává všechny stavy instancí a všechny zprávy. Rychlý přehled toho, jak se používají ke sledování průběhu orchestrace, najdete v příkladu provádění centra úloh.

Poskytovatel služby Azure Storage představuje centrum úloh v úložišti pomocí následujících komponent:

  • Dvě tabulky Azure ukládají stavy instancí.
  • Jedna fronta Azure ukládá zprávy o aktivitách.
  • Nejméně jedna fronta Azure ukládá zprávy instance. Každá z těchto tzv. řídicích front představuje oddíl , který je přiřazen podmnožinu všech zpráv instance na základě hodnoty hash ID instance.
  • Několik dalších kontejnerů objektů blob, které se používají pro zapůjčení objektů blob nebo velkých zpráv.

Například centrum úloh s názvem s PartitionCount = 4 následujícími xyz frontami a tabulkami:

Diagram znázorňující organizaci úložiště úložiště poskytovatele služby Azure Storage pro 4 řídicí fronty

Dále popíšeme tyto komponenty a roli, kterou hrají podrobněji.

Tabulka historie

Tabulka Historie je tabulka Azure Storage, která obsahuje události historie pro všechny instance orchestrace v centru úloh. Název této tabulky je ve formuláři TaskHubNameHistory. Při spuštění instancí se do této tabulky přidají nové řádky. Klíč oddílu této tabulky je odvozen od ID instance orchestrace. ID instancí jsou ve výchozím nastavení náhodná a zajišťují optimální distribuci interních oddílů ve službě Azure Storage. Klíč řádku pro tuto tabulku je pořadové číslo použité k řazení událostí historie.

Když je potřeba spustit instanci orchestrace, načtou se odpovídající řádky tabulky Historie do paměti pomocí dotazu rozsahu v rámci jednoho oddílu tabulky. Tyto události historie se pak znovu přehrají do kódu funkce orchestrátoru, aby se vrátily do dříve kontrolního stavu. Použití historie provádění k opětovnému sestavení stavu tímto způsobem je ovlivněno vzorem Event Sourcing.

Tip

Data orchestrace uložená v tabulce Historie zahrnují výstupní datové části z funkcí aktivity a dílčího orchestrátoru. Datové části z externích událostí jsou také uloženy v tabulce Historie. Vzhledem k tomu, že se úplná historie načítá do paměti pokaždé, když orchestrátor potřebuje provést, může mít velký dostatek historie za následek významný tlak na paměť na daný virtuální počítač. Délku a velikost historie orchestrace je možné snížit rozdělením velkých orchestrací na několik dílčích orchestrací nebo zmenšením velikosti výstupů vrácených aktivitou a dílčím orchestrátorem, které volá. Alternativně můžete snížit využití paměti snížením omezení souběžnosti jednotlivých virtuálních počítačů, abyste omezili počet orchestrací, které se načítají do paměti současně.

Tabulka instancí

Tabulka Instances obsahuje stavy všech instancí orchestrace a entit v rámci centra úloh. Při vytváření instancí se do této tabulky přidají nové řádky. Klíč oddílu této tabulky je ID instance orchestrace nebo klíč entity a klíč řádku je prázdný řetězec. Na instanci orchestrace nebo entity existuje jeden řádek.

Tato tabulka slouží k uspokojení požadavků na dotazy instancí z kódu a také volání rozhraní HTTP API stavového dotazu . Uchovává se nakonec v souladu s obsahem tabulky Historie , kterou jsme zmínili dříve. Použití samostatné tabulky Azure Storage k efektivnímu uspokojování operací dotazů instance tímto způsobem ovlivňuje model oddělení odpovědnosti příkazů a dotazů (CQRS).

Tip

Dělení tabulky Instances umožňuje ukládat miliony instancí instancí bez znatelného dopadu na výkon nebo škálování modulu runtime. Počet instancí ale může mít významný dopad na výkon dotazů s více instancemi . Pokud chcete řídit množství dat uložených v těchto tabulkách, zvažte pravidelné vymazání starých dat instance.

Fronty

Funkce orchestratoru, entity a aktivity se aktivují interními frontami v centru úloh aplikace funkcí. Používání front tímto způsobem poskytuje spolehlivé záruky doručení zpráv alespoň jednou. V Durable Functions existují dva typy front: řídicí fronta a fronta pracovních položek.

Fronta pracovních položek

V Durable Functions existuje jedna fronta pracovních položek na centrum úloh. Jedná se o základní frontu a chová se podobně jako jakákoli jiná queueTrigger fronta v Azure Functions. Tato fronta se používá k aktivaci funkcí bezstavové aktivity zrušením vyřazení jedné zprávy najednou. Každá z těchto zpráv obsahuje vstupy funkcí aktivity a další metadata, jako je například funkce, která se má provést. Když se Durable Functions aplikace škáluje na více virtuálních počítačů, všechny tyto virtuální počítače soupeří o získání úkolů z fronty pracovních položek.

Řídicí fronty

V Durable Functions existuje více řídicích front na každé centrum úloh. Řídicí fronta je sofistikovanější než jednodušší fronta pracovních položek. Řídicí fronty se používají k aktivaci stavového orchestrátoru a funkcí entit. Vzhledem k tomu, že instance orchestrátoru a funkce entity jsou stavové singletony, je důležité, aby každá orchestrace nebo entita byla zpracována pouze jedním pracovním procesem najednou. K dosažení tohoto omezení je každá instance orchestrace nebo entita přiřazena k jedné řídicí frontě. Tyto řídicí fronty jsou vyrovnávají zatížení mezi pracovními procesy, aby se zajistilo, že každá fronta bude zpracovávat pouze jeden pracovní proces najednou. Další podrobnosti o tomto chování najdete v dalších částech.

Řídicí fronty obsahují různé typy zpráv o životním cyklu orchestrace. Mezi příklady patří řídicí zprávy orchestrátoru, zprávy odpovědí na funkce aktivity a zprávy časovače. Až 32 zpráv bude vyřazeno z řídicí fronty v jednom hlasování. Tyto zprávy obsahují data datové části a také metadata, včetně toho, pro kterou instanci orchestrace je určena. Pokud je pro stejnou instanci orchestrace určeno více odřazení zpráv, zpracuje se jako dávka.

Zprávy řídicí fronty se neustále dotazují pomocí vlákna na pozadí. Velikost dávky každého dotazování fronty se řídí controlQueueBatchSize nastavením v souboru host.json a má výchozí hodnotu 32 (maximální hodnotu podporovanou frontami Azure). Maximální počet předem načtených zpráv řídicí fronty, které jsou uloženy do vyrovnávací paměti, se řídí controlQueueBufferThreshold nastavením v souboru host.json. Výchozí hodnota se controlQueueBufferThreshold liší v závislosti na různých faktorech, včetně typu plánu hostování. Další informace o těchto nastaveních najdete v dokumentaci ke schématu host.json .

Tip

Zvýšení hodnoty pro controlQueueBufferThreshold povolení rychlejšího zpracování událostí u jedné orchestrace nebo entity Zvýšení této hodnoty ale může také vést k vyššímu využití paměti. Vyšší využití paměti je částečně způsobené načítáním dalších zpráv z fronty a částečně kvůli načítání dalších historie orchestrace do paměti. Snížení hodnoty může controlQueueBufferThreshold být proto účinným způsobem, jak snížit využití paměti.

Dotazování front

Rozšíření trvalých úloh implementuje náhodný exponenciální back-off algoritmus, který snižuje účinek nečinného dotazování fronty na náklady na transakce úložiště. Když se zpráva najde, modul runtime okamžitě zkontroluje jinou zprávu. Pokud nebyla nalezena žádná zpráva, před dalším pokusem počká na určité časové období. Po dalších neúspěšných pokusech o získání zprávy fronty se doba čekání bude dál zvětšovat, dokud nedosáhne maximální doby čekání, což je výchozí hodnota 30 sekund.

Maximální zpoždění dotazování je možné konfigurovat prostřednictvím maxQueuePollingInterval vlastnosti v souboru host.json. Nastavení této vlastnosti na vyšší hodnotu může vést k vyšší latenci zpracování zpráv. Vyšší latence by se očekávala až po období nečinnosti. Nastavení této vlastnosti na nižší hodnotu může vést k vyšším nákladům na úložiště kvůli zvýšeným transakcím úložiště.

Poznámka

Při spuštění v plánech Azure Functions Consumption a Premium se kontroler škálování Azure Functions každých 10 sekund dotazuje na každý ovládací prvek a frontu pracovních položek. Toto další dotazování je nezbytné k určení, kdy aktivovat instance aplikace funkcí a rozhodnout se o škálování. V době psaní tohoto 10sekundového intervalu je konstantní a nelze ho nakonfigurovat.

Zpoždění zahájení orchestrace

Instance orchestrace se spouští tak, že vloží ExecutionStarted zprávu do jedné z řídicích front centra úloh. Za určitých podmínek můžete sledovat vícesekundové zpoždění mezi naplánovaným spuštěním orchestrace a jejím spuštěním. Během tohoto časového intervalu zůstane instance orchestrace ve Pending stavu. Existují dvě možné příčiny tohoto zpoždění:

  • Backlogované řídicí fronty: Pokud řídicí fronta pro tuto instanci obsahuje velký počet zpráv, může trvat dobu, než ExecutionStarted se zpráva přijme a zpracuje modul runtime. K backlogům zpráv může dojít, když orchestrace zpracovávají velké množství událostí současně. Události, které přejdou do fronty řízení, zahrnují události zahájení orchestrace, dokončování aktivit, trvalé časovače, ukončení a externí události. Pokud k tomuto zpoždění dochází za normálních okolností, zvažte vytvoření nového centra úloh s větším počtem oddílů. Konfigurace dalších oddílů způsobí, že modul runtime vytvoří více řídicích front pro distribuci zatížení. Každý oddíl odpovídá 1:1 řídicí frontě s maximálně 16 oddíly.

  • Zpoždění zpětného dotazování: Další běžnou příčinou zpoždění orchestrace je dříve popsané chování zpětného dotazování pro řídicí fronty. Toto zpoždění se ale očekává pouze v případě, že se aplikace škáluje na dvě nebo více instancí. Pokud existuje pouze jedna instance aplikace nebo pokud instance aplikace, která spouští orchestraci, je také stejná instance, která dotazuje frontu ovládacího prvku cíle, nebude zpoždění dotazování fronty. Zpoždění zpětného dotazování je možné snížit aktualizací nastavení host.json , jak je popsáno výše.

Objekty blob

Ve většině případů Durable Functions k zachování dat nepoužívá objekty blob služby Azure Storage. Fronty a tabulky ale mají limity velikosti, které můžou bránit Durable Functions zachovat všechna požadovaná data do řádku úložiště nebo zprávy fronty. Pokud je například část dat, která je potřeba zachovat do fronty, je při serializaci větší než 45 kB, Durable Functions data zkomprimuje a uloží do objektu blob. Při uchovávání dat do úložiště objektů blob tímto způsobem ukládá Durable Function odkaz na tento objekt blob v řádku tabulky nebo ve zprávě fronty. Když Durable Functions potřebuje načíst data, automaticky je načte z objektu blob. Tyto objekty blob se ukládají do kontejneru <taskhub>-largemessagesobjektů blob .

Otázky výkonu

Kroky další komprese a operace objektů blob pro velké zprávy můžou být nákladné z hlediska nákladů na latenci procesoru a vstupně-výstupních operací. Kromě toho Durable Functions potřebuje načíst trvalá data v paměti a může to udělat pro mnoho různých spuštění funkcí současně. V důsledku toho může zachování velkých datových částí způsobit také vysoké využití paměti. Pokud chcete minimalizovat režii paměti, zvažte ruční uchovávání velkých datových částí (například v úložišti objektů blob) a místo toho předejte odkazy na tato data. Tímto způsobem může váš kód načíst data pouze v případě, že je potřeba zabránit redundantnímu zatížení při přehrání funkce orchestrátoru. Ukládání datových částí na místní disky se ale nedoporučuje , protože stav na disku není zaručený, protože funkce se můžou spouštět na různých virtuálních počítačích po celou dobu jejich životnosti.

Výběr účtu úložiště

Fronty, tabulky a objekty blob používané Durable Functions se vytvářejí v nakonfigurovaným účtu služby Azure Storage. Účet, který se má použít, lze zadat pomocí durableTask/storageProvider/connectionStringName nastavení (nebo durableTask/azureStorageConnectionStringName nastavení v Durable Functions 1.x) v souboru host.json.

Durable Functions 2.x

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

Durable Functions 1.x

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

Pokud není zadaný, použije se výchozí AzureWebJobsStorage účet úložiště. Pro úlohy citlivé na výkon se ale doporučuje konfigurace jiného než výchozího účtu úložiště. Durable Functions využívá Azure Storage silně a použití vyhrazeného účtu úložiště izoluje Durable Functions využití úložiště od interního využití hostitelem Azure Functions.

Poznámka

Účty Azure Storage pro obecné účely úrovně Standard se vyžadují při použití poskytovatele služby Azure Storage. Všechny ostatní typy účtů úložiště nejsou podporované. Pro Durable Functions důrazně doporučujeme používat starší účty úložiště pro obecné účely verze 1. Novější účty úložiště v2 můžou být pro úlohy Durable Functions výrazně dražší. Další informace o typech účtů služby Azure Storage najdete v dokumentaci k přehledu účtu úložiště .

Horizontální navýšení kapacity orchestratoru

I když je možné funkce aktivit škálovat neomezeně přidáním dalších virtuálních počítačů elasticky, jednotlivé instance orchestrátoru a entity jsou omezené tak, aby obývaly jeden oddíl a maximální počet oddílů je svázán partitionCount nastavením ve vašem host.json.

Poznámka

Obecně řečeno, funkce orchestrátoru mají být jednoduché a neměly by vyžadovat velké množství výpočetního výkonu. Proto není nutné vytvořit velký počet oddílů řídicí fronty, abyste získali velkou propustnost pro orchestrace. Většina náročných prací by měla být provedena ve funkcích bezstavové aktivity, které je možné škálovat neomezeně.

Počet řídicích front je definován v souboru host.json . Následující příklad fragmentu kódu host.json nastaví durableTask/storageProvider/partitionCount vlastnost (nebo durableTask/partitionCount v Durable Functions 1.x) na 3. Všimněte si, že existuje tolik řídicích front, kolik je oddílů.

Durable Functions 2.x

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

Durable Functions 1.x

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

Centrum úloh je možné nakonfigurovat s 1 až 16 oddíly. Pokud není zadaný, výchozí počet oddílů je 4.

Během scénářů s nízkým provozem se vaše aplikace škáluje na více instancí, takže oddíly budou spravovány malým počtem pracovních procesů. Jako příklad zvažte následující diagram.

Diagram orchestrací škálování

V předchozím diagramu vidíme, že orchestrátory 1 až 6 jsou vyrovnány zatížení napříč oddíly. Podobně jsou oddíly, jako jsou aktivity, vyrovnávají zatížení mezi pracovními procesy. Oddíly jsou vyrovnány zatížení mezi pracovními procesy bez ohledu na počet orchestrátorů, které začínají.

Pokud používáte plány Azure Functions Consumption nebo Elastic Premium nebo pokud máte nakonfigurované automatické škálování založené na zatížení, při nárůstu provozu se při zvýšení provozu a oddíly nakonec přidělí více pracovních procesů napříč všemi pracovními procesy. Pokud budeme pokračovat v horizontálním navýšení kapacity, nakonec bude každý oddíl nakonec spravován jedním pracovním procesem. Aktivity na druhé straně budou nadále vyváženy zatížením napříč všemi pracovními procesy. To je znázorněno na následujícím obrázku.

Diagram orchestrací horizontálního navýšení kapacity

Horní mez maximálního počtu souběžných aktivních orchestrací v daném okamžiku se rovná počtu pracovních procesů přidělených vaší aplikaci krát vaší hodnoty .maxConcurrentOrchestratorFunctions Tuto horní mez je možné přesněji určit, když jsou oddíly plně škálované na více instancí mezi pracovními procesy. Pokud je plně škálovaný a každý pracovní proces bude mít pouze jednu instanci hostitele Functions, maximální počet aktivních souběžných instancí orchestrátoru se bude rovnat vašemu počtu oddílů , než je hodnota pro maxConcurrentOrchestratorFunctions.

Poznámka

V tomto kontextu aktivní znamená, že orchestrace nebo entita se načte do paměti a zpracovává nové události. Pokud orchestrace nebo entita čeká na další události, jako je například návratová hodnota funkce aktivity, dojde k uvolnění z paměti a už se nepovažuje za aktivní. Orchestrace a entity se následně znovu načtou do paměti pouze v případě, že se budou zpracovávat nové události. Neexistuje žádný praktický maximální počet celkových orchestrací nebo entit, které se můžou spouštět na jednom virtuálním počítači, i když jsou všechny ve stavu Spuštěno. Jediným omezením je počet souběžných aktivních instancí orchestrace nebo instancí entit.

Následující obrázek znázorňuje plně škálovaný scénář, ve kterém se přidá více orchestrátorů, ale některé jsou neaktivní, zobrazené šedě.

Druhý diagram orchestrací horizontálního navýšení kapacity

Během horizontálního navýšení kapacity se můžou zapůjčení fronty řízení distribuovat napříč instancemi hostitele Functions, aby se zajistilo rovnoměrné rozdělení oddílů. Tyto zapůjčení se interně implementují jako zapůjčení úložiště objektů blob v Azure a zajišťují, aby všechny jednotlivé instance orchestrace nebo entity běžely jenom na jedné instanci hostitele najednou. Pokud je centrum úloh nakonfigurované se třemi oddíly (a proto třemi řídicími frontami), instance orchestrace a entity mohou být vyrovnána zatížením napříč všemi třemi instancemi hostitelů s blokováním zapůjčení. Další virtuální počítače je možné přidat ke zvýšení kapacity pro provádění funkcí aktivit.

Následující diagram znázorňuje, jak hostitel Azure Functions komunikuje s entitami úložiště ve škálovaném prostředí.

Diagram škálování

Jak je znázorněno v předchozím diagramu, všechny virtuální počítače soutěží o zprávy ve frontě pracovních položek. Zprávy z řídicích front ale můžou získat jenom tři virtuální počítače a každý virtuální počítač uzamkne jednu řídicí frontu.

Instance orchestrace a entity se distribuují napříč všemi instancemi fronty řízení. Distribuce se provádí hashováním ID instance orchestrace nebo názvu entity a páru klíčů. ID instancí orchestrace jsou ve výchozím nastavení náhodné identifikátory GUID, takže instance jsou rovnoměrně distribuovány napříč všemi frontami ovládacích prvků.

Obecně řečeno, funkce orchestrátoru mají být jednoduché a neměly by vyžadovat velké množství výpočetního výkonu. Proto není nutné vytvořit velký počet oddílů front ovládacích prvků, abyste získali velkou propustnost pro orchestrace. Většina náročných prací by měla být provedena ve funkcích bezstavové aktivity, které je možné škálovat neomezeně.

Rozšířené relace

Rozšířené relace jsou mechanismus ukládání do mezipaměti , který uchovává orchestrace a entity v paměti i po dokončení zpracování zpráv. Typickým účinkem povolení rozšířených relací je snížení vstupně-výstupních operací vůči podkladovému odolnému úložišti a celkové vylepšené propustnosti.

Rozšířené relace můžete povolit nastavením durableTask/extendedSessionsEnabledtrue v souboru host.json . Nastavení durableTask/extendedSessionIdleTimeoutInSeconds se dá použít k řízení doby, po jakou dobu se bude nečinná relace uchovávat v paměti:

Funkce 2.0

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

Funkce 1.0

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

Existují dvě potenciální nevýhody tohoto nastavení, o které je potřeba vědět:

  1. Dochází k celkovému zvýšení využití paměti aplikace funkcí, protože nečinné instance se neskládají z paměti tak rychle.
  2. Pokud existuje mnoho souběžných, odlišných, krátkodobých orchestratorů nebo spouštění funkcí entity, může dojít k celkovému snížení propustnosti.

Pokud je například durableTask/extendedSessionIdleTimeoutInSeconds nastavená na 30 sekund, pak krátký orchestrátor nebo epizoda funkce entity, která se spustí za méně než 1 sekundu, stále zabírá paměť po dobu 30 sekund. Počítá se také s kvótou durableTask/maxConcurrentOrchestratorFunctions uvedenou dříve, což potenciálně brání spuštění jiných funkcí orchestrátoru nebo entit.

Konkrétní účinky rozšířených relací na orchestrátor a funkce entit jsou popsány v dalších částech.

Poznámka

Rozšířené relace jsou aktuálně podporovány pouze v jazycích .NET, jako je C# nebo F#. true Nastavení extendedSessionsEnabled pro jiné platformy může vést k problémům s modulem runtime, například bezobslužným selháním spouštění aktivit a funkcí aktivovaných orchestrací.

Přehrání funkce Orchestratoru

Jak už bylo zmíněno dříve, funkce orchestrátoru se přehrají pomocí obsahu tabulky Historie . Ve výchozím nastavení se kód funkce orchestrátoru přehraje při každém vyřazení dávky zpráv z řídicí fronty. I když používáte vzor ventilátoru, ventilátoru a čekáte na dokončení všech úkolů (například v Task.WhenAll() .NET, context.df.Task.all() v JavaScriptu nebo context.task_all() v Pythonu), budou se v průběhu času zpracovávat dávky odpovědí na úkoly. Pokud jsou povolené rozšířené relace, instance funkcí orchestrátoru se uchovávají v paměti déle a nové zprávy je možné zpracovat bez přehrání úplné historie.

Zlepšení výkonu rozšířených relací se nejčastěji vyskytuje v následujících situacích:

  • Pokud je spuštěný omezený počet instancí orchestrace současně.
  • Pokud mají orchestrace velký počet sekvenčních akcí (například stovky volání funkcí aktivit), které se rychle dokončí.
  • Když orchestruje fan-out a fan-in velký počet akcí, které se dokončí přibližně ve stejnou dobu.
  • Když funkce orchestrátoru potřebují zpracovávat velké zprávy nebo provádět zpracování dat náročných na procesor.

Ve všech ostatních situacích obvykle neexistuje pozorovatelné zlepšení výkonu pro funkce orchestrátoru.

Poznámka

Tato nastavení by se měla používat pouze po úplném vývoji a otestovaní funkce orchestrátoru. Výchozí agresivní chování při přehrání může být užitečné pro detekci porušení omezení kódu funkce orchestrátoru v době vývoje, a proto je ve výchozím nastavení zakázaná.

Cíle výkonu

Následující tabulka ukazuje očekávaná maximální počet propustnosti pro scénáře popsané v části Výkonnostní cíle článku Výkon a škálování .

Instance odkazuje na jednu instanci funkce orchestrátoru spuštěné na jednom malém virtuálním počítači (A1) v Azure App Service. Ve všech případech se předpokládá, že jsou povolené rozšířené relace . Skutečné výsledky se můžou lišit v závislosti na výkonu procesoru nebo vstupně-výstupních operací provedených kódem funkce.

Scenario Maximální propustnost
Provádění sekvenční aktivity 5 aktivit za sekundu, na instanci
Paralelní provádění aktivit (fan-out) 100 aktivit za sekundu, na instanci
Paralelní zpracování odpovědí (ventilátor) 150 odpovědí za sekundu, na instanci
Zpracování externích událostí 50 událostí za sekundu, na instanci
Zpracování operací entit 64 operací za sekundu

Pokud se vám nezobrazují očekávaná čísla propustnosti a využití procesoru a paměti, zkontrolujte, jestli příčina souvisí se stavem vašeho účtu úložiště. Rozšíření Durable Functions může výrazně zatížit účet služby Azure Storage a dostatečně vysoké zatížení může vést k omezování účtu úložiště.

Tip

V některých případech můžete výrazně zvýšit propustnost externích událostí, aktivit fan-in a operací entit zvýšením hodnoty controlQueueBufferThreshold nastavení v souboru host.json. Zvýšení této hodnoty nad rámec výchozího nastavení způsobí, že poskytovatel úložiště Durable Task Framework použije více paměti k tomu, aby tyto události načítá agresivněji, což snižuje zpoždění související s vyřazením zpráv z front ovládacích prvků Azure Storage. Další informace najdete v referenční dokumentaci k souboru host.json .

Zpracování s vysokou propustností

Architektura back-endu služby Azure Storage klade určitá omezení maximálního teoretického výkonu a škálovatelnosti Durable Functions. Pokud testování ukazuje, že Durable Functions ve službě Azure Storage nevyhovuje vašim požadavkům na propustnost, měli byste zvážit použití poskytovatele úložiště Netherite pro Durable Functions.

Pokud chcete porovnat dosažitelnou propustnost pro různé základní scénáře, přečtěte si část Základní scénáře dokumentace poskytovatele úložiště Netherite.

Back-end úložiště Netherite byl navržen a vyvinut společností Microsoft Research. Používá Azure Event Hubs a rychlejší databázovou technologii nad objekty blob stránky Azure. Návrh Netherite umožňuje výrazně vyšší propustnost zpracování orchestrací a entit v porovnání s jinými poskytovateli. V některých scénářích srovnávacího testu se propustnost ukázala zvýšit o více než řadu velikostí oproti výchozímu poskytovateli služby Azure Storage.

Další informace o podporovaných poskytovatelích úložiště pro Durable Functions a jejich porovnání najdete v dokumentaci k poskytovatelům úložiště Durable Functions.

Další kroky