Výkon Windows Workflow Foundation 4

.NET Framework 4 obsahuje velkou revizi Windows Workflow Foundation (WF) s velkými investicemi do výkonu. Tato nová revize představuje významné změny návrhu z předchozích verzí WF, které byly dodány jako součást rozhraní .NET Framework 3.0 a .NET Framework 3.5. Byl znovu navržen od jádra programovacího modelu, modulu runtime a nástrojů, aby se výrazně zlepšil výkon a použitelnost. Toto téma ukazuje důležité charakteristiky výkonu těchto revizí a porovnává je s vlastnostmi předchozí verze.

Výkon jednotlivých komponent pracovního postupu se mezi WF3 a WF4 zvýšil o řád. Díky tomu je mezera mezi ručně zakódovanými službami Windows Communication Foundation (WCF) a službami pracovních postupů WCF poměrně malé. Latence pracovního postupu se ve WF4 výrazně snížila. Výkon trvalosti se zvýšil faktorem 2,5 – 3,0. Monitorování stavu prostřednictvím sledování pracovních postupů má výrazně menší režii. To jsou přesvědčivé důvody pro migraci nebo přijetí WF4 ve vašich aplikacích.

Terminologie

Verze WF představená v rozhraní .NET Framework 4 se bude pro zbytek tohoto tématu označovat jako WF4. WF byl zaveden v rozhraní .NET Framework 3.0 a měl několik menších revizí prostřednictvím rozhraní .NET Framework 3.5 SP1. Verze .NET Framework 3.5 Workflow Foundation bude označována jako WF3 pro zbytek tohoto tématu. WF3 je dodáván v rozhraní .NET Framework 4 souběžně s WF4. Další informace o migraci artefaktů WF3 do WF4 naleznete v tématu: Průvodce migrací windows Workflow Foundation 4.

Windows Communication Foundation (WCF) je jednotný programovací model Microsoftu pro vytváření aplikací orientovaných na služby. Poprvé byla představena jako součást rozhraní .NET Framework 3.0 společně s WF3 a nyní je jednou z klíčových součástí rozhraní .NET Framework.

Windows Server AppFabric je sada integrovaných technologií, které usnadňují sestavování, škálování a správu webových a složených aplikací, které běží ve službě IIS. Poskytuje nástroje pro monitorování a správu služeb a pracovních postupů. Další informace naleznete v tématu Windows Server AppFabric 1.0.

Cíle

Cílem tohoto tématu je ukázat charakteristiky výkonu WF4 s daty měřenými pro různé scénáře. Poskytuje také podrobná porovnání mezi WF4 a WF3, a proto ukazuje skvělá vylepšení, která byla provedena v této nové revizi. Scénáře a data uvedená v tomto článku vyčíslují základní náklady na různé aspekty WF4 a WF3. Tato data jsou užitečná při pochopení charakteristik výkonu WF4 a mohou být užitečná při plánování migrací z WF3 do WF4 nebo použití WF4 při vývoji aplikací. Je však třeba věnovat pozornost závěrům vyplývajícím z údajů uvedených v tomto článku. Výkon složené aplikace pracovního postupu je vysoce závislý na způsobu implementace pracovního postupu a způsobu integrace různých komponent. Jedna musí měřit každou aplikaci, aby určila charakteristiky výkonu dané aplikace.

Přehled vylepšení výkonu WF4

WF4 byla pečlivě navržena a implementována s vysokým výkonem a škálovatelností, které jsou popsány v následujících částech.

WF Runtime

Jádrem modulu runtime WF je asynchronní plánovač, který řídí provádění aktivit v pracovním postupu. Poskytuje výkonné a předvídatelné spouštěcí prostředí pro aktivity. Prostředí má dobře definovaný kontrakt pro spouštění, pokračování, dokončení, zrušení, výjimky a předvídatelný model vláken.

Ve srovnání s WF3 má modul runtime WF4 efektivnější plánovač. Využívá stejný fond vstupně-výstupních vláken, který se používá pro WCF, což je velmi efektivní při provádění dávkových pracovních položek. Fronta plánovače interních pracovních položek je optimalizovaná pro nejběžnější vzory použití. Modul runtime WF4 také spravuje stavy spouštění velmi jednoduchým způsobem s minimální logikou synchronizace a zpracování událostí, zatímco WF3 závisí na registraci a vyvolání náročných událostí při provádění složité synchronizace přechodů stavu.

Úložiště dat a tok

V WF3 se data přidružená k aktivitě modelují prostřednictvím vlastností závislostí implementovaných typem DependencyProperty. Model vlastností závislostí byl zaveden ve Windows Presentation Foundation (WPF). Obecně platí, že tento model je velmi flexibilní pro podporu snadné datové vazby a dalších funkcí uživatelského rozhraní. Model však vyžaduje, aby vlastnosti byly definovány jako statická pole v definici pracovního postupu. Pokaždé, když modul runtime WF nastaví nebo získá hodnoty vlastností, zahrnuje silně váženou vyhledávací logiku.

WF4 používá jasnou logiku definování rozsahu dat, aby výrazně zlepšila způsob zpracování dat v pracovním postupu. Odděluje data uložená v aktivitě od dat, která proudí přes hranice aktivity, pomocí dvou různých konceptů: proměnných a argumentů. Použitím jasného hierarchického rozsahu proměnných a argumentů In/Out/InOut se složitost využití dat pro aktivity výrazně snižuje a životnost dat se také automaticky omezuje. Aktivity mají dobře definovaný podpis, který popisují jejich argumenty. Když jednoduše zkontrolujete aktivitu, můžete určit, jaká data očekává přijetí a jaká data budou vytvořena v důsledku jejího spuštění.

Při vytváření pracovního postupu byly ve WF3 inicializovány aktivity. Aktivity WF 4 se inicializují, pouze když se provádějí odpovídající aktivity. To umožňuje jednodušší životní cyklus aktivity bez provádění operací inicializace nebo zrušení inicializace při vytvoření nové instance pracovního postupu, a tím dosáhl vyšší efektivity.

Řízení toku

Stejně jako v jakémkoli programovacím jazyce poskytuje WF podporu toků řízení pro definice pracovních postupů tím, že zavádí sadu aktivit toku řízení pro sekvencování, smyčky, větvení a další vzory. V WF3, pokud je nutno provést stejnou aktivitu znovu, vytvoří se nová ActivityExecutionContext a aktivita se naklonuje pomocí náročné serializační a deserializační logiky na základě BinaryFormatter. Výkon iterativních toků řízení je obvykle mnohem pomalejší než provádění posloupnosti aktivit.

WF4 to zvládne poměrně jinak. Vezme šablonu aktivity, vytvoří nový objekt ActivityInstance a přidá ho do fronty plánovače. Tento celý proces zahrnuje pouze explicitní vytvoření objektu a je velmi jednoduchý.

Asynchronní programování

Aplikace obvykle mají lepší výkon a škálovatelnost pomocí asynchronního programování pro dlouhotrvající blokující operace, jako jsou vstupně-výstupní operace nebo distribuované výpočetní operace. WF4 poskytuje asynchronní podporu prostřednictvím základních typů AsyncCodeActivityaktivit , AsyncCodeActivity<TResult>. Modul runtime nativně rozumí asynchronním aktivitám, a proto může instanci automaticky umístit do zóny bez uložení, zatímco probíhá asynchronní práce. Vlastní aktivity mohou odvozovat z těchto typů, aby prováděly asynchronní práci, aniž by podržely vlákno plánovače pracovního postupu a blokovaly jakékoliv aktivity, které by mohly probíhat paralelně.

Odesílání zpráv

Služba WF3 měla zpočátku velmi omezenou podporu zasílání zpráv prostřednictvím externích událostí nebo volání webových služeb. V rozhraní .NET Framework 3.5 lze pracovní postupy implementovat jako klienty WCF nebo zpřístupnit jako služby WCF prostřednictvím SendActivity a ReceiveActivity. Ve WF4 byl koncept programování zasílání zpráv založených na pracovních postupech dále posílen prostřednictvím těsné integrace logiky zasílání zpráv WCF do WF.

Sjednocený kanál zpracování zpráv poskytovaný ve WCF v .NET 4 pomáhá službám WF4 výrazně zlepšit výkon a škálovatelnost než WF3. WF4 také poskytuje bohatší podporu programování zasílání zpráv, která umožňuje modelování složitých vzorů výměny zpráv (MEP). Vývojáři můžou k dosažení jednoduchého programování nebo netypových kontraktů služeb použít buď typové kontrakty služeb, aby dosáhli lepšího výkonu bez placení nákladů na serializaci. Podpora ukládání do mezipaměti na straně klienta prostřednictvím SendMessageChannelCache třídy ve WF4 pomáhá vývojářům vytvářet rychlé aplikace s minimálním úsilím. Další informace najdete v tématu Změna úrovní sdílení mezipaměti pro aktivity odesílání.

Deklarativní programování

WF4 poskytuje čistou a jednoduchou deklarativní programovací architekturu pro modelování obchodních procesů a služeb. Programovací model podporuje plně deklarativní složení aktivit bez použití kódu, což výrazně zjednodušuje vytváření pracovních postupů. V rozhraní .NET Framework 4 byla deklarativní programovací architektura založená na XAML sjednocená do jediného sestavení System.Xaml.dll pro podporu WPF i WF.

Ve WF4 poskytuje XAML skutečně deklarativní prostředí a umožňuje definovat celou definici pracovního postupu v kódu XML a odkazovat na aktivity a typy vytvořené pomocí .NET. Bylo obtížné to provést ve WF3 s formátem XOML bez implementace vlastní zákulisní logiky. Nová XAML vrstva v rozhraní .NET 4 má výrazně lepší výkon při serializaci/deserializaci artefaktů pracovního postupu a dělá deklarativní programování atraktivnějším a spolehlivějším.

Návrhář pracovního postupu

Plně deklarativní podpora programování pro WF4 explicitně ukládá vyšší požadavky na výkon doby návrhu pro velké pracovní postupy. Návrhář pracovních postupů ve WF4 má mnohem lepší škálovatelnost pro velké pracovní postupy než pro WF3. Díky podpoře virtualizace uživatelského rozhraní může návrhář během několika sekund snadno načíst velký pracovní postup 1000 aktivit, zatímco téměř nemožné načíst pracovní postup několika stovek aktivit pomocí návrháře WF3.

Porovnání výkonu na úrovni komponent

Tato část obsahuje data o přímém porovnání jednotlivých aktivit v pracovních postupech WF3 a WF4. Klíčové oblasti, jako je trvalost, mají hlubší dopad na výkon než jednotlivé komponenty aktivity. Vylepšení výkonu jednotlivých komponent ve WF4 jsou ale důležitá, protože komponenty jsou teď dostatečně rychlé, aby se porovnávaly s ručně zakódovanou orchestrační logikou. Příklad, na který se vztahuje další část: "Scénář složení služby".

Nastavení prostředí

Výše uvedený obrázek znázorňuje konfiguraci počítače použitou pro měření výkonu na úrovni komponent. Jeden server a pět klientů připojených přes jedno síťové rozhraní Ethernet s rychlostí 1 Gb/s. Pro snadné měření je server nakonfigurován tak, aby používal jedno jádro v serveru s dvojicí procesorů a čtyřmi jádry, běžícím na systému Windows Server 2008 x86. Využití systémového CPU se udržuje téměř na 100%.

Podrobnosti o testu

WF3 CodeActivity je pravděpodobně nejjednodušší aktivita, kterou lze použít v pracovním postupu WF3. Aktivita volá metodu v kódu, do které může programátor pracovního postupu vložit vlastní kód. Ve WF4 neexistuje žádný přímý analog pro WF3 CodeActivity , který poskytuje stejné funkce. Všimněte si, že ve WF4 existuje CodeActivity základní třída, která nesouvisí s WF3 CodeActivity. Doporučuje se, aby autoři pracovních postupů vytvářeli vlastní aktivity a pracovní postupy pouze v XAML. V následujících testech je použita aktivita Comment místo prázdného CodeActivity ve WF4 pracovních postupech. Kód v aktivitě Comment je následující:

C#

[ContentProperty("Body")]
    public sealed class Comment : CodeActivity
    {
        public Comment()
            : base()
        {
        }

        [DefaultValue(null)]
        public Activity Body
        {
            get;
            set;
        }

        protected override void Execute(CodeActivityContext context)
        {
        }
    }

Prázdný pracovní postup

Tento test používá sekvenční pracovní postup bez podřízených aktivit.

Jedna aktivita

Pracovní postup je sekvenční a obsahuje jednu podřízenou aktivitu. Aktivita je CodeActivity bez kódu v případě WF3 a Comment aktivita v případě WF4.

Při 1000 iteracích

Sekvenční pracovní postup obsahuje jednu aktivitu ve smyčce s jednou podřízenou aktivitou, která neprovádí žádnou práci.

Replikátor ve srovnání s ParallelForEach

ReplicatorActivity ve WF3 má režim sekvenčního a paralelního spouštění. V sekvenčním režimu je výkon aktivity podobný WhileActivity. Nejužitečnější ReplicatorActivity je pro paralelní provádění. Analog WF4 pro tohle je aktivita ParallelForEach<T>.

Následující diagram znázorňuje pracovní postupy použité pro tento test. Pracovní postup WF3 je vlevo a pracovní postup WF4 je vpravo.

Sekvenční pracovní postup s pěti aktivitami

Cílem tohoto testu je ukázat účinek provádění několika aktivit v sekvenci. V posloupnosti je pět aktivit.

Obor transakce

Test oboru transakce se mírně liší od ostatních testů v tom, že nová instance pracovního postupu není vytvořena pro každou iteraci. Místo toho je pracovní postup strukturovaný smyčkou while obsahující TransactionScope aktivitu, která obsahuje jedinou aktivitu, která nedělá žádnou práci. Každé spuštění dávky 50 iterací prostřednictvím smyčky while se počítá jako jedna operace.

Kompenzace

Pracovní postup WF3 má jednu kompenzační aktivitu s názvem WorkScope. Aktivita jednoduše implementuje ICompensatableActivity rozhraní:

C#

class WorkScope :
        CompositeActivity, ICompensatableActivity
    {
        public WorkScope() : base() { }

        public WorkScope(string name)
        {
            this.Name = name;
        }

        public ActivityExecutionStatus Compensate(
            ActivityExecutionContext executionContext)
        {
            return ActivityExecutionStatus.Closed;
        }
    }

Obslužná rutina chyby cílí na WorkScope aktivitu. Pracovní postup WF4 je stejně zjednodušený. A CompensableActivity má tělo a kompenzační obslužnou rutinu. V posloupnosti následuje explicitní kompenzace. Aktivita těla a kompenzační obslužná rutina jsou obě prázdné implementace.

C#

public sealed class CompensableActivityEmptyCompensation : CodeActivity
    {
        public CompensableActivityEmptyCompensation()
            : base() { }

        public Activity Body { get; set; }

        protected override void Execute(CodeActivityContext context) { }
    }
    public sealed class CompensableActivityEmptyBody : CodeActivity
    {
        public CompensableActivityEmptyBody()
            : base() { }

        public Activity Body { get; set; }

        protected override void Execute(CodeActivityContext context) { }
    }

Následující diagram znázorňuje základní pracovní postup kompenzace. Pracovní postup WF3 je vlevo a pracovní postup WF4 je vpravo.

Výsledky testu výkonnosti

Všechny testy se měří v pracovních postupech za sekundu s výjimkou testu oboru transakce. Jak je vidět výše, výkon WF runtime se celkově zlepšil, zejména v oblastech, které vyžadují vícenásobné spuštění stejné aktivity, jako je smyčka while.

Scénář složení služby

Jak je znázorněno v předchozí části " Porovnání výkonu na úrovni komponent", došlo k významnému snížení režie mezi WF3 a WF4. Služby pracovních postupů WCF teď můžou téměř odpovídat výkonu ručně zakódovaných služeb WCF, ale stále mají všechny výhody modulu runtime WF. Tento testovací scénář porovnává službu WCF se službou pracovního postupu WCF ve WF4.

Služba Online Store

Jednou z silných stránek Windows Workflow Foundation je schopnost vytvářet procesy pomocí několika služeb. V tomto příkladu je služba online obchodu, která orchestruje využití dvou služeb s realizací objednávky. Prvním krokem je ověření objednávky pomocí služby ověřování objednávek. Druhým krokem je vyplnění objednávky pomocí služby skladu.

Obě back-endové služby, Služba ověřování objednávek a Služba skladu, zůstávají pro oba testy stejné. Součástí, která se mění, je služba Online Store, která provádí orchestraci. V jednom případě je služba ručně zakódovaná jako služba WCF. V druhém případě je služba napsaná jako služba pracovního postupu WCF ve WF4. Funkce specifické pro WF, jako je sledování a trvalost, jsou pro tento test vypnuté.

Životní prostředí

Požadavky klientů se provádějí do služby Online Store prostřednictvím protokolu HTTP z více počítačů. Jeden počítač hostuje všechny tři služby. Přenosová vrstva mezi službou Online Store a back-endovými službami je TCP nebo HTTP. Měření operací za sekundu vychází z počtu dokončených PurchaseOrder volání provedených ve službě Online Store. Sdružování kanálů je nová funkce dostupná ve WF4. V části WCF tohoto testu není sdružování kanálů standardně k dispozici, proto byla ve službě Online Store použita ruční implementace jednoduché techniky sdružování.

Výkon

Připojení k backendovým službám TCP bez sdružování kanálů má služba WF dopad 17,2% na propustnost. Se sdružováním kanálů je penalizace asi 23,8%. U protokolu HTTP je dopad mnohem menší: 4,3% bez sdružování a 8.1% s sdružováním. Je také důležité si uvědomit, že sdružování kanálů při použití protokolu HTTP poskytuje velmi malou výhodu.

Přestože v tomto testu zatížení způsobené modulem runtime WF4 je v porovnání s ručně zakódovanou službou WCF, lze to považovat za nejhorší možný scénář. Dvě back-endové služby v tomto testu dělají velmi málo práce. Ve skutečném komplexním scénáři by tyto služby prováděly dražší operace, jako jsou volání databáze, což by mělo menší dopad na výkon přenosové vrstvy. Díky dostupným funkcím ve WF4 je Workflow Foundation rozumnou volbou pro vytváření služeb orchestrace.

Klíčové aspekty výkonu

Oblasti funkcí v této části, s výjimkou interoperability, se mezi WF3 a WF4 velmi změnily. To má vliv na návrh aplikací pracovních postupů a také na výkon.

Latence aktivace pracovního postupu

V aplikaci služby pracovního postupu WCF je důležitá latence spuštění nového pracovního postupu nebo načtení existujícího pracovního postupu, protože může blokovat. Tento testovací případ měří hostitele XOML WF3 proti hostiteli WF4 XAMLX v typickém scénáři.

Nastavení prostředí

Testovací nastavení

V tomto scénáři klientský počítač kontaktuje službu pracovního postupu WCF pomocí kontextové korelace. Korelace kontextu vyžaduje speciální kontextovou vazbu a používá hlavičku kontextu nebo soubor cookie ke spojení zpráv se správnou instancí pracovního postupu. Má výhodu výkonu v tom, že ID korelace se nachází v záhlaví zprávy, takže tělo zprávy nemusí být analyzováno.

Služba vytvoří nový pracovní postup s požadavkem a odešle okamžitou odpověď, aby měření latence neobsáhne čas strávený spuštěním pracovního postupu. Pracovní postup WF3 je XOML s kódem a pracovní postup WF4 je zcela XAML. Pracovní postup WF4 vypadá takto:

Aktivita Receive vytvoří instanci pracovního postupu. Hodnota předaná v přijaté zprávě se zopakuje v odpovědi. Sekvence následující po odpovědi obsahuje zbytek pracovního postupu. V případě nahoře se zobrazí jen jedna aktivita komentáře. Počet aktivit komentářů se mění tak, aby simuloval složitost pracovního postupu. Aktivita komentáře je ekvivalentní WF3 CodeActivity, která neprovádí žádnou práci. Další informace o aktivitě komentáře najdete v části Porovnání výkonu na úrovni komponent výše v tomto článku.

Výsledky testů

Studená a teplá latence pro služby pracovních postupů WCF:

V předchozím grafu odkazuje termín "cold" na případ, kdy pro daný pracovní postup neexistuje žádný WorkflowServiceHost. Jinými slovy, studená latence spočívá v tom, že pracovní postup se používá poprvé a je potřeba zkompilovat XOML nebo XAML. Teplá latence (doba zahřátí) je doba potřebná k vytvoření nové instance pracovního postupu, když už byl typ tohoto postupu zkompilován. Složitost pracovního postupu v případě WF4 velmi málo liší, ale v případě WF3 má lineární průběh.

Propustnost korelace

WF4 zavádí novou funkci korelace založenou na obsahu. WF3 poskytuje pouze kontextovou korelaci. Korelaci na základě kontextu je možné provést pouze přes konkrétní vazby kanálu WCF. ID pracovního postupu se vloží do záhlaví zprávy při použití těchto vazeb. Modul runtime WF3 mohl identifikovat pracovní postup pouze podle id. Při korelaci na základě obsahu může autor pracovního postupu vytvořit klíč korelace z relevantní části dat, jako je číslo účtu nebo ID zákazníka.

Kontextová korelace má výhodu výkonu v tom, že klíč korelace se nachází v záhlaví zprávy. Klíč lze číst ze zprávy bez de-serializace nebo kopírování zpráv. V korelaci založené na obsahu je klíč korelace uložen v textu zprávy. Výraz XPath slouží k vyhledání klíče. Náklady na toto dodatečné zpracování závisí na velikosti zprávy, hloubkě klíče v textu a počtu klíčů. Tento test porovnává kontextovou a obsahovou korelaci a také ukazuje snížení výkonu při použití více klíčů.

Nastavení prostředí

Testovací nastavení

Předchozí pracovní postup je stejný jako v části Trvalost . Pro korelační testy bez trvalosti není v modulu runtime nainstalován žádný zprostředkovatel trvalosti. Korelace probíhá na dvou místech: CreateOrder a CompleteOrder.

Výsledky testů

Tento graf ukazuje snížení výkonu při nárůstu počtu klíčů používaných v korelaci založené na obsahu. Podobnost v křivkách mezi protokoly TCP a HTTP označuje režii spojenou s těmito protokoly.

Korelace s trvalostí

Díky trvalému pracovnímu postupu se zatížení procesoru z korelace na základě obsahu posune z modulu runtime pracovního postupu do databáze SQL. Uložené procedury v SQL zprostředkovateli trvalosti pracují s klíči pro nalezení příslušného pracovního postupu.

Korelace založená na kontextu je stále rychlejší než korelace založená na obsahu. Rozdíl je však méně výrazný, protože trvalost má větší vliv na výkon než korelace.

Složitá propustnost pracovního postupu

Složitost pracovního postupu se neměří jenom podle počtu aktivit. Složené aktivity mohou obsahovat mnoho podřízených položek a tyto podřízené položky mohou být také složené aktivity. S rostoucím počtem úrovní vnoření se zvyšuje také počet aktivit, které mohou být aktuálně ve výkonném stavu, a počet proměnných, které mohou být ve stavu. Tento test porovnává propustnost mezi WF3 a WF4 při provádění složitých pracovních postupů.

Testovací nastavení

Tyto testy byly provedeny na intel Xeon X5355 @ 2,66GHz 4-way počítač s 4GB RAM se systémem Windows Server 2008 x64. Testovací kód běží v jednom procesu s jedním vláknem na každém jádru, aby dosáhl 100% využití jádra procesoru%.

Pracovní postupy vygenerované pro tento test mají dvě hlavní proměnné: hloubku a počet aktivit v každé sekvenci. Každá úroveň hloubky zahrnuje paralelní aktivitu, cyklus while, rozhodnutí, přiřazení a sekvence. V návrháři WF4 na obrázku níže je znázorněn vývojový diagram nejvyšší úrovně. Každá aktivita vývojového diagramu se podobá hlavnímu vývojovému diagramu. Při vytváření obrázku tohoto pracovního postupu může být užitečné uvažovat o fraktalu, kde je hloubka omezena na parametry testu.

Počet aktivit v daném testu je určen hloubkou a počtem aktivit na sekvenci. Následující rovnice vypočítá počet aktivit v testu WF4:

Počet aktivit testu WF3 se dá vypočítat s mírně odlišnou rovnicí kvůli dodatečné sekvenci:

Kde d je hloubka a je počet aktivit na sekvenci. Logika za těmito rovnicemi spočívá v tom, že první konstanta, vynásobená hodnotou a, představuje počet sekvencí a druhá konstanta je statický počet aktivit na aktuální úrovni. V každém vývojovém diagramu jsou tři podřízené aktivity. Na nejnižší úrovni hloubky jsou tyto vývojové diagramy prázdné, ale na dalších úrovních jsou kopiemi hlavního vývojového diagramu. Počet aktivit v definici pracovního postupu každé testovací varianty je uveden v následující tabulce:

Počet aktivit v definici pracovního postupu se výrazně zvyšuje s každou úrovní hloubky. V dané instanci pracovního postupu se ale provede pouze jedna cesta na jeden bod rozhodnutí, takže se provede pouze malá podmnožina skutečných aktivit.

Pro WF3 byl vytvořen ekvivalentní pracovní postup. Návrhář WF3 zobrazuje celý pracovní postup v návrhové oblasti místo vnořeného zobrazení, proto je příliš velký, aby mohl být zobrazen v tomto tématu. Níže je uvedený fragment pracovního postupu.

Pro cvičení vnoření v extrémním případě používá jiný pracovní postup, který je součástí tohoto testu, 100 vnořených sekvencí. Ve vnitřní sekvenci je jedna Comment nebo CodeActivity.

Sledování a trvalost se v rámci tohoto testu nepoužívají.

Výsledky testů

I u složitých pracovních postupů s velkou hloubkou a vysokým počtem aktivit jsou výsledky výkonu konzistentní s dalšími čísly propustnosti, která jsou znázorněna dříve v tomto článku. Propustnost WF4 je řádově rychlejší a musí se porovnávat v logaritmickém měřítku.

Paměť

Režie paměti služby Windows Workflow Foundation se měří ve dvou klíčových oblastech: složitost pracovního postupu a počet definic pracovních postupů. Měření paměti byla provedena na 64bitové pracovní stanici s Windows 7. Existuje mnoho způsobů, jak získat měření velikosti pracovní sady, jako je monitorování čítačů výkonu, dotazování Environment.WorkingSet nebo použití nástroje, jako je VMMap dostupný z VMMap. Kombinace metod byla použita k získání a ověření výsledků každého testu.

Test složitosti pracovního postupu

Test složitosti pracovního postupu měří rozdíl ve složitosti pracovní sady na základě složitosti pracovního postupu. Kromě složitých pracovních postupů použitých v předchozí části se přidají nové varianty, které pokrývají dva základní případy: jeden pracovní postup aktivity a posloupnost s 1000 aktivitami. Pro tyto testy jsou pracovní postupy inicializovány a provedeny k dokončení v jedné sériové smyčce po dobu jedné minuty. Každá testovací varianta se spustí třikrát a zaznamenaná data jsou průměrem těchto tří spuštění.

Tyto dva nové základní testy mají pracovní postupy, které vypadají takto:

V pracovním postupu WF3 zobrazeném výše se používají prázdné CodeActivity aktivity. Výše uvedený pracovní postup WF4 používá Comment aktivity. Aktivita Comment byla popsána v části Porovnání výkonu na úrovni komponent dříve v tomto článku.

Jednou z jasných tendencí, které lze pozorovat v tomto grafu, je to, že vnoření má relativně minimální dopad na využití paměti v WF3 i WF4. Nejvýznamnější dopad na paměť pochází z počtu aktivit v daném pracovním postupu. Vzhledem k datům ze sekvence 1000, variační sekvence 5 s komplexní hloubkou 5 a variační sekvence 1 s komplexní hloubkou 7, je jasné, že jakmile počet aktivit dosáhne tisíců, zvýšení využití paměti se stává výraznějším. V extrémním případě (hloubka 7 sekvencí 1), kde se nachází přibližně 29 tisíc aktivit, WF4 používá téměř 79% méně paměti než WF3.

Test více definic pracovních postupů

Měření paměti na definici pracovního postupu je rozděleno do dvou různých testů z důvodu dostupných možností hostování pracovních postupů ve WF3 a WF4. Testy se spouští jiným způsobem než test složitosti pracovního postupu, protože daný pracovní postup je instancován a proveden pouze jednou pro každou definici. Důvodem je to, že definice pracovního postupu a jeho hostitel zůstávají v paměti po celou dobu životnosti AppDomain. Paměť používaná spuštěním dané instance pracovního postupu by se měla během uvolňování paměti vyčistit. Pokyny k migraci pro WF4 obsahují podrobnější informace o možnostech hostování. Další informace naleznete v tématu WF Migration Cookbook: Workflow Hosting.

Vytváření mnoha definic pracovního postupu pro test definice pracovního postupu lze provádět několika způsoby. Pomocí generování kódu můžete například vytvořit sadu 1 000 pracovních postupů, které jsou shodné s výjimkou názvu a uložit každý z těchto pracovních postupů do samostatných souborů. Tento přístup byl přijat pro test hostovaný konzolou. Ve WF3 byla třída WorkflowRuntime použita k spuštění definic pracovních postupů. WF4 může použít WorkflowApplication buď k vytvoření jedné instance pracovního postupu, nebo přímo použít WorkflowInvoker ke spuštění aktivity, jako by se jednalo o volání metody. WorkflowApplication je hostitelem jedné instance pracovního postupu a má blíže paritu funkcí tak, aby se blížila funkcí WorkflowRuntime a proto byla použita v tomto testu.

Při hostování pracovních postupů ve službě IIS je možné použít VirtualPathProvider k vytvoření nové WorkflowServiceHost místo generování všech souborů XAMLX nebo XOML. Zpracovává VirtualPathProvider příchozí požadavek a odpoví "virtuálním souborem", který je možné načíst z databáze nebo v tomto případě vygenerovaný za běhu. Proto není nutné vytvářet 1 000 fyzických souborů.

Definice pracovního postupu použité v testu konzoly byly jednoduché sekvenční pracovní postupy s jednou aktivitou. Jedna aktivita byla pro případ WF3 prázdná CodeActivity a Comment aktivita pro případ WF4. Pracovní postupy hostované službou IIS, začínající přijetím zprávy a končící odesláním odpovědi:

Následující obrázek znázorňuje pracovní postup WF3 s receiveActivity a pracovním postupem WF4 se vzorem požadavků a odpovědí:

Následující tabulka ukazuje rozdíl v pracovní sadě mezi jednou definicí pracovního postupu a 1001 definicemi:

Možnosti hostování	Rozdílová pracovní sada WF3	Rozdílová pracovní sada WF4
Hostované pracovní postupy konzolové aplikace	18 MB	9 MB
Služby pracovních postupů hostované službou IIS	446 MB	364 MB

Hostování definic pracovních postupů ve službě IIS spotřebovává mnohem více paměti kvůli WorkflowServiceHost, podrobným artefaktům služby WCF a logice zpracování zpráv spojené s hostitelem.

Pro hostování konzoly ve WF3 byly pracovní postupy implementovány v kódu místo XOML. Ve WF4 je výchozí použít XAML. XAML je uložen jako vložený prostředek v sestavení a zkompilován během modulu runtime pro zajištění implementace pracovního postupu. S tímto procesem souvisí určitá režie. Aby bylo možné provést spravedlivé porovnání mezi WF3 a WF4, používaly se místo XAML programové pracovní postupy. Příklad jednoho z pracovních postupů WF4 je uvedený níže:

C#

public class Workflow1 : Activity
{
    protected override Func<Activity> Implementation
    {
        get
        {
            return new Func<Activity>(() =>
            {
                return new Sequence
                {
                    Activities = {
                        new Comment()
                    }
                };
            });
        }
        set
        {
            base.Implementation = value;
        }
    }
}

Existuje mnoho dalších faktorů, které můžou ovlivnit spotřebu paměti. Stejné rady pro všechny spravované programy platí i nadále. V prostředích hostovaných službou IIS zůstane objekt vytvořený pro definici pracovního postupu v paměti, WorkflowServiceHost dokud nebude fond aplikací recyklován. Při psaní rozšíření je třeba mít na paměti. Nejlepší je také vyhnout se "globálním" proměnným (proměnným vymezeným na celý pracovní postup) a omezit rozsah proměnných všude, kde je to možné.

Služby modulu runtime pracovního postupu

Perzistence

WF3 i WF4 se dodávají se zprostředkovatelem trvalosti SQL. Zprostředkovatel trvalosti SQL WF3 je jednoduchá implementace, která serializuje instanci pracovního postupu a uloží ji do objektu blob. Z tohoto důvodu výkon tohoto poskytovatele výrazně závisí na velikosti instance pracovního postupu. V WF3 se velikost instance může z mnoha důvodů zvětšit, jak je popsáno dříve v tomto dokumentu. Mnoho zákazníků se rozhodne nepoužívat výchozího zprostředkovatele trvalosti SQL, protože uložení serializované instance do databáze neposkytuje žádný přehled o stavu pracovního postupu. Aby bylo možné najít konkrétní pracovní postup bez znalosti ID pracovního postupu, bylo by nutné deserializovat každou trvalou instanci a prozkoumat obsah. Mnoho vývojářů dává přednost psaní vlastních poskytovatelů uchování dat, aby tuto překážku překonali.

Poskytovatel trvalosti SQL WF4 se pokusil některé z těchto problémů vyřešit. Tabulky trvalosti zveřejňují určité informace, jako jsou aktivní záložky a propagační vlastnosti. Nová funkce korelace založená na obsahu ve WF4 by použitím přístupu trvalosti WF3 SQL nefungovala dobře, což vedlo ke změně v organizaci instance pracovního postupu uložené v perzistenci. Díky tomu je úloha zprostředkovatele trvalosti složitější a zvyšuje zatížení databáze.

Nastavení prostředí

Testovací nastavení

I s vylepšenou sadou funkcí a lepším zpracováním souběžnosti je poskytovatel trvalosti SQL ve WF4 rychlejší než poskytovatel ve WF3. Abychom to ukázali, porovnají se níže dva pracovní postupy, které provádějí v podstatě stejné operace ve WF3 a WF4.

Oba pracovní postupy jsou vytvořeny přijatou zprávou. Po odeslání počáteční odpovědi se pracovní postup zachová. K zahájení perzistence ve WF3 se použije prázdný TransactionScopeActivity. Totéž by se dalo dosáhnout ve WF3 označením aktivity jako "perzistence při zavření". Druhá, korelovaná zpráva dokončí workflow. Pracovní postupy jsou uloženy, ale neodstraněny z paměti.

Výsledky testů

Pokud je přenos mezi klientem a střední vrstvou realizován pomocí protokolu HTTP, persistence ve WF4 ukazuje zlepšení o 2,6 násobek. Přenos TCP tento faktor zvyšuje na 3,0krát. Ve všech případech je využití procesoru na střední úrovni 98% nebo vyšší. Důvodem, proč je vyšší propustnost WF4, je rychlejší běh pracovního postupu. Velikost serializované instance je v obou případech nízká a v této situaci není hlavním prvkem přispívání.

Pracovní postupy WF3 i WF4 v tomto testu používají aktivitu k explicitní indikaci, kdy má dojít k trvalosti. To má výhodu zachování pracovního postupu bez jeho uvolnění. Ve WF3 je také možné použít zachování pomocí funkce TimeToUnload, ale tím se instance pracovního postupu uvolní z paměti. Pokud vývojář používající WF3 chce zajistit, aby pracovní postup zůstal v určitých bodech, musí buď změnit definici pracovního postupu, nebo zaplatit náklady na uvolnění a opětovné načtení instance pracovního postupu. Nová funkce ve WF4 umožňuje persistovat bez uvolnění: TimeToPersist. Tato funkce umožňuje uložení instance pracovního postupu během nečinnosti, ale zůstává v paměti, dokud není dosažena prahová hodnota TimeToUnload nebo se obnoví spuštění.

Všimněte si, že poskytovatel trvalosti WF4 SQL provádí více práce v databázové vrstvě. Databáze SQL se může stát kritickým bodem, takže je důležité monitorovat využití procesoru a disku. Při testování výkonu aplikací pracovních postupů nezapomeňte zahrnout následující čítače výkonu z databáze SQL:

• PhysicalDisk\%Disk doba čtení

• PhysicalDisk\% Doba využití disku

• PhysicalDisk\% doba zápisu na disk

• PhysicalDisk\% Průměrná délka fronty disku

• PhysicalDisk\Avg. Délka fronty čtení disku

• PhysicalDisk\Průměrná délka fronty zápisu na disk

• PhysicalDisk\Current Disk Queue Length

• Informace o procesoru\% čas procesoru

• SQLServer:Latches\Průměrná čekací doba na západku (ms)

• SQLServer:Latches\Latch Waits/sek

Sledování

Sledování pracovního postupu lze použít ke sledování průběhu pracovního postupu. Informace zahrnuté ve sledovacích událostech jsou určeny sledovacím profilem. Čím složitější je profil sledování, tím dražší bude sledování.

WF3 se dodává se službou pro sledování založenou na SQL. Tato služba může fungovat v dávkových a nesádkových režimech. V režimu bez dávek se události sledování zapisují přímo do databáze. V dávkovém režimu se události sledování shromažďují ve stejné dávce jako stav instance pracovního postupu. Dávkový režim má nejlepší výkon pro nejširší škálu návrhů pracovních postupů. Dávkování však může mít negativní dopad na výkon, pokud pracovní postup spouští mnoho aktivit bez uložení a jsou tyto aktivity sledovány. K tomu obvykle dochází ve smyčce a nejlepším způsobem, jak se vyhnout tomuto scénáři, je navrhnout velké smyčky tak, aby obsahovaly bod trvalosti. Zavedení bodu trvalosti do smyčky může negativně ovlivnit výkon, takže je důležité změřit náklady na každý z nich a vytvořit rovnováhu.

WF4 není dodáván se službou pro sledování SQL. Záznam informací o sledování do databáze SQL je možné zpracovat lépe z aplikačního serveru místo integrovaného do rozhraní .NET Framework. Sledování SQL je proto nyní zpracováno technologií AppFabric. Předem připravený poskytovatel sledování ve WF4 je založený na trasování událostí v systému Windows (ETW).

EtW je systém událostí nízké latence na úrovni jádra integrovaný do Windows. Používá model poskytovatele/spotřebitele, který umožňuje, aby se pokuta za trasování událostí uplatnila pouze tehdy, když skutečně existuje spotřebitel. Kromě událostí jádra, jako je například využití procesoru, disku, paměti a sítě, využívá Trasování událostí pro Windows také řada aplikací. Události ETW jsou výkonnější než čítače výkonu, protože je lze přizpůsobit aplikaci. Událost může obsahovat text, například ID pracovního postupu nebo informační zprávu. Události jsou také kategorizovány bitovými maskami, aby využívání určité podmnožiny událostí mělo menší dopad na výkon než zachycení všech jednotlivých událostí.

Mezi výhody přístupu používání ETW pro trasování namísto SQL patří:

• Shromažďování událostí sledování je možné oddělit do jiného procesu. Tím získáte větší flexibilitu při zaznamenávání událostí.

• Události trasování událostí pro Windows (ETW) lze snadno kombinovat s událostmi ETW pro WCF nebo s dalšími poskytovateli ETW, jako je SQL Server nebo jádrový poskytovatel.

• Autoři pracovního postupu nemusí měnit pracovní postup, aby lépe fungoval s konkrétní implementací sledování, jako je dávkový mód sledovacího servisu WF3 SQL.

• Správce může sledování zapnout nebo vypnout bez recyklace hostitelského procesu.

Výhody výkonu ETW sledování přicházejí s nevýhodou. Události ETW se mohou ztratit, pokud je systém pod silným zatížením prostředků. Zpracování událostí není určeno k blokování normálního spuštění programu, a proto není zaručeno, že všechny události etW budou vysílány svým odběratelům. Díky tomu je ETW sledování skvělé pro monitorování stavu, ale není vhodné pro auditování.

I když WF4 nemá zprostředkovatele sledování SQL, AppFabric to dělá. Přístup AppFabric ke sledování SQL spočívá v přihlášení k odběru událostí ETW pomocí služby Windows, která události zpracovává v dávkách a zapisuje je do tabulky SQL navržené pro rychlé vkládání. Samostatná úloha vyprázdní data z této tabulky a přetváří je do podoby sestavových tabulek, které lze zobrazit na řídicím panelu AppFabric. To znamená, že dávka sledování událostí se zpracovává nezávisle na pracovním postupu, ze kterého pochází, a proto nemusí čekat na bod trvalosti před zaznamenání.

Události ETW (Event Tracing for Windows) je možné zaznamenávat pomocí nástrojů jako logman nebo xperf. Kompaktní soubor ETL lze zobrazit pomocí nástroje, jako je xperfview nebo převeden na čitelnější formát, například XML, s tracerpt. Jedinou možností pro získání událostí sledování bez databáze SQL ve službě WF3 je vytvoření vlastní sledovací služby. Další informace o trasování událostí pro Windows naleznete v tématu Služby WCF a Trasování událostí pro Windows a Trasování událostí – aplikace systému Windows.

Povolení sledování pracovních postupů bude mít vliv na výkon v různých stupních. Následující srovnávací test používá nástroj logman ke zpracování událostí trasování ETW a k zaznamenání těchto událostí do souboru ETL. Náklady na sledování SQL v AppFabricu nejsou v oboru tohoto článku. Základní profil sledování, který se používá také v AppFabricu, se zobrazuje v tomto srovnávacím testu. Zahrnuté jsou také náklady na sledování pouze událostí monitorování stavu. Tyto události jsou užitečné pro řešení problémů a určení průměrné propustnosti systému.

Nastavení prostředí

Výsledky testů

Monitorování stavu má přibližně 3% dopad na propustnost. Náklady na základní profil jsou přibližně 8%.

Interoperabilita

WF4 je téměř úplný přepis WF, a proto pracovní postupy a aktivity WF3 nejsou přímo kompatibilní s WF4. Mnoho zákazníků, kteří dříve přijali Windows Workflow Foundation, bude mít interní definice pracovních postupů nebo definice pracovních postupů třetích stran a vlastní aktivity pro WF3. Jedním ze způsobů, jak usnadnit přechod na WF4, je použít aktivitu spolupráce, která může provádět aktivity WF3 z pracovního postupu WF4. Doporučuje se, aby se aktivita Interop používala jenom v případě potřeby. Další informace o migraci na WF4 najdete v pokynech k migraci WF4.

Nastavení prostředí

Výsledky testů

Následující tabulka ukazuje výsledky spuštění pracovního postupu obsahujícího pět aktivit v posloupnosti v různých konfiguracích.

Zkouška	Propustnost (pracovní postupy/s)
Sekvence WF3 v běhovém prostředí WF3	1,576
Sekvence WF3 během běhu WF4 pomocí Interop	dva tisíce sedm set čtyřicet pět
Sekvence WF4	153,582

Existuje výrazné zvýšení výkonu při použití Interop oproti přímému použití WF3. Ve srovnání s aktivitami WF4 je však nárůst zanedbatelný.

Shrnutí

Velké investice do výkonu WF4 se vyplatily v mnoha zásadních oblastech. Výkon jednotlivých komponent pracovního postupu je v některých případech u WF4 stovkykrát rychlejší než u WF3 díky efektivnější optimalizaci modulu WF runtime. Čísla latencí jsou také výrazně lepší. To znamená, že snížení výkonu při používání WF na rozdíl od ručního kódování služeb orchestrace WCF je velmi malé vzhledem k přidaným výhodám používání WF. Výkon trvalosti se zvýšil faktorem 2,5 – 3,0. Monitorování stavu prostřednictvím sledování pracovních postupů teď má velmi malou režii. Komplexní sada průvodců migrací je k dispozici pro ty, kteří zvažují přechod z WF3 na WF4. To vše by mělo učinit z WF4 atraktivní volbu pro psaní složitých aplikací.