A Windows Workflow Foundation 4 teljesítménye

.NET-keretrendszer 4 tartalmazza a Windows Workflow Foundation (WF) jelentős felülvizsgálatát, amely jelentős teljesítménybeli befektetésekkel rendelkezik. Ez az új változat jelentős módosításokat vezet be a WF korábbi verzióihoz képest, amelyek a 3.0-s és .NET-keretrendszer 3.5-ös .NET-keretrendszer részeként szállítottak. A programozási modell, a futtatókörnyezet és az eszközkezelés magjából lett újratervezve a teljesítmény és a használhatóság javítása érdekében. Ez a témakör bemutatja ezeknek a változatoknak a fontos teljesítményjellemzőit, és összehasonlítja őket az előző verzióéval.

Az egyes munkafolyamat-összetevők teljesítménye nagyságrendekkel nőtt a WF3 és a WF4 között. Így a kézzel kódolt Windows Communication Foundation (WCF) szolgáltatások és a WCF munkafolyamat-szolgáltatások közötti különbség meglehetősen kicsi. A munkafolyamat késése jelentősen csökkent a WF4-ben. A megőrzési teljesítmény 2,5-3,0-s tényezővel nőtt. Az állapotmonitorozás a munkafolyamat-nyomon követés révén jelentősen kevesebb többletterhelést jelent. Ezek meggyőző érvek a WF4-be való migrálásra vagy az alkalmazásokban való bevezetésére.

Terminológia

A .NET-keretrendszer 4-ben bevezetett WF-verziót a témakör további részében WF4-nek nevezzük. A WF .NET-keretrendszer 3.0-s verziójában jelent meg, és a 3.5 SP1 .NET-keretrendszer néhány kisebb változatot is módosított. A Workflow Foundation .NET-keretrendszer 3.5-ös verzióját a témakör további részében WF3-nak nevezzük. A WF3 .NET-keretrendszer 4 egymás mellett, WF4-sel együtt szállítható. A WF3-összetevők WF4-re való migrálásáról további információt a Windows Workflow Foundation 4 migrálási útmutatójában talál.

A Windows Communication Foundation (WCF) a Microsoft egységes programozási modellje a szolgáltatásorientált alkalmazások létrehozásához. Először a .NET-keretrendszer 3.0 és a WF3 részeként vezették be, és most a .NET-keretrendszer egyik legfontosabb összetevője.

A Windows Server AppFabric olyan integrált technológiák készlete, amelyek megkönnyítik az IIS-en futó webes és összetett alkalmazások létrehozását, méretezését és kezelését. Eszközöket biztosít a szolgáltatások és munkafolyamatok figyeléséhez és kezeléséhez. További információ: Windows Server AppFabric 1.0.

Célok

A témakör célja a WF4 teljesítményjellemzőinek bemutatása különböző forgatókönyvekhez mért adatokkal. Részletes összehasonlítást is nyújt a WF4 és a WF3 között, és így az új változatban végrehajtott nagyszerű fejlesztéseket mutatja be. Az ebben a cikkben bemutatott forgatókönyvek és adatok számszerűsítik a WF4 és a WF3 különböző aspektusainak mögöttes költségeit. Ezek az adatok hasznosak a WF4 teljesítményjellemzőinek megértéséhez, és hasznosak lehetnek a WF3-ról WF4-re való migrálás megtervezésében, vagy a WF4 alkalmazásfejlesztésben való használatához. A cikkben bemutatott adatokból levont következtetéseket azonban körültekintően kell figyelembe venni. Az összetett munkafolyamat-alkalmazások teljesítménye nagymértékben függ a munkafolyamat implementálásától és a különböző összetevők integrálásától. Az alkalmazás teljesítményjellemzőinek meghatározásához minden alkalmazást meg kell mérni.

A WF4 teljesítménybeli fejlesztéseinek áttekintése

A WF4-et gondosan megtervezték és nagy teljesítménnyel és méretezhetőséggel hajtották végre, amelyet a következő szakaszokban ismertetünk.

WF-futtatókörnyezet

A WF-futtatókörnyezet középpontjában egy aszinkron ütemező áll, amely a munkafolyamat tevékenységeinek végrehajtását vezérli. Teljesíthető, kiszámítható végrehajtási környezetet biztosít a tevékenységekhez. A környezet egy jól meghatározott szerződéssel rendelkezik a végrehajtásra, a folytatásra, a befejezésre, a lemondásra, a kivételekre és egy kiszámítható szálmodellre.

A WF3-hoz képest a WF4-futtatókörnyezet hatékonyabb ütemezővel rendelkezik. Ugyanazt az I/O szálkészletet használja, amelyet a WCF-hez használnak, ami nagyon hatékony a kötegelt munkaelemek végrehajtásában. A belső munkaelem-ütemező üzenetsor a leggyakoribb használati mintákhoz van optimalizálva. A WF4-futtatókörnyezet emellett nagyon egyszerű módon kezeli a végrehajtási állapotokat minimális szinkronizálási és eseménykezelési logikával, míg a WF3 nagy súlyú eseményregisztrációtól és meghívástól függ az állapotáttűnés összetett szinkronizálásának végrehajtásához.

Adattárolás és -folyamat

A WF3-ban a tevékenységhez társított adatok modellezése a típus DependencyPropertyáltal implementált függőségi tulajdonságokon keresztül történik. A függőségi tulajdonságminta a Windows megjelenítési alaprendszer (WPF) szolgáltatásban lett bevezetve. Ez a minta általában nagyon rugalmas az egyszerű adatkötés és más felhasználói felületi funkciók támogatásához. A minta azonban megköveteli, hogy a tulajdonságok statikus mezőkként legyenek definiálva a munkafolyamat-definícióban. Amikor a WF-futtatókörnyezet beállítja vagy lekéri a tulajdonságértékeket, az erősen súlyozott keresési logikával jár.

A WF4 világos adatkezelési logikát használ az adatok munkafolyamatban való kezelésének nagyban javítására. A tevékenységben tárolt adatokat két különböző fogalom, változó és argumentum használatával választja el a tevékenységhatárokon áthaladó adatoktól. A változók és az "In/Out/InOut" argumentumok egyértelmű hierarchikus hatókörének használatával a tevékenységek adathasználati összetettsége jelentősen csökken, és az adatok élettartama is automatikusan kiterjed. A tevékenységek argumentumai jól definiált aláírással rendelkeznek. Egy tevékenység vizsgálatával meghatározhatja, hogy milyen adatokat vár el, és milyen adatokat állít elő a végrehajtás eredményeként.

A WF3-tevékenységek inicializálása munkafolyamat létrehozásakor történt. A WF 4-ben a tevékenységek csak a megfelelő tevékenységek végrehajtásakor inicializálódnak. Ez egyszerűbb tevékenység-életciklust tesz lehetővé inicializálási/uninitializálási műveletek végrehajtása nélkül egy új munkafolyamat-példány létrehozásakor, így nagyobb hatékonyságot ért el

Átvitelvezérlés

Ahogy minden programozási nyelvben, a WF is támogatja a munkafolyamat-definíciók vezérlési folyamatait, mivel bemutatja a vezérlőfolyamat-tevékenységeket a szekvenáláshoz, a hurkokhoz, az elágaztatáshoz és más mintákhoz. A WF3-ban, amikor ugyanazt a tevékenységet újra kell végrehajtani, létrejön egy új ActivityExecutionContext , és a tevékenység klónozása egy nagy súlyú szerializálási és deszerializálási logika alapján BinaryFormattertörténik. Az iteratív vezérlési folyamatok teljesítménye általában sokkal lassabb, mint a tevékenységek sorozatának végrehajtása.

A WF4 ezt egészen másképp kezeli. Felveszi a tevékenységsablont, létrehoz egy új ActivityInstance-objektumot, és hozzáadja az ütemező üzenetsorához. Ez az egész folyamat csak explicit objektumlétrehozással jár, és nagyon egyszerű.

Aszinkron programozás

Az alkalmazások általában jobb teljesítményt és méretezhetőséget biztosítanak az aszinkron programozással a hosszú ideig futó blokkoló műveletekhez, például az I/O-hoz vagy az elosztott számítási műveletekhez. A WF4 aszinkron támogatást biztosít az alaptevékenység-típusokon AsyncCodeActivitykeresztül. AsyncCodeActivity<TResult> A futtatókörnyezet natív módon értelmezi az aszinkron tevékenységeket, ezért automatikusan nem állandó zónába helyezheti a példányt, miközben az aszinkron munka ki van kapcsolva. Az ilyen típusú egyéni tevékenységek aszinkron munkát végezhetnek a munkafolyamat-ütemező szál megtartása nélkül, és blokkolhatják azokat a tevékenységeket, amelyek párhuzamosan futtathatók.

Üzenetkezelés

A WF3 kezdetben nagyon korlátozott üzenetkezelési támogatást nyújtott külső események vagy webszolgáltatások meghívása révén. A .NET-keretrendszer 3.5-ben a munkafolyamatok WCF-ügyfelekként implementálhatók, vagy WCF-szolgáltatásként is elérhetők a következő módonSendActivity: és ReceiveActivity. A WF4-ben a WCF üzenetkezelési logikájának a WF-be való szoros integrálásával tovább erősödött a munkafolyamat-alapú üzenetkezelési programozás fogalma.

A WCF-ben a .NET 4-ben biztosított egyesített üzenetfeldolgozási folyamat segítségével a WF4-szolgáltatások jelentősen jobb teljesítményt és méretezhetőséget biztosítanak, mint a WF3. A WF4 emellett gazdagabb üzenetkezelési programozási támogatást is biztosít, amely összetett üzenetcsere-mintákat (MEP-ket) modellezhet. A fejlesztők gépelt szolgáltatási szerződéseket is használhatnak az egyszerű programozáshoz vagy a nem gépelt szolgáltatási szerződésekhez, hogy a szerializálási költségek megfizetése nélkül jobb teljesítményt érjenek el. Az ügyféloldali csatorna gyorsítótárazási támogatása a SendMessageChannelCache WF4 osztályán keresztül segít a fejlesztőknek gyors alkalmazások létrehozásában, minimális erőfeszítéssel. További információ: A küldési tevékenységek gyorsítótármegosztási szintjeinek módosítása.

Deklaratív programozás

A WF4 tiszta és egyszerű deklaratív programozási keretrendszert biztosít az üzleti folyamatok és szolgáltatások modellezéséhez. A programozási modell támogatja a tevékenységek teljes deklaratív összetételét, kód nélkül, jelentősen leegyszerűsítve a munkafolyamat-létrehozást. A 4. .NET-keretrendszer az XAML-alapú deklaratív programozási keretrendszert egyesítette az egységes szerelvény-System.Xaml.dll a WPF és a WF támogatásához.

A WF4-ben az XAML valóban deklaratív élményt nyújt, és lehetővé teszi a munkafolyamat teljes definíciójának meghatározását XML-korrektúrában, hivatkozva a .NET használatával létrehozott tevékenységekre és típusokra. Ezt A WF3-ban XOML formátumban nehéz volt elvégezni anélkül, hogy egyéni kód mögötti logikát vontak be. A .NET 4-ben az új XAML-verem sokkal jobb teljesítményt nyújt a munkafolyamat-összetevők szerializálásában/deszerializálásában, és vonzóbbá és szilárdabbá teszi a deklaratív programozást.

Munkafolyamat-Tervező

A WF4 teljes deklaratív programozási támogatása kifejezetten magasabb követelményeket támaszt a nagy munkafolyamatok tervezési idejének teljesítményével szemben. A WF4 munkafolyamat-tervezője sokkal jobb méretezhetőséget biztosít a nagy munkafolyamatok esetében, mint a WF3 esetében. A felhasználói felület virtualizálásának támogatásával a tervező néhány másodperc alatt egyszerűen betölthet egy 1000 tevékenységből álló nagy munkafolyamatot, míg a WF3-tervezővel szinte lehetetlen betölteni néhány száz tevékenységből álló munkafolyamatot.

Összetevőszintű teljesítmény-összehasonlítások

Ez a szakasz a WF3- és WF4-munkafolyamatok egyes tevékenységeinek közvetlen összehasonlítására vonatkozó adatokat tartalmazza. Az olyan kulcsfontosságú területek, mint a megőrzés, mélyebb hatással vannak a teljesítményre, mint az egyes tevékenységösszetevőkre. A WF4 egyes összetevőinek teljesítménybeli fejlesztései azért fontosak, mert az összetevők már elég gyorsak ahhoz, hogy összehasonlíthatók legyenek a kézzel kódolt vezénylési logikával. Példa erre a következő szakaszban: "Szolgáltatásösszetételi forgatókönyv".

A környezet beállítása

A fenti ábra az összetevőszintű teljesítményméréshez használt gépkonfigurációt mutatja be. Egyetlen kiszolgáló és öt ügyfél csatlakozik egy 1 Gb/s-os Ethernet hálózati adapteren keresztül. Az egyszerű mérések érdekében a kiszolgáló úgy van konfigurálva, hogy a Windows Server 2008 x86 rendszert futtató két-proc/négymagos kiszolgáló egyetlen magját használja. A rendszer CPU-kihasználtsága közel 100%.

Teszt részletei

A WF3 valószínűleg a WF3 CodeActivity munkafolyamatban használható legegyszerűbb tevékenység. A tevékenység meghív egy metódust a kód mögött, amelybe a munkafolyamat-programozó egyéni kódot helyezhet el. A WF4-ben nincs közvetlen analógja a WF3-nak CodeActivity , amely ugyanazt a funkciót biztosítja. Vegye figyelembe, hogy a WF4-ben van egy CodeActivity alaposztály, amely nem kapcsolódik a WF3-hoz CodeActivity. A munkafolyamat-szerzőknek egyéni tevékenységeket kell létrehozniuk, és csak XAML-munkafolyamatokat kell létrehozniuk. Az alábbi tesztekben a rendszer egy meghívott Comment tevékenységet használ egy üres CodeActivity WF4-munkafolyamat helyett. A tevékenységben szereplő Comment kód a következő:

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

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

        protected override void Execute(CodeActivityContext context)
        {
        }
    }

Üres munkafolyamat

Ez a teszt gyermektevékenységek nélküli szekvencia-munkafolyamatot használ.

Egyetlen tevékenység

A munkafolyamat egy gyermektevékenységet tartalmazó szekvencia-munkafolyamat. A tevékenység egy CodeActivity kód nélküli WF3-eset, és egy Comment tevékenység a WF4-es esetben.

Míg 1000 iterációval

A szekvencia-munkafolyamat egy While olyan tevékenységet tartalmaz, amely egyetlen gyermektevékenységet tartalmaz a ciklusban, amely nem végez semmilyen munkát.

Replikátor a ParallelForEachhoz képest

ReplicatorActivity A WF3-ban szekvenciális és párhuzamos végrehajtási módokkal rendelkezik. Szekvenciális módban a tevékenység teljesítménye hasonló a WhileActivity. A ReplicatorActivity párhuzamos végrehajtáshoz ez a leg hasznosabb. Ehhez a WF4 analógja a ParallelForEach<T> tevékenység.

Az alábbi ábra a teszthez használt munkafolyamatokat mutatja be. A WF3 munkafolyamat a bal oldalon, a WF4 munkafolyamat pedig a jobb oldalon található.

Szekvenciális munkafolyamat öt tevékenységgel

Ennek a tesztnek az a célja, hogy bemutassa, milyen hatással van több tevékenység egymás után történő végrehajtására. A sorrendben öt tevékenység szerepel.

Tranzakció hatóköre

A tranzakció hatókörének tesztelése némileg eltér a többi teszttől, mivel nem minden iterációhoz hoz létre új munkafolyamat-példányt. Ehelyett a munkafolyamat egy olyan ciklussal van strukturálva, amely egy TransactionScope olyan tevékenységet tartalmaz, amely egyetlen tevékenységet tartalmaz, amely nem működik. Egy 50 iterációból álló köteg minden egyes futtatása a cikluson keresztül egyetlen műveletnek számít.

Kompenzáció

A WF3 munkafolyamatnak egyetlen kompenzálható tevékenység neve van WorkScope. A tevékenység egyszerűen megvalósítja a ICompensatableActivity felületet:

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

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

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

A hibakezelő a WorkScope tevékenységet célozza. A WF4-munkafolyamat ugyanilyen egyszerű. A CompensableActivity teste és kompenzációs kezelője van. A sorrendben egy explicit kompenzálás következik. A törzstevékenység és a kompenzációkezelő tevékenység egyaránt üres megvalósítás:

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) { }
    }

Az alábbi ábra az alapszintű kompenzációs munkafolyamatot mutatja be. A WF3 munkafolyamat a bal oldalon, a WF4 munkafolyamat pedig a jobb oldalon található.

Teljesítményteszt eredményei

Az összes teszt másodpercenkénti munkafolyamatokban van mérve, a tranzakció hatókörének tesztelése kivételével. Ahogy fent látható, a WF futtatókörnyezet teljesítménye javult az egész táblán, különösen azokban a területeken, amelyek több végrehajtást igényelnek ugyanahhoz a tevékenységhez, mint a ciklus.

Szolgáltatásösszetételi forgatókönyv

Ahogy az előző, "Komponensszintű teljesítmény-összehasonlítások" című szakaszban is látható, a WF3 és a WF4 közötti többletterhelés jelentősen csökkent. A WCF munkafolyamat-szolgáltatásai mostantól szinte megegyeznek a kézzel kódolt WCF-szolgáltatások teljesítményével, de továbbra is a WF-futtatókörnyezet minden előnyével rendelkeznek. Ez a tesztforgatókönyv összehasonlít egy WCF-szolgáltatást egy WCF munkafolyamat-szolgáltatással a WF4-ben.

Online áruház szolgáltatás

A Windows Workflow Foundation egyik erőssége, hogy több szolgáltatás használatával is képes folyamatokat írni. Ebben a példában létezik egy online áruházbeli szolgáltatás, amely két szolgáltatáshívást vezényel egy megrendelés megvásárlásához. Az első lépés a megrendelés ellenőrzése egy rendelés-érvényesítési szolgáltatással. A második lépés a megrendelés warehouse service használatával történő kitöltése.

A két háttérszolgáltatás, az Order Validating Service és a Warehouse Service változatlan marad mindkét teszt esetében. A módosítás része a vezénylést végrehajtó Online Áruház szolgáltatás. Egy esetben a szolgáltatás kézzel kódolt WCF-szolgáltatásként. A másik esetben a szolgáltatás WCF munkafolyamat-szolgáltatásként van megírva a WF4-ben. A WF-specifikus funkciók, például a nyomon követés és az adatmegőrzés ki vannak kapcsolva ehhez a teszthez.

Környezet

Az ügyfélkérelmek több számítógépről HTTP-en keresztül kerülnek az Online Áruház szolgáltatásba. Egyetlen számítógép üzemelteti mindhárom szolgáltatást. Az Online Áruház szolgáltatás és a háttérszolgáltatások közötti átviteli réteg TCP vagy HTTP. A műveletek/másodpercek mérése az Online Áruház szolgáltatásba irányuló befejezett PurchaseOrder hívások számán alapul. A csatornakészletezés egy új funkció, amely a WF4-ben érhető el. A WCF-ben a tesztcsatorna készletezése nem érhető el a dobozból, így egy egyszerű készletezési technika kézzel kódolt implementációját használták az Online Áruház szolgáltatásban.

Teljesítmény

Csatlakozás háttérbeli TCP-szolgáltatásokhoz csatornakészletezés nélkül, a WF szolgáltatás 17,2%-os hatással van az átviteli sebességre. A csatornakészletezés esetén a büntetés körülbelül 23,8%. HTTP esetén a hatás sokkal kisebb: 4,3% készletezés nélkül, 8,1% készletezéssel. Azt is fontos megjegyezni, hogy a csatornakészletezés nagyon kevés előnyt biztosít a HTTP használatakor.

Bár ebben a tesztben a WF4-futtatókörnyezet többletterhelést jelent egy kézzel kódolt WCF-szolgáltatáshoz képest, ez a legrosszabb esetnek tekinthető. A teszt két háttérszolgáltatása nagyon kevés munkát végez. Egy valós, teljes körű forgatókönyvben ezek a szolgáltatások drágább műveleteket, például adatbázis-hívásokat hajtanak végre, ami kevésbé fontossá teszi az átviteli réteg teljesítményre gyakorolt hatását. Ez és a WF4-ben elérhető funkciók előnyei révén a Workflow Foundation használható választás a vezénylési szolgáltatások létrehozásához.

Főbb teljesítménybeli szempontok

A szakasz funkcióterületei az interop kivételével jelentősen megváltoztak a WF3 és a WF4 között. Ez hatással van a munkafolyamat-alkalmazások tervezésére és a teljesítményre.

Munkafolyamat-aktiválás késése

A WCF munkafolyamat-szolgáltatásalkalmazásokban fontos az új munkafolyamat indításának vagy egy meglévő munkafolyamat betöltésének késése, mivel ez blokkolható. Ez a teszteset egy WF3 XOML-gazdagépet mér egy WF4 XAMLX-gazdagépen egy tipikus forgatókönyvben.

A környezet beállítása

Tesztbeállítás

Ebben a forgatókönyvben az ügyfélszámítógép környezetalapú korreláció használatával kapcsolatba lép egy WCF munkafolyamat-szolgáltatással. A környezeti korreláció speciális környezeti kötést igényel, és egy környezeti fejlécet vagy cookie-t használ az üzenetek megfelelő munkafolyamat-példányhoz való kapcsolásához. Teljesítménybeli előnye, hogy a korrelációs azonosító az üzenet fejlécében található, így az üzenet törzsét nem kell elemezni.

A szolgáltatás létrehoz egy új munkafolyamatot a kéréssel, és azonnali választ küld, hogy a késés mérése ne foglalja magában a munkafolyamat futtatásával töltött időt. A WF3-munkafolyamat XOML,mögöttes kóddal, a WF4-munkafolyamat pedig teljes egészében XAML. A WF4-munkafolyamat a következőképpen néz ki:

A Receive tevékenység létrehozza a munkafolyamat-példányt. A kapott üzenetben átadott érték visszhangzik a válaszüzenetben. A választ követő sorozat tartalmazza a munkafolyamat többi részét. A fenti esetben csak egy megjegyzéstevékenység jelenik meg. A megjegyzéstevékenységek száma módosul a munkafolyamat összetettségének szimulálásához. A megjegyzéstevékenység egyenértékű egy olyan WF3-sal CodeActivity , amely nem végez munkát. A megjegyzési tevékenységről a cikk korábbi, "Komponensszintű teljesítmény-összehasonlítás" című szakaszában olvashat bővebben.

A teszt eredményei

Hideg és meleg késés a WCF munkafolyamat-szolgáltatások esetében:

Az előző diagramban a hideg azokra az esetekre vonatkozik, ahol nincs meglévő WorkflowServiceHost az adott munkafolyamathoz. Más szóval a hideg késés az, amikor a munkafolyamatot első alkalommal használják, és a XOML-et vagy az XAML-t kell lefordítani. A meleg késés az új munkafolyamat-példány létrehozásához szükséges idő, amikor a munkafolyamat-típus már elkészült. A munkafolyamat összetettsége nagyon kis különbséget tesz a WF4-es esetben, de lineáris progresszióval rendelkezik a WF3-esetben.

Korrelációs átviteli sebesség

A WF4 új tartalomalapú korrelációs funkciót vezet be. A WF3 csak kontextusalapú korrelációt biztosított. A környezetalapú korrelációt csak meghatározott WCF-csatornakötésekkel lehetett elvégezni. A munkafolyamat-azonosító a kötések használatakor be lesz szúrva az üzenet fejlécébe. A WF3-futtatókörnyezet csak az azonosítója alapján tudott azonosítani egy munkafolyamatot. A tartalomalapú korrelációval a munkafolyamat szerzője létrehozhat egy korrelációs kulcsot egy releváns adatból, például egy fiókszámból vagy egy ügyfélazonosítóból.

A környezetalapú korreláció teljesítménybeli előnye, hogy a korrelációs kulcs az üzenet fejlécében található. A kulcs szerializálás/üzenetmásolás nélkül is olvasható az üzenetből. A tartalomalapú korrelációban a korrelációs kulcs az üzenet törzsében lesz tárolva. A kulcs megkereséséhez XPath-kifejezés használható. A további feldolgozás költsége az üzenet méretétől, a törzsben lévő kulcs mélységétől és a kulcsok számától függ. Ez a teszt összehasonlítja a környezet- és tartalomalapú korrelációt, és több kulcs használata esetén a teljesítmény romlását is mutatja.

A környezet beállítása

Tesztbeállítás

Az előző munkafolyamat ugyanaz, mint a Perzisztencia szakaszban. Az állandóság nélküli korrelációs tesztekhez nincs telepítve adatmegőrzési szolgáltató a futtatókörnyezetben. A korreláció két helyen fordul elő: CreateOrder és CompleteOrder.

A teszt eredményei

Ez a grafikon a tartalomalapú korrelációban használt kulcsok számának növekedésével a teljesítmény csökkenését mutatja. A TCP és a HTTP közötti görbék hasonlósága jelzi az ezekhez a protokollokhoz kapcsolódó többletterhelést.

Korreláció az adatmegőrzéssel

A tartós munkafolyamatok során a tartalomalapú korreláció processzorterhelése a munkafolyamat-futtatókörnyezetről az SQL-adatbázisra változik. Az SQL-adatmegőrzési szolgáltató tárolt eljárásai végzik a kulcsok egyeztetését a megfelelő munkafolyamat megkereséséhez.

A környezetalapú korreláció még mindig gyorsabb, mint a tartalomalapú korreláció. A különbség azonban kevésbé kifejezett, mivel a tartósság nagyobb hatással van a teljesítményre, mint a korrelációra.

Összetett munkafolyamat-átviteli sebesség

A munkafolyamat összetettségét nem csak a tevékenységek száma méri. Az összetett tevékenységek sok gyermeket tartalmazhatnak, és ezek a gyermekek összetett tevékenységek is lehetnek. Ahogy nő a beágyazási szintek száma, úgy nő a jelenleg végrehajtási állapotban lévő tevékenységek száma és az állapotban lévő változók száma is. Ez a teszt összehasonlítja a WF3 és a WF4 közötti átviteli sebességet összetett munkafolyamatok végrehajtásakor.

Tesztbeállítás

Ezeket a teszteket egy Intel Xeon X5355 @ 2,66 GHz 4-es, 4 GB RAM-mal rendelkező, Windows Server 2008 x64 rendszerű számítógépen hajtották végre. A tesztkód egyetlen folyamatban fut, magonként egy szállal, hogy elérje a 100%-os processzorkihasználtságot.

A teszthez létrehozott munkafolyamatoknak két fő változójuk van: az egyes sorozatokban lévő tevékenységek mélysége és száma. Minden mélységi szint tartalmaz egy párhuzamos tevékenységet, míg a hurkokat, döntéseket, hozzárendeléseket és sorozatokat. Az alábbi képen látható WF4-tervezőben a felső szintű folyamatábra látható. Minden folyamatábra-tevékenység a fő folyamatábrahoz hasonlít. Hasznos lehet fraktálra gondolni a munkafolyamat képi megjelenítésekor, ahol a mélység a teszt paramétereire korlátozódik.

Az adott teszt tevékenységeinek számát a tevékenységek mélysége és sorozatonkénti száma határozza meg. Az alábbi egyenlet kiszámítja a WF4-teszt tevékenységeinek számát:

A WF3-teszt tevékenységszáma egy kissé eltérő egyenlettel számítható ki egy extra sorozat miatt:

Ahol d a mélység, és a a tevékenységek száma sorozatonként. Az egyenletek mögött az a logika áll, hogy az első állandó szorozva a sorozatok száma, a második állandó pedig az aktuális szinten lévő tevékenységek statikus száma. Minden folyamatábra három folyamatábra gyermektevékenységet tartalmaz. Az alsó mélységi szinten ezek a folyamatábraok üresek, a többi szinten azonban a fő folyamatábra másolatai. Az egyes tesztváltozatok munkafolyamat-definíciójában szereplő tevékenységek száma az alábbi táblázatban látható:

A munkafolyamat-definíció tevékenységeinek száma az egyes mélységi szinteknél jelentősen nő. Döntési pontonként azonban csak egy elérési út lesz végrehajtva egy adott munkafolyamat-példányban, így a tényleges tevékenységeknek csak egy kis része lesz végrehajtva.

Ezzel egyenértékű munkafolyamat lett létrehozva a WF3-hoz. A WF3 tervező a teljes munkafolyamatot a tervezési területen jeleníti meg beágyazás helyett, ezért túl nagy ahhoz, hogy megjelenjen ebben a témakörben. A munkafolyamat kódrészlete alább látható.

A beágyazás szélsőséges esetben történő gyakorlásához egy másik, a teszt részét képező munkafolyamat 100 beágyazott sorozatot használ. A legbelső sorrendben egyetlen Comment vagy CodeActivity.

A nyomon követés és a megőrzés nem szerepel a tesztben.

A teszt eredményei

Még a sok mélységű és sok tevékenységgel rendelkező összetett munkafolyamatok esetében is a teljesítményeredmények összhangban vannak a cikkben korábban bemutatott egyéb átviteli sebességekkel. A WF4 átviteli sebessége nagyságrendekkel gyorsabb, és logaritmikus skálán kell összehasonlítani.

Memory (Memória)

A Windows Workflow Foundation memóriaterhelését két fő területen mérik: a munkafolyamat összetettségét és a munkafolyamat-definíciók számát. Memóriaméréseket végeztek egy Windows 7 64 bites munkaállomáson. A munkakészlet méretének mérésére számos módon van lehetőség, például a teljesítményszámlálók figyelésére, a Environment.WorkingSet lekérdezésére, vagy a VMMap-ból elérhető VMMap eszköz használatára. Az egyes tesztek eredményeinek lekéréséhez és ellenőrzéséhez módszerek kombinációját használták.

Munkafolyamat összetettségi tesztje

A munkafolyamat összetettségi tesztje a munkafolyamat összetettsége alapján méri a munkakészlet különbségét. Az előző szakaszban használt összetett munkafolyamatok mellett az új változatok két alapvető esetet fednek le: egyetlen tevékenység-munkafolyamatot és egy 1000 tevékenységet tartalmazó sorozatot. Ezekhez a tesztekhez a munkafolyamatok inicializálása és végrehajtása egyetlen soros ciklusban történik egy percen át. Minden tesztváltozatot háromszor futtatunk, a rögzített adatok pedig a három futtatás átlagát.

A két új alapteszt munkafolyamatai az alábbiakhoz hasonlóan néznek ki:

A fent látható WF3 munkafolyamatban üres CodeActivity tevékenységeket használ a rendszer. A fenti WF4-munkafolyamat tevékenységeket használ Comment . A Comment tevékenységet a cikk korábbi, összetevőszintű teljesítmény-összehasonlítási szakaszában ismertette.

A gráfban látható egyik egyértelmű trend az, hogy a beágyazás viszonylag minimális hatással van a WF3 és a WF4 memóriahasználatára. A legfontosabb memóriahatás az adott munkafolyamatban végzett tevékenységek számából ered. Tekintettel az 1000-es sorozat adataira, az 5. komplex mélységi sorozat 5. sorozatára és az összetett mélység 7 sorozat 1 változatára, nyilvánvaló, hogy a tevékenységek száma az ezrekbe kerül, a memóriahasználat növekedése észrevehetőbbé válik. A szélsőséges esetben (mélység 7 sorozat 1), ahol van ~29K tevékenységek, WF4 használ majdnem 79%-kal kevesebb memóriát, mint A WF3.

Több munkafolyamat-definíciós teszt

A munkafolyamat-definíciónkénti memória mérése két különböző tesztre oszlik, mivel a WF3-ban és a WF4-ben a munkafolyamatok üzemeltetéséhez rendelkezésre álló lehetőségek állnak rendelkezésre. A tesztek a munkafolyamat összetettségi tesztjétől eltérő módon futnak, mivel egy adott munkafolyamat példánya és végrehajtása definíciónként csak egyszer történik meg. Ennek az az oka, hogy a munkafolyamat-definíció és a gazdagép az AppDomain teljes élettartama alatt a memóriában marad. Az adott munkafolyamat-példány futtatásához használt memóriát a szemétgyűjtés során ki kell tisztítani. A WF4 migrálási útmutatója részletesebb információkat tartalmaz az üzemeltetési lehetőségekről. További információ: WF Migration Cookbook: Workflow Hosting.

A munkafolyamat-definíciós teszthez számos munkafolyamat-definíció létrehozása többféleképpen is elvégezhető. Például kódgenerálással létrehozhat egy 1000 munkafolyamatot, amelyek a név kivételével azonosak, és ezeket a munkafolyamatokat külön fájlokba mentik. Ez a módszer a konzol által üzemeltetett teszthez készült. A WF3-ban az WorkflowRuntime osztályt használták a munkafolyamat-definíciók futtatásához. A WF4 WorkflowApplication használhatja egyetlen munkafolyamat-példány létrehozására, vagy közvetlenül a WorkflowInvoker tevékenység futtatására, mintha metódushívás lenne. WorkflowApplication egyetlen munkafolyamat-példány gazdagépe, és a funkció paritása WorkflowRuntime közelebb van ehhez a teszthez.

Amikor munkafolyamatokat üzemeltet az IIS-ben, az összes XAMLX- vagy XOML-fájl létrehozása helyett egy újat WorkflowServiceHost hozhat VirtualPathProvider létre. A VirtualPathProvider rendszer kezeli a bejövő kérést, és egy "virtuális fájllal" válaszol, amely betölthető egy adatbázisból, vagy ebben az esetben menet közben generálható. Ezért nem szükséges 1000 fizikai fájlt létrehozni.

A konzoltesztben használt munkafolyamat-definíciók egyszerű szekvenciális munkafolyamatok voltak egyetlen tevékenységgel. Az egyetlen tevékenység üres CodeActivity volt a WF3-esethez és a Comment WF4-esethez. Az IIS által üzemeltetett eset olyan munkafolyamatokat használt, amelyek egy üzenet fogadásával kezdődnek, és a válasz elküldésével fejeződnek be:

Az alábbi képen egy WF3-munkafolyamat látható a ReceiveActivity és egy WF4-munkafolyamat kérés-válasz mintával:

Az alábbi táblázat egy munkafolyamat-definíció és 1001 definíció közötti munkakészlet változását mutatja be:

Üzemeltetési beállítások	WF3 munkakészlet delta	WF4 munkakészlet delta
Konzolalkalmazás által üzemeltetett munkafolyamatok	18 MB	9 MB
IIS által üzemeltetett munkafolyamat-szolgáltatások	446 MB	364 MB

A munkafolyamat-definíciók IIS-ben való üzemeltetése sokkal több memóriát használ fel a WorkflowServiceHostrészletes WCF szolgáltatásösszetevők és a gazdagéphez társított üzenetfeldolgozási logika miatt.

A WF3-ban történő konzolüzemeltetés esetében a munkafolyamatok XOML helyett kódban lettek implementálva. A WF4-ben az alapértelmezett az XAML használata. Az XAML beágyazott erőforrásként van tárolva a szerelvényben, és futásidőben lesz lefordítva, hogy biztosítsa a munkafolyamat megvalósítását. Ez a folyamat némi többletterhelést jelent. A WF3 és a WF4 közötti tisztességes összehasonlítás érdekében az XAML helyett kódolt munkafolyamatokat használtunk. A WF4-munkafolyamatok egyikére az alábbiakban talál példát:

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

Sok más tényező is befolyásolhatja a memóriahasználatot. Ugyanez a tanács az összes felügyelt program esetében is érvényes. Az IIS által üzemeltetett környezetekben a WorkflowServiceHost munkafolyamat-definícióhoz létrehozott objektum a memóriában marad, amíg az alkalmazáskészletet újra nem hasznosítják. Ezt figyelembe kell venni a bővítmények írásakor. Emellett érdemes elkerülni a "globális" változókat (a teljes munkafolyamatra kiterjedő változókat), és lehetőség szerint korlátozni a változók hatókörét.

Munkafolyamat-futtatókörnyezeti szolgáltatások

Kitartás

A WF3 és a WF4 is SQL-adatmegőrzési szolgáltatóval szállít. A WF3 SQL-adatmegőrzési szolgáltató egy egyszerű implementáció, amely szerializálja a munkafolyamat-példányt, és blobban tárolja. Emiatt a szolgáltató teljesítménye nagymértékben függ a munkafolyamat-példány méretétől. A WF3-ban a példány mérete több okból is növekedhet, ahogy azt a jelen tanulmány korábban is tárgyalta. Sok ügyfél úgy dönt, hogy nem használja az alapértelmezett SQL-adatmegőrzési szolgáltatót, mert a szerializált példányok adatbázisban való tárolása nem biztosít betekintést a munkafolyamat állapotába. Ahhoz, hogy egy adott munkafolyamatot a munkafolyamat-azonosító ismerete nélkül találhasson meg, deszerializálnia kell az egyes fenntartott példányokat, és meg kell vizsgálnia a tartalmat. Sok fejlesztő inkább saját adatmegőrzési szolgáltatókat ír, hogy leküzdje ezt az akadályt.

A WF4 SQL-adatmegőrzési szolgáltató megpróbálta kezelni néhány ilyen problémát. A perzisztenciatáblák bizonyos információkat, például az aktív könyvjelzőket és a promóciós táblák tulajdonságait teszik elérhetővé. A WF4 új tartalomalapú korrelációs funkciója nem teljesít jól a WF3 SQL-adatmegőrzési megközelítéssel, ami némi változást váltott ki a munkafolyamat-példány szervezetében. Ez összetettebbé teszi a adatmegőrzési szolgáltató feladatát, és további stresszt helyez az adatbázisra.

A környezet beállítása

Tesztbeállítás

A továbbfejlesztett funkciókészlet és az egyidejűség jobb kezelése mellett is a WF4 SQL-adatmegőrzési szolgáltatója gyorsabb, mint a WF3 szolgáltatója. Ennek bemutatásához az alábbiakban két munkafolyamatot hasonlítunk össze, amelyek lényegében ugyanazokat a műveleteket hajtják végre a WF3-ban és a WF4-ben.

A két munkafolyamatot egy fogadott üzenet hozza létre. A kezdeti válasz elküldése után a munkafolyamat megmarad. A WF3-esetben a rendszer egy üres értéket TransactionScopeActivity használ az adatmegőrzés elindításához. Ugyanezt a WF3-ban is el lehet érni úgy, hogy egy tevékenységet "bezárt állapotúként" jelöl meg. Egy második, korrelált üzenet befejezi a munkafolyamatot. A munkafolyamatok megmaradnak, de nincsenek kiürítve.

A teszt eredményei

Ha az ügyfél és a középső réteg közötti átvitel HTTP, a WF4-ben való megőrzés 2,6-szoros javulást mutat. A TCP-átvitel ezt a tényezőt 3,0-ra növeli. A középső réteg processzorkihasználtsága minden esetben 98%-os vagy magasabb. A WF4 átviteli sebességének oka a gyorsabb munkafolyamat-futtatókörnyezet. A szerializált példány mérete mindkét esetben alacsony, és ebben a helyzetben nem jelentős tényező.

A teszt WF3- és WF4-munkafolyamatai is egy tevékenység használatával jelzik, hogy mikor kell állandósulni. Ennek az az előnye, hogy a munkafolyamatot anélkül őrizheti meg, hogy nem távolítja el. A WF3-ban a funkció használatával TimeToUnload is megőrizhető, de ez eltávolítja a munkafolyamat-példányt a memóriából. Ha a WF3-at használó fejlesztő meg szeretné győződni arról, hogy egy munkafolyamat bizonyos pontokon megmarad, akkor vagy módosítania kell a munkafolyamat definícióját, vagy meg kell fizetnie a munkafolyamat-példány kiürítési és újrabetöltési költségeit. A WF4 új funkciója lehetővé teszi, hogy eltávolítás nélkül is megmaradjon: TimeToPersist. Ez a funkció lehetővé teszi, hogy a munkafolyamat-példány tétlen állapotban maradjon, de maradjon a memóriában, amíg el nem éri a TimeToUnload küszöbértéket, vagy a végrehajtás folytatódik.

Vegye figyelembe, hogy a WF4 SQL-adatmegőrzési szolgáltató több munkát végez az adatbázisszinten. Az SQL-adatbázis szűk keresztmetszetet jelenthet, ezért fontos figyelni a processzor- és lemezhasználatot. A munkafolyamat-alkalmazások teljesítménytesztelése során mindenképpen vegye fel a következő teljesítményszámlálókat az SQL-adatbázisból:

• PhysicalDisk\%Disk olvasási ideje

• PhysicalDisk\% Lemezidő

• PhysicalDisk\% Lemez írási ideje

• PhysicalDisk\% Avg. Lemezsor hossza

• PhysicalDisk\Avg. Lemez olvasási üzenetsorának hossza

• PhysicalDisk\Avg. Lemez írási üzenetsorának hossza

• PhysicalDisk\Current Disk Queue Length

• Processzoradatok\Processzorhasználati idő százalékos aránya

• SQLServer:Latches\Átlagos retesz várakozási idő (ms)

• SQLServer:Latches\Latch Waits/sec

Nyomon követés

A munkafolyamat-nyomon követés a munkafolyamat előrehaladásának nyomon követésére használható. A nyomkövetési eseményekben szereplő információkat egy nyomkövetési profil határozza meg. Minél összetettebb a nyomkövetési profil, annál drágább lesz a nyomon követés.

A WF3 sql-alapú nyomkövetési szolgáltatással szállítva. Ez a szolgáltatás kötegelt és nem kötegelt módban is működhet. Nem kötegelt módban a nyomkövetési események közvetlenül az adatbázisba lesznek írva. Kötegelt módban a rendszer a nyomkövetési eseményeket ugyanabba a kötegbe gyűjti, mint a munkafolyamat-példány állapota. A kötegelt mód a munkafolyamat-kialakítások legszélesebb köréhez a legjobb teljesítményt nyújtja. A kötegelés azonban negatív hatással lehet a teljesítményre, ha a munkafolyamat számos tevékenységet futtat anélkül, hogy megőrizte volna, és ezeket a tevékenységeket nyomon követik. Ez általában hurkokban fordul elő, és ennek a forgatókönyvnek a legjobb módja, ha nagy hurkokat tervez, amelyek egy adatmegőrzési pontot tartalmaznak. A perzisztenciapont hurkokba való bevezetése negatív hatással lehet a teljesítményre is, ezért fontos az egyes pontok költségeinek mérése és az egyenleg létrehozása.

A WF4-et nem sql-követési szolgáltatással szállítjuk. Az SQL-adatbázis nyomkövetési adatainak rögzítése az alkalmazáskiszolgálókról jobban kezelhető, nem pedig a .NET-keretrendszer. Ezért az SQL-nyomkövetést mostantól az AppFabric kezeli. A WF4 beépített nyomkövetési szolgáltatója a Windows eseménykövetésén (ETW) alapul.

Az ETW egy kernelszintű, alacsony késésű eseményrendszer, amely a Windowsba van beépítve. Olyan szolgáltatói/fogyasztói modellt használ, amely lehetővé teszi, hogy csak akkor merüljön fel az eseménykövetés büntetése, ha ténylegesen fogyasztó van. Az olyan kernelesemények mellett, mint a processzor, a lemez, a memória és a hálózathasználat, számos alkalmazás használja az ETW-t is. Az ETW-események hatékonyabbak, mint a teljesítményszámlálók, mivel az események testre szabhatók az alkalmazáshoz. Az események tartalmazhatnak szöveget, például munkafolyamat-azonosítót vagy tájékoztató üzenetet. Emellett az események bitmaszkokkal vannak kategorizálva, így az események egy bizonyos részhalmazának felhasználása kevésbé lesz hatással a teljesítményre, mint az összes esemény rögzítése.

Az ETW sql helyetti követésére való használatának előnyei a következők:

• A nyomon követési események gyűjteménye különválasztható egy másik folyamathoz. Ez nagyobb rugalmasságot biztosít az események rögzítésében.

• Az ETW-nyomkövetési események egyszerűen kombinálhatók a WCF ETW-eseményekkel vagy más ETW-szolgáltatókkal, például sql serverrel vagy kernelszolgáltatóval.

• A munkafolyamat-szerzőknek nem kell módosítaniuk egy munkafolyamatot, hogy jobban működjenek egy adott nyomkövetési implementációval, például a WF3 SQL tracking service kötegelt módjával.

• A rendszergazda a gazdafolyamat újrahasznosítása nélkül is be- és kikapcsolhatja a nyomkövetést.

Az ETW-nyomkövetés teljesítménybeli előnyeinek hátrányai vannak. Az ETW-események elveszhetnek, ha a rendszer intenzív erőforrás-nyomás alatt áll. Az események feldolgozása nem célja a normál programvégrehajtás blokkolása, ezért nem garantált, hogy az összes ETW-eseményt az előfizetőknek közvetítik. Így az ETW nyomon követése kiválóan alkalmas az állapotfigyelésre, de nem alkalmas naplózásra.

Bár a WF4 nem rendelkezik SQL-követési szolgáltatóval, az AppFabric igen. Az AppFabric SQL-követési módszere az, hogy előfizet egy ETW-eseményekre egy Windows-szolgáltatással, amely kötegeli az eseményeket, és egy gyors beszúrásokhoz tervezett SQL-táblába írja őket. Egy külön feladat üríti ki a táblából az adatokat, és az AppFabric irányítópulton megtekinthető jelentési táblákká alakítja őket. Ez azt jelenti, hogy a nyomkövetési események kötegét a rendszer a kapott munkafolyamattól függetlenül kezeli, ezért nem kell megvárnia egy adatmegőrzési pontot a rögzítés előtt.

Az ETW-események rögzíthetők olyan eszközökkel, mint a logman vagy az xperf. A kompakt ETL-fájl megtekinthető egy olyan eszközzel, mint az xperfview, vagy átalakítható olvashatóbb formátumra, például XML-fájllá, tracerpttel. A WF3-ban az sql-adatbázis nélküli események nyomon követésének egyetlen lehetősége egy egyéni nyomkövetési szolgáltatás létrehozása. Az ETW-vel kapcsolatos további információkért lásd: WCF Services and Event Tracing for Windows and Event Tracing – Windows applications.

A munkafolyamat-nyomkövetés engedélyezése különböző mértékben befolyásolja a teljesítményt. Az alábbi referenciamutató a logman eszközzel használja az ETW nyomkövetési eseményeket, és rögzíti őket egy ETL-fájlba. Az AppFabric SQL-nyomkövetésének költsége nem tartozik a jelen cikk hatálya alá. Az AppFabricban is használt alapkövető profil ebben a teljesítménytesztben jelenik meg. Emellett a költségek csak az állapotfigyelési események nyomon követésének költségeit tartalmazzák. Ezek az események hasznosak a problémák elhárításához és a rendszer átlagos átviteli sebességének meghatározásához.

A környezet beállítása

A teszt eredményei

Az állapotfigyelés nagyjából 3%-os hatással van az átviteli sebességre. Az alapprofil költsége körülbelül 8%.

Együttműködési

A WF4 szinte teljes átírása a WF-nek, ezért a WF3 munkafolyamatok és tevékenységek nem kompatibilisek közvetlenül a WF4-zel. A Windows Workflow Foundationt korán elfogadó ügyfelek közül sok saját vagy külső gyártótól származó munkafolyamat-definíciókkal és egyéni tevékenységekkel rendelkezik a WF3-hoz. A WF4-be való áttérés megkönnyítésének egyik módja az Interop tevékenység használata, amely WF3-tevékenységeket hajthat végre egy WF4-munkafolyamaton belül. Javasoljuk, hogy a Interop tevékenységet csak akkor használja, ha szükséges. A WF4-be való migrálással kapcsolatos további információkért tekintse meg a WF4 migrálási útmutatóját.

A környezet beállítása

A teszt eredményei

Az alábbi táblázat egy olyan munkafolyamat futtatásának eredményeit mutatja be, amely öt tevékenységet tartalmaz egy sorrendben, különböző konfigurációkban.

Teszt	Átviteli sebesség (munkafolyamatok/másodperc)
WF3-sorozat a WF3-futtatókörnyezetben	1,576
WF3-sorozat a WF4-futtatókörnyezetben az Interop használatával	2,745
WF4-sorozat	153,582

Az Interop használata az egyenes WF3-nál jelentős teljesítménynövekedést jelent. A WF4-tevékenységekhez képest azonban a növekedés elhanyagolható.

Összegzés

A WF4 teljesítményére irányuló jelentős beruházások számos kulcsfontosságú területen kifizetődtek. Az egyes munkafolyamat-összetevők teljesítménye bizonyos esetekben több százszor gyorsabb a WF4-ben, mint a WF3-ban egy soványabb WF-futtatókörnyezet miatt. A késési számok is jelentősen jobbak. Ez azt jelenti, hogy a WF használatának teljesítménybeli büntetése a kézi kódolású WCF vezénylési szolgáltatások helyett nagyon kicsi, figyelembe véve a WF használatának további előnyeit. A megőrzési teljesítmény 2,5-3,0-s tényezővel nőtt. Az állapotmonitorozás a munkafolyamat-nyomon követés révén most nagyon kevés többletterheléssel jár. A WF3-ról WF4-be való áttérést fontolgatók számára átfogó migrálási útmutatók állnak rendelkezésre. Mindezeknek vonzóvá kell tennie a WF4-et az összetett alkalmazások írásához.