Prestanda för Windows Workflow Foundation 4

.NET Framework 4 innehåller en större revision av Windows Workflow Foundation (WF) med stora investeringar i prestanda. Den här nya revisionen introducerar betydande designändringar från tidigare versioner av WF som levererades som en del av .NET Framework 3.0 och .NET Framework 3.5. Den har byggts om från kärnan i programmeringsmodellen, körningen och verktygen för att avsevärt förbättra prestanda och användbarhet. Det här avsnittet visar de viktiga prestandaegenskaperna för dessa revisioner och jämför dem med dem i den tidigare versionen.

Prestanda för enskilda arbetsflödeskomponenter har ökat med storleksordningar mellan WF3 och WF4. Detta lämnar klyftan mellan handkodade WCF-tjänster (Windows Communication Foundation) och WCF-arbetsflödestjänster ganska små. Arbetsflödets svarstid har minskat avsevärt i WF4. Beständighetsprestanda har ökat med en faktor på 2,5–3,0. Hälsoövervakning med hjälp av arbetsflödesspårning har betydligt mindre omkostnader. Det här är övertygande skäl att migrera till eller använda WF4 i dina program.

Terminologi

Den version av WF som introducerades i .NET Framework 4 kallas WF4 för resten av det här avsnittet. WF introducerades i .NET Framework 3.0 och hade några mindre revisioner via .NET Framework 3.5 SP1. .NET Framework 3.5-versionen av Workflow Foundation kallas WF3 för resten av det här avsnittet. WF3 levereras i .NET Framework 4 sida vid sida med WF4. Mer information om hur du migrerar WF3-artefakter till WF4 finns i migreringsguiden för Windows Workflow Foundation 4.

Windows Communication Foundation (WCF) är Microsofts enhetliga programmeringsmodell för att skapa tjänstorienterade program. Den introducerades först som en del av .NET Framework 3.0 tillsammans med WF3 och är nu en av huvudkomponenterna i .NET Framework.

Windows Server AppFabric är en uppsättning integrerade tekniker som gör det enklare att skapa, skala och hantera webbprogram och sammansatta program som körs på IIS. Den innehåller verktyg för övervakning och hantering av tjänster och arbetsflöden. Mer information finns i Windows Server AppFabric 1.0.

Mål

Målet med det här avsnittet är att visa prestandaegenskaperna för WF4 med data som mäts för olika scenarier. Den innehåller också detaljerade jämförelser mellan WF4 och WF3 och visar därmed de stora förbättringar som har gjorts i den här nya revisionen. Scenarierna och data som presenteras i den här artikeln kvantifierar den underliggande kostnaden för olika aspekter av WF4 och WF3. Dessa data är användbara för att förstå prestandaegenskaperna för WF4 och kan vara till hjälp vid planering av migreringar från WF3 till WF4 eller med WF4 i programutveckling. Man bör dock vara försiktig med de slutsatser som dras av de uppgifter som presenteras i den här artikeln. Prestandan för ett sammansatt arbetsflödesprogram är mycket beroende av hur arbetsflödet implementeras och hur olika komponenter är integrerade. Man måste mäta varje program för att fastställa programmets prestandaegenskaper.

Översikt över prestandaförbättringar i WF4

WF4 utformades noggrant och implementerades med höga prestanda och skalbarhet som beskrivs i följande avsnitt.

WF-körning

Kärnan i WF-körningen är en asynkron schemaläggare som driver körningen av aktiviteterna i ett arbetsflöde. Det ger en högpresterande, förutsägbar körningsmiljö för aktiviteter. Miljön har ett väldefinierat kontrakt för körning, fortsättning, slutförande, annullering, undantag och en förutsägbar trådmodell.

Jämfört med WF3 har WF4-körningen en effektivare schemaläggare. Den utnyttjar samma I/O-trådpool som används för WCF, vilket är mycket effektivt vid körning av batchbaserade arbetsobjekt. Den interna schemaläggningskön för arbetsobjekt är optimerad för de vanligaste användningsmönstren. WF4-körningen hanterar även körningstillstånden på ett mycket enkelt sätt med minimal synkronisering och händelsehanteringslogik, medan WF3 är beroende av tung händelseregistrering och anrop för att utföra komplex synkronisering för tillståndsövergångar.

Datalagring och flöde

I WF3 modelleras data som är associerade med en aktivitet genom beroendeegenskaper som implementeras av typen DependencyProperty. Beroendeegenskapsmönstret introducerades i Windows Presentation Foundation (WPF). I allmänhet är det här mönstret mycket flexibelt för att stödja enkel databindning och andra gränssnittsfunktioner. Mönstret kräver dock att egenskaperna definieras som statiska fält i arbetsflödesdefinitionen. När WF-körningen ställer in eller hämtar egenskapsvärdena innebär det tungt viktad uppslagslogik.

WF4 använder klar dataomfångslogik för att avsevärt förbättra hur data hanteras i ett arbetsflöde. Den separerar data som lagras i en aktivitet från data som flödar över aktivitetsgränserna med hjälp av två olika begrepp: variabler och argument. Genom att använda ett tydligt hierarkiskt omfång för variabler och "In/Out/InOut"-argument minskas dataanvändningskomplexiteten för aktiviteter dramatiskt och datalivslängden begränsas också automatiskt. Aktiviteter har en väldefinierad signatur som beskrivs av dess argument. Genom att bara inspektera en aktivitet kan du avgöra vilka data den förväntar sig att ta emot och vilka data som ska skapas av den som ett resultat av dess körning.

I WF3 initierades aktiviteter när ett arbetsflöde skapades. I WF 4 initieras aktiviteter endast när motsvarande aktiviteter körs. Detta möjliggör en enklare aktivitetslivscykel utan att utföra initiera/uninitialisera åtgärder när en ny arbetsflödesinstans skapas och har därmed uppnått större effektivitet

Kontrollflöde

Precis som i alla programmeringsspråk ger WF stöd för kontrollflöden för arbetsflödesdefinitioner genom att introducera en uppsättning kontrollflödesaktiviteter för sekvensering, loopning, förgrening och andra mönster. När samma aktivitet måste köras igen i WF3 skapas en ny ActivityExecutionContext och aktiviteten klonas via en tung serialiserings- och deserialiseringslogik baserat på BinaryFormatter. Vanligtvis är prestandan för iterativa kontrollflöden mycket långsammare än att köra en sekvens med aktiviteter.

WF4 hanterar detta på ett helt annat sätt. Den tar aktivitetsmallen, skapar ett nytt ActivityInstance-objekt och lägger till det i scheduler-kön. Hela den här processen omfattar endast explicit skapande av objekt och är mycket enkel.

Asynkron programmering

Program har vanligtvis bättre prestanda och skalbarhet med asynkron programmering för tidskrävande blockeringsåtgärder som I/O eller distribuerade databehandlingsåtgärder. WF4 ger asynkront stöd via basaktivitetstyper AsyncCodeActivity, AsyncCodeActivity<TResult>. Körningen förstår asynkrona aktiviteter internt och kan därför automatiskt placera instansen i en icke-bestående zon medan det asynkrona arbetet är enastående. Anpassade aktiviteter kan härledas från dessa typer för att utföra asynkront arbete utan att hålla i tråden för arbetsflödesschemaläggaren och blockera aktiviteter som kan köras parallellt.

Meddelandetjänster

Ursprungligen hade WF3 mycket begränsat meddelandestöd via externa händelser eller anrop av webbtjänster. I .NET Framework 3.5 kan arbetsflöden implementeras som WCF-klienter eller exponeras som WCF-tjänster via SendActivity och ReceiveActivity. I WF4 har begreppet arbetsflödesbaserad meddelandeprogrammering förstärkts ytterligare genom en nära integrering av WCF-meddelandelogik i WF.

Den enhetliga pipelinen för meddelandebearbetning som tillhandahålls i WCF i .NET 4 hjälper WF4-tjänster att få betydligt bättre prestanda och skalbarhet än WF3. WF4 ger också ett mer omfattande stöd för meddelandeprogrammering som kan modellera komplexa Message Exchange Patterns (MEP). Utvecklare kan använda antingen maskinskrivna tjänstkontrakt för att uppnå enkel programmering eller oskrivna tjänstkontrakt för att uppnå bättre prestanda utan att betala serialiseringskostnader. Stöd för cachelagring på klientsidan via SendMessageChannelCache klassen i WF4 hjälper utvecklare att skapa snabba program med minimal ansträngning. Mer information finns i Ändra cachedelningsnivåer för skicka aktiviteter.

Deklarativ programmering

WF4 tillhandahåller ett rent och enkelt deklarativt programmeringsramverk för att modellera affärsprocesser och tjänster. Programmeringsmodellen stöder helt deklarativ sammansättning av aktiviteter, utan kod bredvid, vilket avsevärt förenklar arbetsflödesredigeringen. I .NET Framework 4 har det XAML-baserade deklarativa programmeringsramverket enhetligt i den enda sammansättningen System.Xaml.dll för att stödja både WPF och WF.

I WF4 ger XAML en verkligt deklarativ upplevelse och gör att hela definitionen av arbetsflödet kan definieras i XML-markering, referera till aktiviteter och typer som skapats med hjälp av .NET. Detta var svårt att göra i WF3 med XOML-format utan att behöva anpassad kod bakom logik. Den nya XAML-stacken i .NET 4 har mycket bättre prestanda vid serialisering/deserialisering av arbetsflödesartefakter och gör deklarativ programmering mer attraktiv och solid.

Arbetsflödesdesigner

Fullständigt deklarativt programmeringsstöd för WF4 ställer uttryckligen högre krav för designtidsprestanda för stora arbetsflöden. Arbetsflödesdesignern i WF4 har mycket bättre skalbarhet för stora arbetsflöden än för WF3. Med stöd för användargränssnittsvirtualisering kan designern enkelt läsa in ett stort arbetsflöde med 1 000 aktiviteter på några sekunder, medan det är nästan omöjligt att läsa in ett arbetsflöde med några hundra aktiviteter med WF3-designern.

Prestandajämförelser på komponentnivå

Det här avsnittet innehåller data om direkta jämförelser mellan enskilda aktiviteter i WF3- och WF4-arbetsflöden. Viktiga områden som beständighet har en mer djupgående inverkan på prestanda än de enskilda aktivitetskomponenterna. Prestandaförbättringarna i enskilda komponenter i WF4 är dock viktiga eftersom komponenterna nu är tillräckligt snabba för att jämföras med handkodad orkestreringslogik. Ett exempel som beskrivs i nästa avsnitt: "Scenario för tjänstsammansättning".

Miljökonfiguration

Bilden ovan visar den datorkonfiguration som används för prestandamätning på komponentnivå. En enskild server och fem klienter som är anslutna via ett Ethernet-nätverksgränssnitt på 1 Gbit/s. För enkla mätningar är servern konfigurerad att använda en enda kärna av en dubbel-proc/quad-core server som kör Windows Server 2008 x86. Systemets CPU-användning underhålls på nästan 100 %.

Testinformation

WF3 CodeActivity är förmodligen den enklaste aktiviteten som kan användas i ett WF3-arbetsflöde. Aktiviteten anropar en metod i koden bakom som arbetsflödesprogrammet kan placera anpassad kod i. I WF4 finns det ingen direkt analog till WF3 CodeActivity som tillhandahåller samma funktioner. Observera att det finns en CodeActivity basklass i WF4 som inte är relaterad till WF3 CodeActivity. Arbetsflödesförfattare uppmuntras att skapa anpassade aktiviteter och skapa XAML-endast arbetsflöden. I testerna nedan används en aktivitet med namnet Comment i stället för ett tomt CodeActivity i WF4-arbetsflöden. Koden i Comment aktiviteten är följande:

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

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

        protected override void Execute(CodeActivityContext context)
        {
        }
    }

Tomt arbetsflöde

Det här testet använder ett sekvensarbetsflöde utan underordnade aktiviteter.

Enskild aktivitet

Arbetsflödet är ett sekvensarbetsflöde som innehåller en underordnad aktivitet. Aktiviteten är en CodeActivity utan kod i WF3-fallet och en Comment aktivitet i WF4-fallet.

Med 1 000 iterationer

Sekvensarbetsflödet innehåller en While aktivitet med en underordnad aktivitet i loopen som inte utför något arbete.

Replikator jämfört med ParallelForEach

ReplicatorActivity i WF3 har sekventiella och parallella körningslägen. I sekventiellt läge liknar WhileActivityaktivitetens prestanda . Är ReplicatorActivity mest användbart för parallell körning. WF4-analogen ParallelForEach<T> för detta är aktiviteten.

Följande diagram visar de arbetsflöden som används för det här testet. WF3-arbetsflödet finns till vänster och WF4-arbetsflödet finns till höger.

Sekventiellt arbetsflöde med fem aktiviteter

Det här testet är avsett att visa effekten av att flera aktiviteter körs i följd. Det finns fem aktiviteter i sekvensen.

Transaktionsomfång

Transaktionsomfångstestet skiljer sig något från de andra testerna eftersom en ny arbetsflödesinstans inte skapas för varje iteration. I stället struktureras arbetsflödet med en while-loop som innehåller en TransactionScope aktivitet som innehåller en enda aktivitet som inte fungerar. Varje körning av en batch med 50 iterationer via while-loopen räknas som en enda åtgärd.

Kompensation

WF3-arbetsflödet har en enda kompenserande aktivitet med namnet WorkScope. Aktiviteten implementerar ICompensatableActivity helt enkelt gränssnittet:

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

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

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

Felhanteraren riktar in sig på WorkScope aktiviteten. WF4-arbetsflödet är lika förenklat. A CompensableActivity har ett organ och en kompensationshanterare. En explicit kompensation är nästa i sekvensen. Aktivitet för brödtext och kompensationshanterare är båda tomma implementeringar:

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

Följande diagram visar arbetsflödet för grundläggande kompensation. WF3-arbetsflödet finns till vänster och WF4-arbetsflödet finns till höger.

Prestandatestresultat

Alla tester mäts i arbetsflöden per sekund med undantag för transaktionsomfångstestet. Som du ser ovan har WF-körningsprestandan förbättrats över hela linjen, särskilt i områden som kräver flera körningar av samma aktivitet som while-loopen.

Scenario för tjänstsammansättning

Som visas i föregående avsnitt, "Prestandajämförelser på komponentnivå", har det skett en betydande minskning av omkostnaderna mellan WF3 och WF4. WCF-arbetsflödestjänster kan nu nästan matcha prestandan för handkodade WCF-tjänster men har fortfarande alla fördelar med WF-körningen. Det här testscenariot jämför en WCF-tjänst med en WCF-arbetsflödestjänst i WF4.

Onlinebutikstjänst

En av fördelarna med Windows Workflow Foundation är möjligheten att skapa processer med flera tjänster. I det här exemplet finns det en onlinebutikstjänst som samordnar två tjänstanrop för att köpa en beställning. Det första steget är att verifiera ordern med hjälp av en orderverifierande tjänst. Det andra steget är att fylla i ordern med hjälp av en lagertjänst.

De två serverdelstjänsterna, Order Validating Service och Warehouse Service, förblir desamma för båda testerna. Den del som ändras är onlinebutikstjänsten som utför orkestreringen. I ett fall är tjänsten handkodad som en WCF-tjänst. I det andra fallet skrivs tjänsten som en WCF-arbetsflödestjänst i WF4. WF-specifika funktioner som spårning och beständighet inaktiveras för det här testet.

Environment

Klientbegäranden görs till Online Store-tjänsten via HTTP från flera datorer. En enda dator är värd för alla tre tjänsterna. Transportlagret mellan Online Store-tjänsten och serverdelstjänsterna är TCP eller HTTP. Mätningen av åtgärder/sekund baseras på antalet slutförda PurchaseOrder anrop till Online Store-tjänsten. Kanalpooler är en ny funktion som är tillgänglig i WF4. I WCF-delen av den här testkanalpoolen tillhandahålls inte en handkodad implementering av en enkel poolteknik i Online Store-tjänsten.

Prestanda

Anslut till serverdels-TCP-tjänster utan kanalpooler har WF-tjänsten 17,2 % inverkan på dataflödet. Med kanalpooler är straffet cirka 23,8 %. För HTTP är effekten mycket mindre: 4,3 % utan poolning och 8,1 % med poolning. Det är också viktigt att observera att kanalpoolen ger mycket lite nytta när du använder HTTP.

Även om det finns kostnader från WF4-körningen jämfört med en handkodad WCF-tjänst i det här testet, kan det betraktas som ett värsta scenario. De två serverdelstjänsterna i det här testet gör mycket lite arbete. I ett verkligt scenario från slutpunkt till slutpunkt skulle dessa tjänster utföra dyrare åtgärder som databasanrop, vilket gör prestandapåverkan på transportlagret mindre viktig. Detta plus fördelarna med de funktioner som är tillgängliga i WF4 gör Workflow Foundation till ett genomförbart val för att skapa orkestreringstjänster.

Viktiga prestandaöverväganden

Funktionsområdena i det här avsnittet, med undantag för interop, har ändrats dramatiskt mellan WF3 och WF4. Detta påverkar utformningen av arbetsflödesprogram samt prestanda.

Svarstid för arbetsflödesaktivering

I ett WCF-arbetsflödestjänstprogram är svarstiden för att starta ett nytt arbetsflöde eller läsa in ett befintligt arbetsflöde viktigt eftersom det kan blockera. Det här testfallet mäter en WF3 XOML-värd mot en WF4 XAMLX-värd i ett typiskt scenario.

Miljökonfiguration

Testkonfiguration

I scenariot kontaktar en klientdator en WCF-arbetsflödestjänst med hjälp av kontextbaserad korrelation. Kontextkorrelation kräver en särskild kontextbindning och använder en kontextrubrik eller cookie för att relatera meddelanden till rätt arbetsflödesinstans. Det har en prestandafördel eftersom korrelations-ID:t finns i meddelandehuvudet så att meddelandetexten inte behöver parsas.

Tjänsten skapar ett nytt arbetsflöde med begäran och skickar ett omedelbart svar så att mätningen av svarstid inte inkluderar den tid som ägnas åt att köra arbetsflödet. WF3-arbetsflödet är XOML med en bakomliggande kod och WF4-arbetsflödet är helt XAML. WF4-arbetsflödet ser ut så här:

Aktiviteten Receive skapar arbetsflödesinstansen. Ett värde som skickas i det mottagna meddelandet upprepas i svarsmeddelandet. En sekvens efter svaret innehåller resten av arbetsflödet. I ovanstående fall visas endast en kommentarsaktivitet. Antalet kommentarsaktiviteter ändras för att simulera arbetsflödets komplexitet. En kommentarsaktivitet motsvarar en WF3 CodeActivity som inte utför något arbete. Mer information om kommentarsaktiviteten finns i avsnittet Prestandajämförelse på komponentnivå tidigare i den här artikeln.

Testresultat

Kall och varm svarstid för WCF-arbetsflödestjänster:

I föregående diagram refererar kall till det fall där det inte finns någon befintlig WorkflowServiceHost för det angivna arbetsflödet. Med andra ord är kall svarstid när arbetsflödet används för första gången och XOML eller XAML måste kompileras. Varm svarstid är det dags att skapa en ny arbetsflödesinstans när arbetsflödestypen redan har kompilerats. Arbetsflödets komplexitet gör mycket liten skillnad i WF4-fallet men har en linjär förlopp i WF3-fallet.

Korrelationsdataflöde

WF4 introducerar en ny innehållsbaserad korrelationsfunktion. WF3 tillhandahöll endast kontextbaserad korrelation. Kontextbaserad korrelation kunde bara göras över specifika WCF-kanalbindningar. Arbetsflödes-ID:t infogas i meddelandehuvudet när du använder dessa bindningar. WF3-körningen kunde bara identifiera ett arbetsflöde med dess ID. Med innehållsbaserad korrelation kan arbetsflödesförfattaren skapa en korrelationsnyckel av en relevant datadel som ett kontonummer eller kund-ID.

Kontextbaserad korrelation har en prestandafördel eftersom korrelationsnyckeln finns i meddelandehuvudet. Nyckeln kan läsas från meddelandet utan av-serialisering/meddelandekopiering. I innehållsbaserad korrelation lagras korrelationsnyckeln i meddelandetexten. Ett XPath-uttryck används för att hitta nyckeln. Kostnaden för den här extra bearbetningen beror på meddelandets storlek, djupet på nyckeln i brödtexten och antalet nycklar. Det här testet jämför kontext- och innehållsbaserad korrelation och visar även prestandaförsämring när du använder flera nycklar.

Miljökonfiguration

Testkonfiguration

Det tidigare arbetsflödet är samma som används i avsnittet Beständighet . För korrelationstesterna utan beständighet finns det ingen beständighetsprovider installerad i körningen. Korrelation sker på två platser: CreateOrder och CompleteOrder.

Testresultat

Det här diagrammet visar en minskning av prestanda när antalet nycklar som används i innehållsbaserad korrelation ökar. Likheten i kurvorna mellan TCP och HTTP anger de omkostnader som är associerade med dessa protokoll.

Korrelation med beständighet

Med ett beständiga arbetsflöde flyttas CPU-trycket från innehållsbaserad korrelation från arbetsflödeskörningen till SQL-databasen. De lagrade procedurerna i SQL-beständighetsprovidern utför arbetet med att matcha nycklarna för att hitta rätt arbetsflöde.

Kontextbaserad korrelation är fortfarande snabbare än innehållsbaserad korrelation. Skillnaden är dock mindre uttalad eftersom beständighet har större inverkan på prestanda än korrelation.

Komplext arbetsflödesdataflöde

Komplexiteten i ett arbetsflöde mäts inte bara av antalet aktiviteter. Sammansatta aktiviteter kan innehålla många barn och dessa barn kan också vara sammansatta aktiviteter. När antalet kapslingsnivåer ökar ökar också antalet aktiviteter som för närvarande kan vara i körningstillståndet och antalet variabler som kan vara i tillstånd. Det här testet jämför dataflödet mellan WF3 och WF4 när komplexa arbetsflöden körs.

Testkonfiguration

Dessa tester utfördes på en Intel Xeon X5355 @ 2,66 GHz 4-vägsdator med 4 GB RAM-minne som kör Windows Server 2008 x64. Testkoden körs i en enda process med en tråd per kärna för att nå 100 % cpu-användning.

Arbetsflödena som genereras för det här testet har två huvudvariabler: djup och antal aktiviteter i varje sekvens. Varje djupnivå innehåller en parallell aktivitet, medan loop, beslut, tilldelningar och sekvenser. I WF4-designern som visas nedan visas det översta flödesdiagrammet. Varje flödesschemaaktivitet liknar huvudflödesschemat. Det kan vara bra att tänka på en fraktal när du visar det här arbetsflödet, där djupet är begränsat till testparametrarna.

Antalet aktiviteter i ett visst test bestäms av djupet och antalet aktiviteter per sekvens. Följande ekvation beräknar antalet aktiviteter i WF4-testet:

WF3-testets aktivitetsantal kan beräknas med en något annorlunda ekvation på grund av en extra sekvens:

Där d är djupet och ett är antalet aktiviteter per sekvens. Logiken bakom dessa ekvationer är att den första konstanten, multiplicerad med en, är antalet sekvenser och den andra konstanten är det statiska antalet aktiviteter på den aktuella nivån. Det finns tre underordnade flödesschemaaktiviteter i varje flödesschema. På den nedre djupnivån är dessa flödesscheman tomma, men på de andra nivåerna är de kopior av huvudflödesschemat. Antalet aktiviteter i varje testvariants arbetsflödesdefinition anges i följande tabell:

Antalet aktiviteter i arbetsflödesdefinitionen ökar kraftigt för varje djupnivå. Men endast en sökväg per beslutspunkt körs i en viss arbetsflödesinstans, så endast en liten delmängd av de faktiska aktiviteterna körs.

Ett motsvarande arbetsflöde skapades för WF3. WF3-designern visar hela arbetsflödet i designområdet i stället för kapsling, därför är det för stort för att visas i det här avsnittet. Ett kodfragment av arbetsflödet visas nedan.

Om du vill använda kapsling i ett extremt fall använder ett annat arbetsflöde som ingår i det här testet 100 kapslade sekvenser. I den innersta sekvensen finns en enskild Comment eller CodeActivity.

Spårning och beständighet används inte som en del av det här testet.

Testresultat

Även med komplexa arbetsflöden med mycket djup och ett stort antal aktiviteter är prestandaresultaten konsekventa med andra dataflödesnummer som visades tidigare i den här artikeln. WF4:s dataflöde är storleksordningar snabbare och måste jämföras på en logaritmisk skala.

Minne

Minneskostnaderna för Windows Workflow Foundation mäts inom två nyckelområden: arbetsflödeskomplexitet och antal arbetsflödesdefinitioner. Minnesmätningar gjordes på en Windows 7 64-bitars arbetsstation. Det finns många sätt att hämta måttet för arbetsuppsättningens storlek, till exempel övervakning av prestandaräknare, avsökningsmiljö.WorkingSet eller med hjälp av ett verktyg som VMMap som är tillgängligt från VMMap. En kombination av metoder användes för att hämta och verifiera resultatet av varje test.

Arbetsflödets komplexitetstest

Arbetsflödets komplexitetstest mäter arbetsuppsättningsskillnaden baserat på arbetsflödets komplexitet. Utöver de komplexa arbetsflöden som användes i föregående avsnitt läggs nya varianter till för att täcka två grundläggande fall: ett arbetsflöde för en enda aktivitet och en sekvens med 1 000 aktiviteter. För dessa tester initieras och körs arbetsflödena till slutförande i en enda seriell loop under en period av en minut. Varje testvariant körs tre gånger och de data som registreras är genomsnittet av dessa tre körningar.

De två nya grundläggande testerna har arbetsflöden som ser ut som de som visas nedan:

I WF3-arbetsflödet som visas ovan används tomma CodeActivity aktiviteter. WF4-arbetsflödet ovan använder Comment aktiviteter. Aktiviteten Comment beskrevs i avsnittet Prestandajämförelser på komponentnivå tidigare i den här artikeln.

En av de tydliga trenderna att märka i det här diagrammet är att kapsling har relativt liten inverkan på minnesanvändningen i både WF3 och WF4. Den mest betydande minnespåverkan kommer från antalet aktiviteter i ett visst arbetsflöde. Med tanke på data från sekvens 1000, komplext djup 5 sekvens 5 och komplexa djup 7 sekvens 1 variationer, är det tydligt att när antalet aktiviteter kommer in tusentals, minnesanvändningen öka blir mer märkbar. I det extrema fallet (djup 7 sekvens 1) där det finns ~29 000 aktiviteter använder WF4 nästan 79 % mindre minne än WF3.

Test av flera arbetsflödesdefinitioner

Mätning av minne per arbetsflödesdefinition är indelat i två olika tester på grund av tillgängliga alternativ för att hantera arbetsflöden i WF3 och WF4. Testerna körs på ett annat sätt än arbetsflödets komplexitetstest eftersom ett visst arbetsflöde instanseras och körs bara en gång per definition. Det beror på att arbetsflödesdefinitionen och dess värd finns kvar i minnet under appdomänens livslängd. Det minne som används vid körning av en viss arbetsflödesinstans bör rensas under skräpinsamlingen. Migreringsvägledningen för WF4 innehåller mer detaljerad information om värdalternativen. Mer information finns i WF Migration Cookbook: Workflow Hosting( WF Migration Cookbook: Workflow Hosting).

Du kan skapa många arbetsflödesdefinitioner för ett arbetsflödesdefinitionstest på flera sätt. Man kan till exempel använda kodgenerering för att skapa en uppsättning med 1 000 arbetsflöden som är identiska förutom i namn och spara var och en av dessa arbetsflöden i separata filer. Den här metoden användes för det konsolhanterade testet. I WF3 WorkflowRuntime användes klassen för att köra arbetsflödesdefinitionerna. WF4 kan antingen använda WorkflowApplication för att skapa en enskild arbetsflödesinstans eller direkt använda WorkflowInvoker för att köra aktiviteten som om det vore ett metodanrop. WorkflowApplication är en värd för en enda arbetsflödesinstans och har en närmare funktionsparitet så WorkflowRuntime att den användes i det här testet.

När du är värd för arbetsflöden i IIS är det möjligt att använda en VirtualPathProvider för att skapa en ny WorkflowServiceHost i stället för att generera alla XAMLX- eller XOML-filer. Hanterar VirtualPathProvider den inkommande begäran och svarar med en "virtuell fil" som kan läsas in från en databas eller, i det här fallet, genereras i farten. Det är därför onödigt att skapa 1 000 fysiska filer.

Arbetsflödesdefinitionerna som användes i konsoltestet var enkla sekventiella arbetsflöden med en enda aktivitet. Den enda aktiviteten var tom CodeActivity för WF3-fallet och en Comment aktivitet för WF4-fallet. Det IIS-värdbaserade ärendet använde arbetsflöden som börjar ta emot ett meddelande och slutar med att skicka ett svar:

Följande bild visar ett WF3-arbetsflöde med ReceiveActivity och ett WF4-arbetsflöde med mönster för begäran/svar:

I följande tabell visas delta i arbetsuppsättningen mellan en enskild arbetsflödesdefinition och 1001-definitioner:

Värdalternativ	Delta i WF3-arbetsuppsättning	Delta i WF4-arbetsuppsättning
Värdbaserade arbetsflöden för konsolprogram	18 MB	9 MB
IIS-värdbaserade arbetsflödestjänster	446 MB	364 MB

Att vara värd för WorkflowServiceHostarbetsflödesdefinitioner i IIS förbrukar mycket mer minne på grund av , detaljerade WCF-tjänstartefakter och logiken för meddelandebearbetning som är associerad med värden.

För konsolvärd i WF3 implementerades arbetsflödena i kod i stället för XOML. I WF4 är standardvärdet att använda XAML. XAML lagras som en inbäddad resurs i sammansättningen och kompileras under körningen för att tillhandahålla implementeringen av arbetsflödet. Det finns vissa kostnader som är associerade med den här processen. För att göra en rättvis jämförelse mellan WF3 och WF4 användes kodade arbetsflöden i stället för XAML. Ett exempel på ett av WF4-arbetsflödena visas nedan:

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

Det finns många andra faktorer som kan påverka minnesförbrukningen. Samma råd för alla hanterade program gäller fortfarande. I IIS-värdbaserade miljöer finns objektet WorkflowServiceHost som skapats för en arbetsflödesdefinition kvar i minnet tills programpoolen återanvänds. Detta bör vara i åtanke när du skriver tillägg. Det är också bäst att undvika "globala" variabler (variabler som är begränsade till hela arbetsflödet) och begränsa omfånget för variabler där det är möjligt.

Arbetsflödeskörningstjänster

Bevarande

WF3 och WF4 levereras båda med en SQL-beständighetsprovider. WF3 SQL-beständighetsprovidern är en enkel implementering som serialiserar arbetsflödesinstansen och lagrar den i en blob. Därför beror prestanda för den här providern mycket på arbetsflödesinstansens storlek. I WF3 kan instansstorleken öka av många orsaker, vilket beskrivs tidigare i det här dokumentet. Många kunder väljer att inte använda standardprovidern för SQL-beständighet eftersom lagring av en serialiserad instans i en databas inte ger någon insyn i arbetsflödets tillstånd. För att hitta ett visst arbetsflöde utan att känna till arbetsflödes-ID:t måste man deserialisera varje bevarad instans och undersöka innehållet. Många utvecklare föredrar att skriva sina egna beständighetsleverantörer för att övervinna detta hinder.

WF4 SQL-beständighetsprovidern har försökt åtgärda några av dessa problem. Beständighetstabellerna exponerar viss information, till exempel aktiva bokmärken och promotable-egenskaper. Den nya innehållsbaserade korrelationsfunktionen i WF4 skulle inte fungera bra med WF3 SQL persistence-metoden, vilket har lett till en viss förändring i organisationen av den bevarade arbetsflödesinstansen. Detta gör jobbet för beständighetsprovidern mer komplext och lägger extra stress på databasen.

Miljökonfiguration

Testkonfiguration

Även med en förbättrad funktionsuppsättning och bättre samtidighetshantering är SQL-beständighetsprovidern i WF4 snabbare än providern i WF3. För att visa upp detta jämförs två arbetsflöden som utför i stort sett samma åtgärder i WF3 och WF4 nedan.

De två arbetsflödena skapas båda av ett mottaget meddelande. När du har skickat ett första svar sparas arbetsflödet. I WF3-fallet används en tom TransactionScopeActivity för att initiera beständigheten. Samma sak kan uppnås i WF3 genom att markera en aktivitet som "spara på nära". Ett andra korrelerat meddelande slutför arbetsflödet. Arbetsflödena sparas men tas inte bort.

Testresultat

När transporten mellan klienten och mellannivån är HTTP visar beständighet i WF4 en förbättring på 2,6 gånger. TCP-transporten ökar den faktorn till 3,0 gånger. I samtliga fall är processoranvändningen på mellannivån 98 % eller högre. Anledningen till att WF4-dataflödet är större beror på den snabbare arbetsflödeskörningen. Storleken på den serialiserade instansen är låg för båda fallen och är inte ett stort bidragande element i den här situationen.

Både WF3- och WF4-arbetsflödena i det här testet använder en aktivitet för att uttryckligen ange när beständighet ska inträffa. Detta har fördelen att bevara arbetsflödet utan att ta bort det. I WF3 är det också möjligt att bevara med hjälp av TimeToUnload funktionen, men detta tar bort arbetsflödesinstansen från minnet. Om en utvecklare som använder WF3 vill se till att ett arbetsflöde bevaras vid vissa tidpunkter måste de antingen ändra arbetsflödesdefinitionen eller betala kostnaden för att ta bort och läsa in arbetsflödesinstansen igen. En ny funktion i WF4 gör det möjligt att spara utan att ta bort: TimeToPersist. Den här funktionen gör att arbetsflödesinstansen kan sparas på inaktivt men stanna kvar i minnet tills tröskelvärdet uppfylls TimeToUnload eller körningen återupptas.

Observera att WF4 SQL-beständighetsprovidern utför mer arbete på databasnivån. SQL-databasen kan bli en flaskhals så det är viktigt att övervaka cpu- och diskanvändningen där. Se till att inkludera följande prestandaräknare från SQL-databasen när du testar arbetsflödesprogram för prestandatestning:

• PhysicalDisk\%Disk Read Time

• PhysicalDisk\% disktid

• PhysicalDisk\% diskskrivningstid

• PhysicalDisk\% Genomsnittlig diskkölängd

• PhysicalDisk\Avg. Diskläs kölängd

• PhysicalDisk\Genomsnittlig längd på diskskrivningskö

• PhysicalDisk\Aktuell diskkölängd

• Processorinformation\% processortid

• SQLServer:Latches\Average Latch Wait Time (ms)

• SQLServer:Latches\Latch Waits/s

Spårning

Arbetsflödesspårning kan användas för att spåra förloppet för ett arbetsflöde. Den information som ingår i spårningshändelserna bestäms av en spårningsprofil. Ju mer komplex spårningsprofilen är, desto dyrare blir spårningen.

WF3 levereras med en SQL-baserad spårningstjänst. Den här tjänsten kan fungera i batchbaserade och icke-batchbaserade lägen. I icke-batchbaserat läge skrivs spårningshändelser direkt till databasen. I batchläge samlas spårningshändelser in i samma batch som arbetsflödesinstansens tillstånd. Batchläget har den bästa prestandan för det bredaste utbudet av arbetsflödesdesigner. Batchbearbetning kan dock ha en negativ prestandapåverkan om arbetsflödet kör många aktiviteter utan att spara och dessa aktiviteter spåras. Detta skulle ofta inträffa i loopar och det bästa sättet att undvika det här scenariot är att utforma stora loopar så att de innehåller en beständighetspunkt. Att införa en beständighetspunkt i en loop kan också påverka prestanda negativt, så det är viktigt att mäta kostnaderna för var och en och komma med en balans.

WF4 levereras inte med en SQL-spårningstjänst. Registrering av spårningsinformation till en SQL-databas kan hanteras bättre från en programserver i stället för inbyggt i .NET Framework. Därför hanteras SQL-spårning nu av AppFabric. Den färdiga spårningsprovidern i WF4 baseras på händelsespårning för Windows (ETW).

ETW är ett händelsesystem på kernelnivå med låg latens som är inbyggt i Windows. Den använder en leverantörs-/konsumentmodell som gör det möjligt att endast ådra sig påföljden för händelsespårning när det faktiskt finns en konsument. Förutom kernelhändelser som processor, disk, minne och nätverksanvändning utnyttjar många program även ETW. ETW-händelser är kraftfullare än prestandaräknare eftersom händelser kan anpassas till programmet. En händelse kan innehålla text som ett arbetsflödes-ID eller ett informationsmeddelande. Händelser kategoriseras också med bitmasker så att användning av en viss delmängd av händelser får mindre prestandapåverkan än att samla in alla händelser.

Fördelarna med att använda ETW för spårning i stället för SQL är:

• Insamling av spårningshändelser kan separeras till en annan process. Detta ger större flexibilitet i hur händelserna registreras.

• ETW-spårningshändelser kombineras enkelt med WCF ETW-händelser eller andra ETW-leverantörer, till exempel en SQL Server- eller kernelprovider.

• Arbetsflödesförfattare behöver inte ändra ett arbetsflöde för att fungera bättre med en viss spårningsimplementering, till exempel WF3 SQL-spårningstjänstens batchläge.

• En administratör kan aktivera eller inaktivera spårning utan att återanvända värdprocessen.

Prestandafördelarna med ETW-spårning har en nackdel. ETW-händelser kan gå förlorade om systemet är under hårt resurstryck. Bearbetningen av händelser är inte avsedd att blockera normal programkörning och därför är det inte garanterat att alla ETW-händelser kommer att sändas till sina prenumeranter. Detta gör ETW-spårning bra för hälsoövervakning men inte lämplig för granskning.

Även om WF4 inte har någon SQL-spårningsprovider gör AppFabric det. AppFabrics SQL-spårningsmetod är att prenumerera på ETW-händelser med en Windows-tjänst som batchar händelserna och skriver dem till en SQL-tabell som är utformad för snabbinfogningar. Ett separat jobb tömmer data från den här tabellen och reformerar dem i rapporteringstabeller som kan visas på AppFabric-instrumentpanelen. Det innebär att en batch med spårningshändelser hanteras oberoende av det arbetsflöde som den kom från och därför inte behöver vänta på en beständighetspunkt innan den registreras.

ETW-händelser kan registreras med verktyg som logman eller xperf. Den kompakta ETL-filen kan visas med ett verktyg som xperfview eller konverteras till ett mer läsbart format, till exempel XML, med tracerpt. I WF3 är det enda alternativet för att hämta spårningshändelser utan en SQL-databas att skapa en anpassad spårningstjänst. Mer information om ETW finns i WCF-tjänster och händelsespårning för Windows - och Händelsespårning – Windows-program.

Aktivering av arbetsflödesspårning påverkar prestanda i varierande grad. Riktmärket nedan använder logman-verktyget för att använda ETW-spårningshändelserna och registrera dem i en ETL-fil. Kostnaden för SQL-spårning i AppFabric finns inte i omfånget för den här artikeln. Den grundläggande spårningsprofilen, som också används i AppFabric, visas i det här riktmärket. Dessutom ingår kostnaden för att endast spåra hälsoövervakningshändelser. Dessa händelser är användbara för att felsöka problem och fastställa systemets genomsnittliga dataflöde.

Miljökonfiguration

Testresultat

Hälsoövervakning har ungefär 3 % inverkan på dataflödet. Basprofilens kostnad är cirka 8 %.

Interop

WF4 är nästan en fullständig omskrivning av WF och därför är WF3-arbetsflöden och aktiviteter inte direkt kompatibla med WF4. Många kunder som antog Windows Workflow Foundation tidigt kommer att ha interna eller externa arbetsflödesdefinitioner och anpassade aktiviteter för WF3. Ett sätt att underlätta övergången till WF4 är att använda Interop-aktiviteten, som kan köra WF3-aktiviteter inifrån ett WF4-arbetsflöde. Vi rekommenderar att Interop aktiviteten endast används när det behövs. Mer information om hur du migrerar till WF4 finns i WF4-migreringsvägledningen.

Miljökonfiguration

Testresultat

Följande tabell visar resultatet av att köra ett arbetsflöde som innehåller fem aktiviteter i en sekvens i olika konfigurationer.

Testa	Dataflöde (arbetsflöden/s)
WF3-sekvens i WF3-körning	1,576
WF3-sekvens i WF4-körning med Interop	2,745
WF4-sekvens	153,582

Det finns en märkbar prestandaökning för att använda Interop över raka WF3. Men jämfört med WF4-aktiviteter är ökningen försumbar.

Sammanfattning

Stora investeringar i prestanda för WF4 har lönat sig på många viktiga områden. Prestanda för enskilda arbetsflödeskomponenter är i vissa fall hundratals gånger snabbare i WF4 jämfört med WF3 på grund av en smalare WF-körning. Svarstidsnummer är också betydligt bättre. Det innebär att prestandastraffet för att använda WF i stället för att handkoda WCF-orkestreringstjänster är mycket liten med tanke på de extra fördelarna med att använda WF. Beständighetsprestanda har ökat med en faktor på 2,5–3,0. Hälsoövervakning med hjälp av arbetsflödesspårning har nu mycket lite omkostnader. En omfattande uppsättning migreringsguider är tillgängliga för dem som överväger att flytta från WF3 till WF4. Allt detta bör göra WF4 till ett attraktivt alternativ för att skriva komplexa program.