A Windows Workflow Foundation 4 teljesítménye

A .NET-keretrendszer 4 tartalmazza a Windows Workflow Foundation (WF) fő felülvizsgálatát, amely jelentős teljesítménybeli befektetésekkel rendelkezik. Ez az új változat jelentős tervezési változásokat vezet be a WF korábbi verzióihoz képest, amelyek a .NET Framework 3.0 és a .NET Framework 3.5 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 a .NET-keretrendszer 3.0-s verziójában lett bevezetve, és a .NET-keretrendszer 3.5 SP1-en keresztül 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 a .NET Framework 4-ben, a WF4-tel 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 Framework 3.0 és a WF3 részeként vezették be, és most a .NET-keretrendszer egyik fő ö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ő sor 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 Presentation Foundationben (WPF) 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 összetett keresési logikával jár együtt.

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 jól definiált aláírással rendelkeznek, amit a hozzájuk tartozó argumentumok írnak le. 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

Folyamat vezérlése

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, és ezért automatikusan nem-állandó zónába helyezheti a folyamatot, miközben az aszinkron munka folyamatban van. Az ilyen típusú egyéni tevékenységek aszinkron munkát végezhetnek anélkül, hogy megtartanák a munkafolyamat-ütemező szálát, így nem akadályozzák azokat a tevékenységeket, amelyek párhuzamosan futtathatók.

Üzenet

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-ügyfélként valósíthatók meg, vagy WCF-szolgáltatásként tehetők elérhetővé SendActivity és ReceiveActivity használatával. 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 .NET-keretrendszer 4-ben az XAML-alapú deklaratív programozási keretrendszer egységesítve lett az System.Xaml.dll assembly-be 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".

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%szinten van fenntartva.

Teszt részletei

A WF3 CodeActivity valószínűleg a legegyszerűbb tevékenység, amely egy WF3 munkafolyamatban használható. 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 Comment nevű tevékenységet használják egy üres CodeActivity helyett a WF4 munkafolyamatokban. 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 szekvenciális munkafolyamat, amely egy gyermektevékenységet tartalmaz. A tevékenység a WF3 esetben egy CodeActivity kód nélküli tevékenység, és a WF4 esetben egy Comment tevékenység.

1000 iteráció során

A szekvencia-munkafolyamat egy While tevékenységet tartalmaz egy cikluson belüli altevékenységgel, amely nem végez 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 a WhileActivity-hez hasonló. A ReplicatorActivity a párhuzamos végrehajtáshoz a leghasznosabb. 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 Workflow futtatókörnyezet teljesítménye összességében javult, különösen azokban a területeken, amelyek több végrehajtást igényelnek ugyanahhoz a tevékenységhez, mint például a while 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 változást az a rész jelenti, amelyben az Online Áruház szolgáltatás végzi a vezénylést. ** Egy esetben a szolgáltatás WCF-szolgáltatásként van kézzel kódolva. 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 tesztrészében az alapértelmezett csatornakészletkezelés nem áll rendelkezésre, ezért egy egyszerű, kézzel kódolt csatornakészlet-kezelési technikát alkalmaztak az Online Áruház szolgáltatásban.

Teljesítmény

A háttérbeli TCP-szolgáltatások csatorna pooling nélküli használata esetén a WF szolgáltatás 17,2% mértékben csökkenti az átviteli sebességet. A csatornák egyesítésével a hátrány körülbelül 23,8%. HTTP esetén a hatás sokkal kisebb: 4.3% készletezés nélkül és 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 tipikus forgatókönyvben értékeli a WF3 XOML-gazdagépet a WF4 XAMLX-gazdagéphez képest.

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, a háttérben futó kóddal, míg a WF4 munkafolyamat 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 akkor következik be, amikor a munkafolyamatot első alkalommal használják, és a XOML vagy az XAML lefordításra van szükség. 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.

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% processzorhasználatot.

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. Mélységi szint tartalmaz párhuzamos tevékenységeket, ciklusokat, 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 logikája az, hogy az első állandó a val szorozva adja meg a sorozatok számát, míg a második állandó az aktuális szinten lévő tevékenységek számát. 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, ahelyett, hogy beágyazná, ezért túlságosan nagy ahhoz, hogy ebben a témakörben megjelenjen. 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.

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 grafikon egyik egyértelműen látható trendje az, hogy a beágyazás viszonylag minimális hatással van a memóriahasználatra mind a WF3, mind a WF4 esetében. 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-ös komplex mélységű, 5. sorozatra, és a 7-es komplex mélységű 1. sorozat változatára, nyilvánvaló, hogy ahogy a tevékenységek száma az ezrek közé tartozik, a memóriahasználat növekedése észrevehetőbbé válik. A szélsőséges esetben (mélység 7 sorozat 1), ahol körülbelül 29 ezer tevékenység van, a WF4 majdnem 79%-val kevesebb memóriát használ, 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 konzolon futó 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ók egyenértékűsége WorkflowRuntime-hoz közelebb van, így ezt használták ebben a tesztben.

Amikor munkafolyamatokat üzemeltet az IIS-ben, egy VirtualPathProvider segítségével hozhat létre egy új WorkflowServiceHost az összes XAMLX- vagy XOML-fájl generálása helyett. 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. Egyedüli tevékenységként a WF3 esetben üres CodeActivity, a WF4 esetben pedig egy Comment tevékenység volt. 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 az összetevőben, és futásidőben lesz lefordítva, hogy biztosítsa a munkafolyamat végrehajtá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.

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 eltávolítva.

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% vagy annál magasabb. A WF4 nagyobb folyamatátvitele annak köszönhető, hogy a munkafolyamat futási ideje gyorsabb. 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 mind egy tevékenység használatával meghatározzák az állandósítás idejét. Ennek az az előnye, hogy a munkafolyamatot anélkül őrizheti meg, hogy nem távolítja el. A WF3-ban a TimeToUnload funkció használatával is megőrizhető az állapot, de ez kiüríti 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 idő

• PhysicalDisk\% lemezhasználat ideje

• PhysicalDisk\% lemez írási ideje

• PhysicalDisk\% Átl. lemezsor hossz

• PhysicalDisk\Átlagos lemez olvasási várólista hossza

• PhysicalDisk\Átlagos lemez írási várakozási sor hossza

• FizikaiLemez\Aktuális lemez várólista hossza

• Processzoradatok\% processzoridő

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

• SQLServer:Latches\Zár-várakozások/másodperc

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őriznék őket, és ezeket a tevékenységeket nyomon követik. Ez általában hurkokban fordul elő, és ennek elkerülésére a legjobb módszer az, ha nagy hurkokat alakít ki, amelyek tartalmaznak egy állapotmentési pontot. 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ázisok nyomkövetési adatainak rögzítése jobban kezelhető egy alkalmazáskiszolgálóról a .NET-keretrendszerbe való beépítés helyett. Ezért az SQL-nyomkövetést mostantól az AppFabric kezeli. A WF4 alapértelmezett nyomkövetési szolgáltatója a Windows Eseménykövetés (ETW) szolgáltatásán 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 a SQL helyett történő követéshez 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őinek nem kell módosítaniuk a munkafolyamatot, hogy jobban működjön egy adott nyomkövetési implementációval, például a WF3 SQL nyomkövetési szolgáltatás 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.

Környezet beállítása

A teszt eredményei

Az állapotfigyelés nagyjából 3% hatással van a rendszer teljesítményére. Az alapprofil költsége körülbelül 8%.

Interop

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.

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-szekvencia 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ó.

Összefoglalá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 hatékonyabb 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.