Poskytovatel služby Azure Storage (Azure Functions)
Tento dokument popisuje charakteristiky poskytovatele služby Durable Functions Azure Storage se zaměřením na aspekty výkonu a škálovatelnosti. Zprostředkovatel 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 úložiště Durable Functions.
Ve zprostředkovateli služby Azure Storage je veškeré spouštění funkcí řízené frontami azure Storage. Stav a historie orchestrace a entity se ukládají 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). Tato část obsahuje 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 udržuje 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:
- Mezi dvěma a třemi tabulkami Azure Dvě tabulky se používají k reprezentaci historie a stavů instancí. Pokud je správce oddílů tabulky povolený, zavádějí se třetí tabulka pro ukládání informací o oddílech.
- Jedna fronta Azure ukládá zprávy o aktivitách.
- Jedna nebo více front Azure ukládá zprávy instance. Každá z těchto takzvaných ří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 objekty blob zapůjčení nebo velké zprávy.
Centrum úloh pojmenované xyz PartitionCount = 4 například obsahuje následující fronty a tabulky:
Dále tyto komponenty a roli, kterou hrají, podrobněji popíšeme.
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 formátu Historie názvu TaskHubName. 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, které se používá 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 přehrají do kódu funkce orchestrátoru, aby se vrátily do předchozího stavu kontrolního bodu. Použití historie provádění k opětovnému sestavení stavu tímto způsobem je ovlivněno modelem 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í se také ukládají v tabulce Historie. Vzhledem k tomu, že se úplná historie načte do paměti při každém spuštění orchestrátoru, může mít velký dostatek historie za následek velký tlak na paměť daného virtuálního počítače. Délku a velikost historie orchestrace je možné snížit rozdělením velkých orchestrací do několika dílčích orchestrací nebo zmenšením velikosti výstupů vrácených aktivitou a dílčími funkcemi orchestrátoru, které volá. Případně 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 pro dotazy na stav. 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 uspokojení operací dotazů instance tímto způsobem je ovlivněno vzorcem oddělení odpovědnosti příkazů a dotazů (CQRS).
Tip
Dělení tabulky Instances umožňuje ukládat miliony instancí orchestrace 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.
Tabulka oddílů
Poznámka:
Tato tabulka se zobrazí v centru úloh pouze v případě, že Table Partition Manager je povolená. Pokud ho chcete použít, nakonfigurujte useTablePartitionManagement nastavení v host.json vaší aplikace.
Tabulka Oddíly ukládá stav oddílů pro aplikaci Durable Functions a slouží k distribuci oddílů mezi pracovní procesy vaší aplikace. Každý oddíl má jeden řádek.
Fronty
Funkce orchestratoru, entity a aktivit se aktivují interními frontami v centru úloh aplikace funkcí. Použití front tímto způsobem poskytuje spolehlivé záruky doručení zpráv alespoň jednou. Durable Functions obsahuje dva typy front: řídicí frontu a frontu 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 ve službě Azure Functions. Tato fronta se používá k aktivaci funkcí bezstavové aktivity zrušením zařazení jedné zprávy najednou. Každá z těchto zpráv obsahuje vstupy funkce aktivity a další metadata, například jakou funkci provést. Když aplikace Durable Functions škáluje kapacitu 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.
Řízení front
V Durable Functions existuje více řídicích front na centrum úloh. Řídicí fronta je propracovaně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é jednoúčelové, 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 mezi pracovními procesy vyrovnány zatížením, aby každá fronta byla zpracována pouze jedním pracovním procesem 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ří zprávy řízení orchestrátoru, zprávy odpovědí na funkce aktivit a zprávy časovače. V jednom hlasování se vyřadí z řídicí fronty až 32 zpráv. 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 zpráv vyřazených z front, budou zpracovány 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 host.json a má výchozí hodnotu 32 (maximální hodnota podporovaná frontami Azure). Maximální počet předem načtených zpráv kontrolní fronty, které jsou uloženy do vyrovnávací paměti, je řízeno controlQueueBufferThreshold nastavením v 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 více zpráv z fronty a částečně kvůli načítání více historie orchestrace do paměti. Snížení hodnoty pro controlQueueBufferThreshold může být efektivní způsob, jak snížit využití paměti.
Dotazování fronty
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ě. Po nalezení zprávy modul runtime okamžitě zkontroluje jinou zprávu. Pokud se žádná zpráva nenajde, počká na určitou dobu, než to zkusíte znovu. Po následný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 mít za následek vyšší náklady na úložiště kvůli zvýšeným transakcím úložiště.
Poznámka:
Při spuštění v plánech Consumption a Premium služby Azure Functions se kontroler škálování Azure Functions každých 10 sekund dotazuje každou frontu ovládacích prvků a pracovních položek. Toto další dotazování je nezbytné k určení, kdy aktivovat instance aplikace funkcí a provést rozhodnutí 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 umístí ExecutionStarted zprávu do jedné z řídicích front centra úloh. Za určitých podmínek můžete pozorovat 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ůstává 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 dlouho, než
ExecutionStartedse zpráva přijme a zpracuje modulem 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řecházejí 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í dotazování zpětného dotazování pro řídicí fronty. Toto zpoždění se ale očekává jenom 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 cílovou řídicí frontu, nedojde ke 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í omezení velikosti, které můžou zabránit trvalému zachování všech požadovaných dat do řádku úložiště nebo zprávy fronty. Pokud je například část dat, která je potřeba zachovat ve frontě, větší než 45 kB při serializaci, Durable Functions zkomprimuje data a uloží je do objektu blob. Při ukládání dat do úložiště objektů blob tímto způsobem uloží 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 jsou uloženy v kontejneru <taskhub>-largemessagesobjektů blob .
Důležité informace o výkonu
Dodatečný postup komprese a operace objektu blob pro velké zprávy může být nákladný z hlediska nákladů na latenci procesoru a vstupně-výstupních operací. Durable Functions navíc potřebuje načíst trvalá data v paměti a může to udělat pro mnoho různých spuštění funkcí najednou. V důsledku toho může trvalé ukládání velkých datových částí způsobit vysoké využití paměti. Pokud chcete minimalizovat režii paměti, zvažte ruční zachová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 kód načíst data pouze v případě potřeby, aby se zabránilo redundantnímu zatížení během 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 nakonfigurovat jiný než výchozí účet úložiště. Durable Functions využívá azure Storage silně a použití vyhrazeného účtu úložiště izoluje využití úložiště Durable Functions 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ě se nepodporují. Důrazně doporučujeme používat starší účty úložiště verze 1 pro obecné účely pro Durable Functions. Novější účty úložiště v2 můžou být pro úlohy Durable Functions výrazně dražší. Další informace o typech účtů azure Storage najdete v dokumentaci k přehledu účtu úložiště.
Horizontální navýšení kapacity orchestratoru
Zatímco funkce aktivit je možné škálovat neomezeně přidáním dalších virtuálních počítačů elasticky, jednotlivé instance a entity orchestrátoru jsou omezené tak, aby obývaly jeden oddíl a maximální počet oddílů je omezen 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é výpočetní výkony. Proto není nutné vytvořit velký počet oddílů front řízení, aby se získala velká propustnost pro orchestrace. Většina těžké práce by se měla provádět ve funkcích bezstavové aktivity, které je možné neomezeně škálovat.
Počet řídicích front je definován v souboru host.json . Následující příklad host.json fragment kódu durableTask/storageProvider/partitionCount nastaví 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 si představte následující diagram.
V předchozím diagramu vidíme, že orchestrátory 1 až 6 jsou mezi oddíly vyváženy zatížení. Podobně jsou oddíly, jako jsou aktivity, vyrovnány zatížení mezi pracovními procesy. Oddíly jsou mezi pracovními procesy vyváženy zatížení 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 více pracovních procesů přidělí a oddíly nakonec vyrovnává zatížení napříč všemi pracovními procesy. Pokud budeme i nadále škálovat, nakonec bude každý oddíl nakonec spravovaný jedním pracovníkem. Na druhou stranu budou činnosti nadále vyrovnává zatížení napříč všemi pracovníky. To je znázorněno na následujícím obrázku.
Horní mez maximálního počtu souběžných aktivních orchestrací v libovolném okamžiku se rovná počtu pracovních procesů přidělených vaší aplikaci krát vaší hodnoty maxConcurrentOrchestratorFunctions. Tato horní mez může být přesnější, když jsou vaše oddíly plně škálovány na více instancí mezi pracovními procesy. Při plném škálování na více instancí a protože 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 počtu oddílů, kolikrát je hodnota vaší maxConcurrentOrchestratorFunctionshodnoty .
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 více událostí, například na návratovou hodnotu funkce aktivity, uvolní se 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řípadech, kdy se mají zpracovat nové události. Neexistuje žádný praktický maximální počet orchestrací nebo entit, které se dají spustit 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ě 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ávají další orchestrátory, ale některé jsou neaktivní, zobrazené šedě.
Během horizontálního navýšení kapacity se můžou zapůjčení fronty řízení distribuovat napříč instancemi hostitelů Functions, aby se zajistilo rovnoměrné rozdělení oddílů. Tato 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 tedy třemi řídicími frontami), instance orchestrace a entity můžou být vyrovnány zatížením napříč všemi třemi instancemi hostitelů držících zapůjčení. Další virtuální počítače je možné přidat, aby se zvýšila kapacita pro provádění funkcí aktivity.
Následující diagram znázorňuje, jak hostitel Azure Functions komunikuje s entitami úložiště ve škálovaném prostředí.
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 pouze 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í zatřiďová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, což zajišťuje rovnoměrné rozdělení instancí napříč všemi řídicími frontami.
Obecně řečeno, funkce orchestrátoru mají být jednoduché a neměly by vyžadovat velké výpočetní výkony. Proto není nutné vytvořit velký počet oddílů řídicí fronty, abyste získali velkou propustnost pro orchestrace. Většina těžké práce by se měla provádět ve funkcích bezstavové aktivity, které je možné neomezeně škálovat.
Rozšířené relace
Rozšířené relace jsou mechanismus ukládání do mezipaměti, který udržuje 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í oproti základnímu odolnému úložišti a celkové lepší propustnosti.
Rozšířené relace můžete povolit nastavením durableTask/extendedSessionsEnabled v true souboru host.json . Toto durableTask/extendedSessionIdleTimeoutInSeconds nastavení se dá použít k řízení doby, po jakou dobu bude nečinná relace uložena 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:
- Dochází k celkovému nárůstu využití paměti aplikace funkcí, protože nečinné instance se z paměti tak rychle nenačtou.
- Pokud existuje mnoho souběžných, odlišných, krátkodobých orchestratorů nebo provádění funkcí entity, může dojít k celkovému snížení propustnosti.
Pokud je například nastavená na 30 sekund, pak krátký orchestrátor nebo epizoda funkce entity, durableTask/extendedSessionIdleTimeoutInSeconds která se spustí za méně než 1 sekundu, stále zabírá paměť po dobu 30 sekund. Počítá se také do durableTask/maxConcurrentOrchestratorFunctions výše uvedené kvóty, což potenciálně brání spuštění jiných funkcí orchestrátoru nebo entity.
Specifické účinky rozšířených relací na funkce orchestrátoru a entit jsou popsány v dalších částech.
Poznámka:
Rozšířené relace se v současné době podporují jenom v jazycích .NET, jako je C# (jenom model v procesu) nebo F#. true Nastavení extendedSessionsEnabled pro jiné platformy může vést k problémům s modulem runtime, jako je například bezobslužné 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řehrávají 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átor 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() Pythonu), budou se přehrávat v dávkách odpovědí úkolů v průběhu času. 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 úplného přehrání 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 ventilátory a ventilátory ve velkém počtu akcí, které se dokončí přibližně ve stejnou dobu.
- Pokud funkce orchestrátoru potřebují zpracovávat velké zprávy nebo zpracovávat data náročná na procesor.
Ve všech ostatních situacích obvykle není k dispozici pozorovatelné zlepšení výkonu pro funkce orchestrátoru.
Poznámka:
Tato nastavení by se měla použít až po úplném vývoji a otestovaní funkce orchestrátoru. Výchozí agresivní chování přehrává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 uvádí očekávaná maximální propustnost 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 běžící na jednom malém virtuálním počítači (A1) ve službě Aplikace Azure Service. Ve všech případech se předpokládá, že jsou povolené rozšířené relace . Skutečné výsledky se mohou lišit v závislosti na výkonu procesoru nebo vstupně-výstupních operací provedených kódem funkce.
| Scénář | Maximální propustnost |
|---|---|
| Provádění sekvenční aktivity | 5 aktivit za sekundu, na instanci |
| Paralelní spouštění aktivit (ventilátor) | 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í entity | 64 operací za sekundu |
Pokud se vám nezobrazují očekávaná čísla propustnosti a vaše využití procesoru a paměti se zobrazuje v pořádku, 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í, ventilátorů aktivity a operací entit zvýšením hodnoty controlQueueBufferThreshold nastavení v 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 agresivnějšímu načtení těchto událostí, což snižuje zpoždění související s vyřazením zpráv z front ovládacího prvku Azure Storage. Další informace najdete v referenční dokumentaci k host.json .
Plán Flex Consumption
Plán Flex Consumption je plán hostování azure Functions, který poskytuje řadu výhod plánu Consumption, včetně modelu fakturace bez serveru, a zároveň přidává užitečné funkce, jako jsou privátní sítě, výběr velikosti paměti instance a úplná podpora ověřování spravovaných identit.
Azure Storage je v současné době jediným podporovaným poskytovatelem úložiště pro Durable Functions, když je hostovaný v plánu Flex Consumption.
Při hostování Durable Functions v plánu Flex Consumption byste měli postupovat podle těchto doporučení k výkonu:
- Nastavte vždy připravený počet instancí pro
durableskupinu na1hodnotu . Tím se zajistí, že vždy existuje jedna instance připravená ke zpracování požadavků souvisejících s Durable Functions, čímž se sníží studený start aplikace. - Snižte interval dotazování fronty na 10 sekund nebo méně. Vzhledem k tomu, že tento typ plánu je citlivější na zpoždění dotazování ve frontě, snížení intervalu dotazování pomůže zvýšit frekvenci operací dotazování, a tím zajistit rychlejší zpracování požadavků. Častější operace dotazování ale vedou k vyšším nákladům na účet Azure Storage.
Zpracování vysoké propustnosti
Architektura back-endu Azure Storage přináší určitá omezení maximálního teoretického výkonu a škálovatelnosti Durable Functions. Pokud vaše testování ukazuje, že Durable Functions ve službě Azure Storage nesplňuje vaše požadavky 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. Využívá službu Azure Event Hubs a technologii databáze FASTER 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ích testů se propustnost ve srovnání s výchozím poskytovatelem služby Azure Storage zobrazovala o více než řádově vyšší.
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.