Prestaties van Windows Workflow Foundation 4
.NET Framework 4 omvat een belangrijke revisie van de Windows Workflow Foundation (WF) met zware investeringen in prestaties. Deze nieuwe revisie introduceert belangrijke ontwerpwijzigingen ten opzichte van de vorige versies van WF die zijn verzonden als onderdeel van .NET Framework 3.0 en .NET Framework 3.5. Het is opnieuw ontworpen vanuit de kern van het programmeermodel, runtime en hulpprogramma's om de prestaties en bruikbaarheid aanzienlijk te verbeteren. In dit onderwerp worden de belangrijke prestatiekenmerken van deze revisies beschreven en vergeleken met die van de vorige versie.
De prestaties van afzonderlijke werkstroomonderdelen zijn toegenomen met een orde van grootte tussen WF3 en WF4. Hierdoor blijft de kloof tussen met de hand gecodeerde WCF-services (Windows Communication Foundation) en WCF-werkstroomservices vrij klein. De werkstroomlatentie is aanzienlijk verminderd in WF4. De persistentieprestaties zijn met een factor van 2,5 - 3,0 toegenomen. Statuscontrole door middel van werkstroomtracking heeft aanzienlijk minder overhead. Dit zijn aantrekkelijke redenen om WF4 in uw toepassingen te migreren of te gebruiken.
Terminologie
De versie van WF die in .NET Framework 4 is geïntroduceerd, wordt voor de rest van dit onderwerp aangeduid als WF4. WF is geïntroduceerd in .NET Framework 3.0 en had enkele kleine revisies via .NET Framework 3.5 SP1. De .NET Framework 3.5-versie van Workflow Foundation wordt voor de rest van dit onderwerp aangeduid als WF3. WF3 wordt geleverd in .NET Framework 4 naast WF4. Zie voor meer informatie over het migreren van WF3-artefacten naar WF4: Migratiehandleiding voor Windows Workflow Foundation 4.
Windows Communication Foundation (WCF) is het geïntegreerde programmeermodel van Microsoft voor het bouwen van servicegerichte toepassingen. Het werd voor het eerst geïntroduceerd als onderdeel van .NET Framework 3.0 samen met WF3 en is nu een van de belangrijkste onderdelen van het .NET Framework.
Windows Server AppFabric is een set geïntegreerde technologieën waarmee u eenvoudiger web- en samengestelde toepassingen kunt bouwen, schalen en beheren die worden uitgevoerd op IIS. Het biedt hulpprogramma's voor het bewaken en beheren van services en werkstromen. Zie Windows Server AppFabric 1.0 voor meer informatie.
Doelstellingen
Het doel van dit onderwerp is om de prestatiekenmerken van WF4 weer te geven met gegevens die zijn gemeten voor verschillende scenario's. Het biedt ook gedetailleerde vergelijkingen tussen WF4 en WF3, en toont dus de grote verbeteringen die zijn aangebracht in deze nieuwe herziening. De scenario's en gegevens in dit artikel kwantificeren de onderliggende kosten van verschillende aspecten van WF4 en WF3. Deze gegevens zijn handig bij het begrijpen van de prestatiekenmerken van WF4 en kunnen nuttig zijn bij het plannen van migraties van WF3 naar WF4 of het gebruik van WF4 in de ontwikkeling van toepassingen. In de conclusies die uit de in dit artikel gepresenteerde gegevens zijn getrokken, moet er echter voor worden gezorgd. De prestaties van een samengestelde werkstroomtoepassing zijn sterk afhankelijk van hoe de werkstroom wordt geïmplementeerd en hoe verschillende onderdelen worden geïntegreerd. U moet elke toepassing meten om de prestatiekenmerken van die toepassing te bepalen.
Overzicht van WF4-prestatieverbeteringen
WF4 is zorgvuldig ontworpen en geïmplementeerd met hoge prestaties en schaalbaarheid die worden beschreven in de volgende secties.
WF Runtime
De kern van de WF-runtime is een asynchrone scheduler die de uitvoering van de activiteiten in een werkstroom aanstuurt. Het biedt een krachtige, voorspelbare uitvoeringsomgeving voor activiteiten. De omgeving heeft een goed gedefinieerd contract voor uitvoering, voortzetting, voltooiing, annulering, uitzonderingen en een voorspelbaar threadingmodel.
In vergelijking met WF3 heeft de WF4-runtime een efficiëntere planner. Het maakt gebruik van dezelfde I/O-threadgroep die wordt gebruikt voor WCF, wat zeer efficiënt is bij het uitvoeren van batchgewijze werkitems. De interne werkitemplannerwachtrij is geoptimaliseerd voor de meest voorkomende gebruikspatronen. De WF4-runtime beheert ook de uitvoeringsstatussen op een zeer lichte manier met minimale synchronisatie- en gebeurtenisafhandelingslogica, terwijl WF3 afhankelijk is van zware gebeurtenisregistratie en aanroep om complexe synchronisatie voor statusovergangen uit te voeren.
Gegevensopslag en -stroom
In WF3 worden gegevens die zijn gekoppeld aan een activiteit gemodelleerd via afhankelijkheidseigenschappen die door het type DependencyPropertyzijn geïmplementeerd. Het patroon van de afhankelijkheidseigenschap is geïntroduceerd in Windows Presentation Foundation (WPF). Over het algemeen is dit patroon zeer flexibel om eenvoudige gegevensbindingen en andere UI-functies te ondersteunen. Het patroon vereist echter dat de eigenschappen worden gedefinieerd als statische velden in de werkstroomdefinitie. Wanneer de WF-runtime de eigenschapswaarden instelt of ophaalt, omvat deze sterk gewogen opzoeklogica.
WF4 maakt gebruik van duidelijke logica voor gegevensbereik om de manier waarop gegevens worden verwerkt in een werkstroom aanzienlijk te verbeteren. Het scheidt de gegevens die zijn opgeslagen in een activiteit van de gegevens die over de grenzen van de activiteit stromen met behulp van twee verschillende concepten: variabelen en argumenten. Door gebruik te maken van een duidelijk hiërarchisch bereik voor variabelen en 'In/Out/InOut'-argumenten, wordt de complexiteit van het gegevensgebruik voor activiteiten aanzienlijk verminderd en wordt de levensduur van de gegevens ook automatisch beperkt. Activiteiten hebben een goed gedefinieerde handtekening die wordt beschreven door de argumenten. Door simpelweg een activiteit te inspecteren, kunt u bepalen welke gegevens ze verwachten te ontvangen en welke gegevens door deze worden geproduceerd als gevolg van de uitvoering ervan.
In WF3-activiteiten zijn geïnitialiseerd toen een werkstroom werd gemaakt. In WF 4-activiteiten worden alleen geïnitialiseerd wanneer de bijbehorende activiteiten worden uitgevoerd. Dit maakt een eenvoudigere levenscyclus van activiteiten mogelijk zonder initialiseren/niet-geïnitialiseerde bewerkingen uit te voeren wanneer een nieuw werkstroomexemplaren wordt gemaakt en zo meer efficiëntie heeft bereikt
Controlestroom
Net als in elke programmeertaal biedt WF ondersteuning voor besturingsstromen voor werkstroomdefinities door een set controlestroomactiviteiten te introduceren voor sequentiëren, herhalen, vertakkingen en andere patronen. Wanneer dezelfde activiteit opnieuw moet worden uitgevoerd, wordt er in WF3 een nieuwe ActivityExecutionContext gemaakt en wordt de activiteit gekloond via een zware serialisatie- en deserialisatielogica op BinaryFormatterbasis van . De prestaties voor iteratieve controlestromen zijn meestal veel langzamer dan het uitvoeren van een reeks activiteiten.
WF4 verwerkt dit heel anders. Hiervoor wordt de activiteitssjabloon gebruikt, wordt een nieuw ActivityInstance-object gemaakt en toegevoegd aan de scheduler-wachtrij. Dit hele proces omvat alleen het expliciet maken van objecten en is zeer licht.
Asynchrone programmering
Toepassingen hebben meestal betere prestaties en schaalbaarheid met asynchrone programmering voor langdurige blokkerende bewerkingen, zoals I/O- of gedistribueerde computingbewerkingen. WF4 biedt asynchrone ondersteuning via basisactiviteitstypen AsyncCodeActivity, AsyncCodeActivity<TResult>. De runtime begrijpt asynchrone activiteiten en kan het exemplaar daarom automatisch in een zone zonder persistent maken plaatsen terwijl het asynchrone werk uitstekend is. Aangepaste activiteiten kunnen worden afgeleid van deze typen om asynchroon werk uit te voeren zonder de thread van de werkstroomplanner vast te houden en activiteiten te blokkeren die parallel kunnen worden uitgevoerd.
Berichten
In eerste instantie had WF3 zeer beperkte ondersteuning voor berichten via externe gebeurtenissen of webservices-aanroepen. In .NET Framework 3.5 kunnen werkstromen worden geïmplementeerd als WCF-clients of worden weergegeven als WCF-services via SendActivity en ReceiveActivity. In WF4 is het concept van op werkstromen gebaseerde berichtprogrammering verder versterkt door de nauwe integratie van WCF-berichtlogica in WF.
De geïntegreerde pijplijn voor berichtverwerking die is geleverd in WCF in .NET 4 helpt WF4-services aanzienlijk betere prestaties en schaalbaarheid te hebben dan WF3. WF4 biedt ook uitgebreidere ondersteuning voor het programmeren van berichten waarmee complexe Message Exchange Patterns (MEP's) kunnen worden gemodelleerd. Ontwikkelaars kunnen getypeerde servicecontracten gebruiken om eenvoudige programmeer- of niet-getypeerde servicecontracten te bereiken om betere prestaties te bereiken zonder serialisatiekosten te betalen. De ondersteuning voor het opslaan van kanalen aan de clientzijde via de klasse in WF4 helpt ontwikkelaars bij het SendMessageChannelCache bouwen van snelle toepassingen met minimale inspanning. Zie Voor meer informatie het wijzigen van de niveaus voor het delen van caches voor verzendactiviteiten.
Declaratieve programmering
WF4 biedt een schoon en eenvoudig declaratief programmeerframework om bedrijfsprocessen en services te modelleren. Het programmeermodel ondersteunt volledige declaratieve samenstelling van activiteiten, zonder code naast elkaar, waardoor het ontwerpen van werkstromen aanzienlijk wordt vereenvoudigd. In .NET Framework 4 is het declaratieve programmeerframework op basis van XAML geïntegreerd in één assembly-System.Xaml.dll om zowel WPF als WF te ondersteunen.
In WF4 biedt XAML een echt declaratieve ervaring en maakt het mogelijk om de volledige definitie van de werkstroom te definiëren in XML-markeringen, te verwijzen naar activiteiten en typen die zijn gebouwd met behulp van .NET. Dit was moeilijk te doen in WF3 met XOML-indeling zonder aangepaste logica achter code te gebruiken. De nieuwe XAML-stack in .NET 4 heeft veel betere prestaties bij het serialiseren/deserialiseren van werkstroomartefacten en maakt declaratieve programmering aantrekkelijker en solide.
Werkstroomontwerper
Volledig declaratieve programmeerondersteuning voor WF4 legt expliciet hogere vereisten op voor ontwerptijdprestaties voor grote werkstromen. De werkstroomontwerper in WF4 heeft veel betere schaalbaarheid voor grote werkstromen dan die voor WF3. Met ondersteuning voor UI-virtualisatie kan de ontwerper eenvoudig een grote werkstroom van 1000 activiteiten in een paar seconden laden, terwijl het bijna onmogelijk is om een werkstroom van een paar honderd activiteiten te laden met de WF3-ontwerper.
Prestatievergelijkingen op onderdeelniveau
Deze sectie bevat gegevens over directe vergelijkingen tussen afzonderlijke activiteiten in WF3- en WF4-werkstromen. Belangrijke gebieden, zoals persistentie, hebben een diepgaandere invloed op de prestaties dan de afzonderlijke activiteitsonderdelen. De prestatieverbeteringen in afzonderlijke onderdelen in WF4 zijn echter belangrijk omdat de onderdelen nu snel genoeg zijn om te worden vergeleken met handgecodeerde indelingslogica. Een voorbeeld hiervan wordt behandeld in de volgende sectie: 'Scenario voor servicesamenstelling'.
Configuratie van de omgeving
In de bovenstaande afbeelding ziet u de machineconfiguratie die wordt gebruikt voor prestatiemeting op onderdeelniveau. Eén server en vijf clients die zijn verbonden via één 1 Gbps Ethernet-netwerkinterface. Voor eenvoudige metingen is de server geconfigureerd voor het gebruik van één kern van een dual-proc/quad-core-server met Windows Server 2008 x86. Het CPU-gebruik van het systeem wordt met bijna 100% gehandhaafd.
Testdetails
De WF3 CodeActivity is waarschijnlijk de eenvoudigste activiteit die kan worden gebruikt in een WF3-werkstroom. De activiteit roept een methode aan in de codeachter waar de programmeur van de werkstroom aangepaste code in kan plaatsen. In WF4 is er geen directe analogie met de WF3 CodeActivity die dezelfde functionaliteit biedt. Houd er rekening mee dat er een CodeActivity basisklasse in WF4 is die niet is gerelateerd aan de WF3 CodeActivity. Auteurs van werkstromen worden aangemoedigd om aangepaste activiteiten te maken en alleen XAML-werkstromen te bouwen. In de onderstaande tests wordt een activiteit die wordt aangeroepen Comment , gebruikt in plaats van een lege CodeActivity in WF4-werkstromen. De code in de Comment activiteit is als volgt:
[ContentProperty("Body")]
public sealed class Comment : CodeActivity
{
public Comment()
: base()
{
}
[DefaultValue(null)]
public Activity Body
{
get;
set;
}
protected override void Execute(CodeActivityContext context)
{
}
}
Lege werkstroom
Deze test maakt gebruik van een sequentiewerkstroom zonder onderliggende activiteiten.
Eén activiteit
De werkstroom is een sequentiewerkstroom die één onderliggende activiteit bevat. De activiteit is een CodeActivity zonder code in de WF3-case en een Comment activiteit in de WF4-case.
Tijdens 1000 iteraties
De werkstroom voor de reeks bevat één While activiteit met één onderliggende activiteit in de lus die geen werk uitvoert.
Replicator vergeleken met ParallelForEach
ReplicatorActivity in WF3 heeft opeenvolgende en parallelle uitvoeringsmodi. In de sequentiële modus zijn de prestaties van de activiteit vergelijkbaar met de WhileActivity. Dit ReplicatorActivity is het handigst voor parallelle uitvoering. De WF4-analogie hiervoor is de ParallelForEach<T> activiteit.
In het volgende diagram ziet u de werkstromen die voor deze test worden gebruikt. De WF3-werkstroom bevindt zich aan de linkerkant en de WF4-werkstroom bevindt zich aan de rechterkant.
Sequentiële werkstroom met vijf activiteiten
Deze test is bedoeld om het effect weer te geven van het op volgorde uitvoeren van verschillende activiteiten. Er zijn vijf activiteiten in de reeks.
Transactiebereik
De transactiebereiktest verschilt enigszins van de andere tests omdat er voor elke iteratie geen nieuw werkstroomexemplaren worden gemaakt. In plaats daarvan is de werkstroom gestructureerd met een while-lus die een TransactionScope activiteit bevat die één activiteit bevat die geen werk doet. Elke uitvoering van een batch van 50 iteraties door de while-lus wordt geteld als één bewerking.
Compensatie
De WF3-werkstroom heeft één compensabele activiteit met de naam WorkScope. De activiteit implementeert eenvoudigweg de ICompensatableActivity interface:
class WorkScope :
CompositeActivity, ICompensatableActivity
{
public WorkScope() : base() { }
public WorkScope(string name)
{
this.Name = name;
}
public ActivityExecutionStatus Compensate(
ActivityExecutionContext executionContext)
{
return ActivityExecutionStatus.Closed;
}
}
De fouthandler is gericht op de WorkScope activiteit. De WF4-werkstroom is even eenvoudig. A CompensableActivity heeft een lichaam en een compensatiehandler. Een expliciete compensatie is de volgende in de reeks. De activiteit van de hoofdtekst en de compensatiehandleractiviteit zijn beide lege implementaties:
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) { }
}
In het volgende diagram ziet u de werkstroom basiscompensatie. De WF3-werkstroom bevindt zich aan de linkerkant en de WF4-werkstroom bevindt zich aan de rechterkant.
Resultaten van prestatietest
Alle tests worden gemeten in werkstromen per seconde, met uitzondering van de transactiebereiktest. Zoals hierboven te zien is, zijn de prestaties van de WF-runtime verbeterd, met name op gebieden waarvoor meerdere uitvoeringen van dezelfde activiteit nodig zijn, zoals tijdens de lus.
Scenario voor servicesamenstelling
Zoals wordt weergegeven in de vorige sectie, 'Prestatievergelijkingen op onderdeelniveau', is er een aanzienlijke vermindering van de overhead tussen WF3 en WF4. WCF-werkstroomservices kunnen nu bijna overeenkomen met de prestaties van met de hand gecodeerde WCF-services, maar hebben nog steeds alle voordelen van de WF-runtime. In dit testscenario wordt een WCF-service vergeleken met een WCF-werkstroomservice in WF4.
Online winkelservice
Een van de sterke punten van Windows Workflow Foundation is de mogelijkheid om processen samen te stellen met behulp van verschillende services. In dit voorbeeld is er een online winkelservice waarmee twee serviceaanroepen worden ingedeeld om een bestelling aan te schaffen. De eerste stap bestaat uit het valideren van de bestelling met behulp van een ordervalidatieservice. De tweede stap is het invullen van de bestelling met behulp van een magazijnservice.
De twee back-endservices, Order Validating Service en Warehouse Service, blijven hetzelfde voor beide tests. Het deel dat verandert, is de Online Store-service waarmee de indeling wordt uitgevoerd. In één geval is de service met de hand gecodeerd als WCF-service. In het andere geval wordt de service geschreven als een WCF-werkstroomservice in WF4. WF-specifieke functies, zoals tracering en persistentie, zijn uitgeschakeld voor deze test.
Omgeving
Clientaanvragen worden via HTTP vanaf meerdere computers naar de Online Store-service verzonden. Eén computer host alle drie de services. De transportlaag tussen de Online Store-service en de back-endservices is TCP of HTTP. De meting van bewerkingen/seconde is gebaseerd op het aantal voltooide PurchaseOrder oproepen naar de Online Store-service. Kanaalpooling is een nieuwe functie die beschikbaar is in WF4. In het WCF-gedeelte van deze testkanaalpooling is niet standaard beschikbaar, dus er is een handcoded implementatie van een eenvoudige pooltechniek gebruikt in de Online Store-service.
Prestaties
Verbinding maken naar back-end TCP-services zonder kanaalpooling, heeft de WF-service een invloed van 17,2% op de doorvoer. Bij kanaalpooling is de boete ongeveer 23,8%. Voor HTTP is de impact veel minder: 4,3% zonder pooling en 8,1% met pooling. Het is ook belangrijk om te weten dat het poolen van kanalen zeer weinig voordeel biedt bij het gebruik van HTTP.
Hoewel er overhead is ten opzichte van de WF4-runtime vergeleken met een met de hand gecodeerde WCF-service in deze test, kan dit worden beschouwd als een slechtst scenario. De twee back-endservices in deze test doen weinig werk. In een echt end-to-end scenario zouden deze services duurdere bewerkingen uitvoeren, zoals database-aanroepen, waardoor de invloed van de prestaties van de transportlaag minder belangrijk is. Dit plus de voordelen van de functies die beschikbaar zijn in WF4 maakt Workflow Foundation een haalbare keuze voor het maken van indelingsservices.
Belangrijke prestatieoverwegingen
De functiegebieden in deze sectie, met uitzondering van interoperabiliteit, zijn aanzienlijk gewijzigd tussen WF3 en WF4. Dit is van invloed op het ontwerp van werkstroomtoepassingen en de prestaties.
Latentie van werkstroomactivering
In een WCF-werkstroomservicetoepassing is de latentie voor het starten van een nieuwe werkstroom of het laden van een bestaande werkstroom belangrijk omdat deze kan worden geblokkeerd. In deze testcase wordt een WF3 XOML-host vergeleken met een WF4 XAMLX-host in een typisch scenario.
Configuratie van de omgeving
Installatie testen
In het scenario neemt een clientcomputer contact op met een WCF-werkstroomservice met behulp van contextgebaseerde correlatie. Contextcorrelatie vereist een speciale contextbinding en gebruikt een contextheader of cookie om berichten te relateren aan het juiste werkstroomexemplaren. Het heeft een prestatievoordeel omdat de correlatie-id zich in de berichtkop bevindt, zodat de berichttekst niet hoeft te worden geparseerd.
De service maakt een nieuwe werkstroom met de aanvraag en verzendt een onmiddellijke reactie, zodat de meting van latentie niet de tijd omvat die nodig is om de werkstroom uit te voeren. De WF3-werkstroom is XOML met een code-behind en de WF4-werkstroom is volledig XAML. De WF4-werkstroom ziet er als volgt uit:
De Receive activiteit maakt het werkstroomexemplaren. Een waarde die is doorgegeven in het ontvangen bericht, wordt in het antwoordbericht herhaald. Een reeks na het antwoord bevat de rest van de werkstroom. In het bovenstaande geval wordt slechts één opmerkingsactiviteit weergegeven. Het aantal opmerkingenactiviteiten wordt gewijzigd om werkstroomcomplexiteit te simuleren. Een opmerkingsactiviteit is gelijk aan een WF3 CodeActivity die geen werk uitvoert. Zie de sectie Prestatievergelijking op onderdeelniveau eerder in dit artikel voor meer informatie over de opmerkingsactiviteit.
Testresultaten
Koude en warme latentie voor WCF-werkstroomservices:
In het vorige diagram verwijst cold naar het geval dat er geen bestaande WorkflowServiceHost is voor de opgegeven werkstroom. Met andere woorden, koude latentie is wanneer de werkstroom voor het eerst wordt gebruikt en de XOML of XAML moet worden gecompileerd. Warme latentie is het moment om een nieuw werkstroomexemplaren te maken wanneer het werkstroomtype al is gecompileerd. De complexiteit van de werkstroom maakt weinig verschil in de WF4-zaak, maar heeft een lineaire voortgang in de WF3-zaak.
Correlatiedoorvoer
WF4 introduceert een nieuwe correlatiefunctie op basis van inhoud. WF3 biedt alleen correlatie op basis van context. Correlatie op basis van context kan alleen worden uitgevoerd via specifieke WCF-kanaalbindingen. De werkstroom-id wordt ingevoegd in de berichtkop wanneer u deze bindingen gebruikt. De WF3-runtime kan alleen een werkstroom identificeren op basis van de id. Met correlatie op basis van inhoud kan de auteur van de werkstroom een correlatiesleutel maken op basis van een relevant stukje gegevens, zoals een accountnummer of klant-id.
Correlatie op basis van context heeft een prestatievoordeel omdat de correlatiesleutel zich in de berichtkop bevindt. De sleutel kan worden gelezen uit het bericht zonder de serialisatie/het kopiëren van berichten. In correlatie op basis van inhoud wordt de correlatiesleutel opgeslagen in de berichttekst. Er wordt een XPath-expressie gebruikt om de sleutel te vinden. De kosten van deze extra verwerking zijn afhankelijk van de grootte van het bericht, de diepte van de sleutel in de hoofdtekst en het aantal sleutels. Deze test vergelijkt de correlatie op basis van context en inhoud en toont ook de prestatievermindering bij het gebruik van meerdere sleutels.
Configuratie van de omgeving
Installatie testen
De vorige werkstroom is hetzelfde werkstroom dat wordt gebruikt in de sectie Persistentie . Voor de correlatietests zonder persistentie is er geen persistentieprovider geïnstalleerd in de runtime. Correlatie vindt plaats op twee plaatsen: CreateOrder en CompleteOrder.
Testresultaten
In deze grafiek ziet u een afname van de prestaties naarmate het aantal sleutels dat wordt gebruikt in correlatie op basis van inhoud toeneemt. De overeenkomst in de curven tussen TCP en HTTP geeft de overhead aan die aan deze protocollen is gekoppeld.
Correlatie met persistentie
Met een persistente werkstroom verschuift de CPU-druk van op inhoud gebaseerde correlatie van de werkstroomruntime naar de SQL-database. De opgeslagen procedures in de SQL-persistentieprovider doen het werk van het koppelen van de sleutels om de juiste werkstroom te vinden.
Correlatie op basis van context is nog steeds sneller dan correlatie op basis van inhoud. Het verschil is echter minder uitgesproken omdat persistentie meer invloed heeft op prestaties dan correlatie.
Complexe werkstroomdoorvoer
De complexiteit van een werkstroom wordt niet alleen gemeten door het aantal activiteiten. Samengestelde activiteiten kunnen veel kinderen bevatten en die kinderen kunnen ook samengestelde activiteiten zijn. Naarmate het aantal nestniveaus toeneemt, neemt het aantal activiteiten dat momenteel in de uitvoeringsstatus kan staan en het aantal variabelen dat de status kan hebben, toe. Met deze test wordt de doorvoer tussen WF3 en WF4 vergeleken bij het uitvoeren van complexe werkstromen.
Installatie testen
Deze tests zijn uitgevoerd op een Intel Xeon X5355 @ 2,66GHz 4-wegcomputer met 4 GB RAM met Windows Server 2008 x64. De testcode wordt uitgevoerd in één proces met één thread per kern om het CPU-gebruik van 100% te bereiken.
De werkstromen die voor deze test worden gegenereerd, hebben twee hoofdvariabelen: diepte en aantal activiteiten in elke reeks. Elk diepteniveau omvat een parallelle activiteit, terwijl lus, beslissingen, toewijzingen en reeksen. In de onderstaande WF4-ontwerpfunctie wordt het stroomdiagram op het hoogste niveau weergegeven. Elke stroomdiagramactiviteit lijkt op het hoofdstroomdiagram. Het kan handig zijn om een fractaal te bedenken bij het weergeven van deze werkstroom, waarbij de diepte beperkt is tot de parameters van de test.
Het aantal activiteiten in een bepaalde test wordt bepaald door de diepte en het aantal activiteiten per reeks. Met de volgende vergelijking wordt het aantal activiteiten in de WF4-test berekend:
Het aantal activiteiten van de WF3-test kan worden berekend met een iets andere vergelijking vanwege een extra reeks:
Waarbij d de diepte is en een is het aantal activiteiten per reeks. De logica achter deze vergelijkingen is dat de eerste constante, vermenigvuldigd met a, het aantal reeksen is en de tweede constante het statische aantal activiteiten in het huidige niveau is. Er zijn drie onderliggende activiteiten voor stroomdiagrammen in elk stroomdiagram. Op het diepteniveau onderaan zijn deze stroomdiagrammen leeg, maar op de andere niveaus zijn ze kopieën van het hoofdstroomdiagram. Het aantal activiteiten in de werkstroomdefinitie van elke testvariatie wordt aangegeven in de volgende tabel:
Het aantal activiteiten in de werkstroomdefinitie neemt sterk toe met elk diepteniveau. Maar slechts één pad per beslissingspunt wordt uitgevoerd in een bepaald werkstroomexemplaren, dus er wordt slechts een kleine subset van de werkelijke activiteiten uitgevoerd.
Er is een equivalente werkstroom gemaakt voor WF3. De WF3-ontwerpfunctie toont de hele werkstroom in het ontwerpgebied in plaats van nesten, daarom is het te groot om in dit onderwerp weer te geven. Hieronder ziet u een fragment van de werkstroom.
Als u wilt oefenen met nesten in een extreem geval, gebruikt een andere werkstroom die deel uitmaakt van deze test 100 geneste reeksen. In de binnenste reeks is één Comment of CodeActivity.
Tracering en persistentie worden niet gebruikt als onderdeel van deze test.
Testresultaten
Zelfs bij complexe werkstromen met veel diepte en een groot aantal activiteiten zijn de prestatieresultaten consistent met andere doorvoernummers die eerder in dit artikel worden weergegeven. De doorvoer van WF4 is sneller en moet worden vergeleken op een logaritmische schaal.
Geheugen
De geheugenoverhead van Windows Workflow Foundation wordt gemeten op twee belangrijke gebieden: werkstroomcomplexiteit en het aantal werkstroomdefinities. Geheugenmetingen zijn uitgevoerd op een Windows 7 64-bits werkstation. Er zijn veel manieren om de grootte van de werkset te verkrijgen, zoals het bewaken van prestatiemeteritems, polling Environment.WorkingSet of het gebruik van een hulpprogramma zoals VMMap dat beschikbaar is via VMMap. Er is een combinatie van methoden gebruikt om de resultaten van elke test te verkrijgen en te verifiëren.
Werkstroomcomplexiteitstest
De werkstroomcomplexiteitstest meet het werksetverschil op basis van de complexiteit van de werkstroom. Naast de complexe werkstromen die in de vorige sectie worden gebruikt, worden er nieuwe variaties toegevoegd om twee basiscases te behandelen: één activiteitswerkstroom en een reeks met 1000 activiteiten. Voor deze tests worden de werkstromen geïnitialiseerd en uitgevoerd tot voltooiing in één seriële lus gedurende een periode van één minuut. Elke testvariatie wordt drie keer uitgevoerd en de vastgelegde gegevens zijn het gemiddelde van deze drie uitvoeringen.
De twee nieuwe basistests hebben werkstromen die er als volgt uitzien:
In de hierboven weergegeven WF3-werkstroom worden lege CodeActivity activiteiten gebruikt. De bovenstaande WF4-werkstroom maakt gebruik van Comment activiteiten. De Comment activiteit is beschreven in de sectie Prestatievergelijkingen op onderdeelniveau eerder in dit artikel.
Een van de duidelijke trends in deze grafiek is dat nesten relatief weinig invloed heeft op het geheugengebruik in zowel WF3 als WF4. De belangrijkste geheugenimpact is afkomstig van het aantal activiteiten in een bepaalde werkstroom. Gezien de gegevens uit de reeks 1000, complexe diepte 5 reeks 5 en complexe diepte 7 reeks 1 variaties, is het duidelijk dat wanneer het aantal activiteiten de duizenden binnenkomt, de toename van het geheugengebruik duidelijker wordt. In het extreme geval (diepte 7 reeks 1) waarbij er ~29.000 activiteiten zijn, gebruikt WF4 bijna 79% minder geheugen dan WF3.
Test voor meerdere werkstroomdefinities
Het meten van geheugen per werkstroomdefinitie is onderverdeeld in twee verschillende tests vanwege de beschikbare opties voor het hosten van werkstromen in WF3 en WF4. De tests worden op een andere manier uitgevoerd dan de werkstroomcomplexiteitstest omdat een bepaalde werkstroom wordt geïnexempeerd en slechts eenmaal per definitie wordt uitgevoerd. Dit komt doordat de werkstroomdefinitie en de bijbehorende host gedurende de levensduur van het AppDomain in het geheugen blijven. Het geheugen dat wordt gebruikt door een bepaald werkstroomexemplaren uit te voeren, moet worden opgeschoond tijdens de garbagecollection. De migratierichtlijnen voor WF4 bevatten meer gedetailleerde informatie over de hostingopties. Zie WF Migration Cookbook: Workflow Hosting voor meer informatie.
Het maken van veel werkstroomdefinities voor een werkstroomdefinitietest kan op verschillende manieren worden uitgevoerd. U kunt bijvoorbeeld codegeneratie gebruiken om een set van 1000 werkstromen te maken die identiek zijn, behalve in naam en elk van deze werkstromen opslaan in afzonderlijke bestanden. Deze benadering is gebruikt voor de door de console gehoste test. In WF3 is de WorkflowRuntime klasse gebruikt om de werkstroomdefinities uit te voeren. WF4 kan worden gebruikt WorkflowApplication om één werkstroomexemplaren te maken of rechtstreeks te gebruiken WorkflowInvoker om de activiteit uit te voeren alsof het een methode-aanroep was. WorkflowApplication is een host van één werkstroomexemplaren en heeft een betere functiepariteit, WorkflowRuntime zodat deze in deze test is gebruikt.
Bij het hosten van werkstromen in IIS is het mogelijk om een VirtualPathProvider nieuwe WorkflowServiceHost te maken in plaats van alle XAMLX- of XOML-bestanden te genereren. De VirtualPathProvider verwerking van de binnenkomende aanvraag en reageert met een 'virtueel bestand' dat kan worden geladen vanuit een database of, in dit geval, gegenereerd op het moment. Het is daarom niet nodig om 1000 fysieke bestanden te maken.
De werkstroomdefinities die in de consoletest worden gebruikt, waren eenvoudige opeenvolgende werkstromen met één activiteit. De enkele activiteit was leeg CodeActivity voor de WF3-aanvraag en een Comment activiteit voor de WF4-aanvraag. De door IIS gehoste case heeft werkstromen gebruikt die beginnen met het ontvangen van een bericht en eindigen bij het verzenden van een antwoord:
In de volgende afbeelding ziet u een WF3-werkstroom met ReceiveActivity en een WF4-werkstroom met een aanvraag-/antwoordpatroon:
In de volgende tabel ziet u de verschillen in de werkset tussen één werkstroomdefinitie en 1001-definities:
| Hostingopties | WF3-werkset Delta | WF4-werkset Delta |
|---|---|---|
| Gehoste werkstromen van consoletoepassing | 18 MB | 9 MB |
| Door IIS gehoste werkstroomservices | 446 MB | 364 MB |
Het hosten van werkstroomdefinities in IIS verbruikt veel meer geheugen vanwege de WorkflowServiceHostgedetailleerde WCF-serviceartefacten en de logica voor berichtverwerking die aan de host is gekoppeld.
Voor consolehosting in WF3 zijn de werkstromen geïmplementeerd in code in plaats van XOML. In WF4 wordt standaard XAML gebruikt. De XAML wordt opgeslagen als een ingesloten resource in de assembly en gecompileerd tijdens runtime om de implementatie van de werkstroom te bieden. Er is enige overhead verbonden aan dit proces. Om een eerlijke vergelijking te maken tussen WF3 en WF4, werden gecodeerde werkstromen gebruikt in plaats van XAML. Hieronder ziet u een voorbeeld van een van de WF4-werkstromen:
public class Workflow1 : Activity
{
protected override Func<Activity> Implementation
{
get
{
return new Func<Activity>(() =>
{
return new Sequence
{
Activities = {
new Comment()
}
};
});
}
set
{
base.Implementation = value;
}
}
}
Er zijn veel andere factoren die van invloed kunnen zijn op het geheugenverbruik. Hetzelfde advies voor alle beheerde programma's is nog steeds van toepassing. In door IIS gehoste omgevingen blijft het object dat is gemaakt voor een werkstroomdefinitie in het WorkflowServiceHost geheugen totdat de groep van toepassingen wordt gerecycled. Dit moet in gedachten worden gehouden bij het schrijven van extensies. Het is ook raadzaam om 'globale' variabelen (variabelen binnen het bereik van de hele werkstroom) te vermijden en waar mogelijk het bereik van variabelen te beperken.
Werkstroomruntimeservices
Persistentie
WF3 en WF4 worden beide geleverd met een SQL-persistentieprovider. De WF3 SQL-persistentieprovider is een eenvoudige implementatie waarmee het werkstroomexemplaren worden geserialiseerd en opgeslagen in een blob. Daarom zijn de prestaties van deze provider sterk afhankelijk van de grootte van het werkstroomexemplaren. In WF3 kan de instantiegrootte om verschillende redenen toenemen, zoals eerder in dit document is besproken. Veel klanten kiezen ervoor om de standaard SQL-persistentieprovider niet te gebruiken, omdat het opslaan van een geserialiseerd exemplaar in een database geen inzicht geeft in de status van de werkstroom. Als u een bepaalde werkstroom wilt vinden zonder de werkstroom-id te kennen, moet u elk persistent exemplaar deserialiseren en de inhoud onderzoeken. Veel ontwikkelaars schrijven liever hun eigen persistentieproviders om dit obstakel te overwinnen.
De WF4 SQL-persistentieprovider heeft geprobeerd een aantal van deze problemen op te lossen. De persistentietabellen bevatten bepaalde informatie, zoals de actieve bladwijzers en promotieeigenschappen. De nieuwe functie voor correlatie op basis van inhoud in WF4 presteert niet goed met behulp van de WF3 SQL-persistentiebenadering, die enige verandering heeft veroorzaakt in de organisatie van het persistente werkstroomexemplaren. Dit maakt de taak van de persistentieprovider complexer en brengt extra stress in de database.
Configuratie van de omgeving
Installatie testen
Zelfs met een verbeterde functieset en betere gelijktijdigheidsafhandeling is de SQL-persistentieprovider in WF4 sneller dan de provider in WF3. Om dit te laten zien, worden twee werkstromen die in feite dezelfde bewerkingen uitvoeren in WF3 en WF4 hieronder vergeleken.
De twee werkstromen worden beide gemaakt door een ontvangen bericht. Nadat u een eerste antwoord hebt verzonden, blijft de werkstroom behouden. In het geval WF3 wordt een lege TransactionScopeActivity wordt gebruikt om de persistentie te initiëren. Hetzelfde kan worden bereikt in WF3 door een activiteit te markeren als 'behouden bij sluiten'. Een tweede, gecorreleerd bericht voltooit de werkstroom. De werkstromen blijven behouden, maar worden niet uitgeladen.
Testresultaten
Wanneer het transport tussen de client en de middelste laag HTTP is, toont persistentie in WF4 een verbetering van 2,6 keer. Het TCP-transport verhoogt die factor tot 3,0 keer. In alle gevallen is het CPU-gebruik op de middelste laag 98% of hoger. De reden waarom WF4-doorvoer groter is, is vanwege de snellere werkstroomruntime. De grootte van het geserialiseerde exemplaar is laag voor beide gevallen en is geen belangrijk element in deze situatie.
Zowel de WF3- als de WF4-werkstromen in deze test gebruiken een activiteit om expliciet aan te geven wanneer persistentie moet plaatsvinden. Dit heeft het voordeel van het behouden van de werkstroom zonder deze te lossen. In WF3 is het ook mogelijk om het gebruik van de TimeToUnload functie te behouden, maar hiermee wordt het werkstroomexemplaren uit het geheugen verwijderd. Als een ontwikkelaar die WF3 gebruikt, op bepaalde punten een werkstroom wil behouden, moet deze de werkstroomdefinitie wijzigen of de kosten betalen voor het lossen en opnieuw laden van het werkstroomexemplaren. Een nieuwe functie in WF4 maakt het mogelijk om te blijven bestaan zonder te lossen: TimeToPersist. Met deze functie kan het werkstroomexemplaren inactief blijven, maar in het geheugen blijven totdat aan de TimeToUnload drempelwaarde wordt voldaan of de uitvoering wordt hervat.
Houd er rekening mee dat de WF4 SQL-persistentieprovider meer werk uitvoert in de databaselaag. De SQL-database kan een knelpunt worden, zodat het belangrijk is om het CPU- en schijfgebruik daar te bewaken. Zorg ervoor dat u de volgende prestatiemeteritems uit de SQL-database opneemt bij het testen van werkstroomtoepassingen voor prestaties:
Leestijd van physicalDisk\%schijf
PhysicalDisk\% schijftijd
Schrijftijd voor fysieke schijf\%
PhysicalDisk\% avg. Lengte van schijfwachtrij
PhysicalDisk\Avg. Schijf leeswachtrijlengte
PhysicalDisk\Avg. Schrijfwachtrijlengte schijf
Lengte van fysieke schijf\huidige schijfwachtrij
Processorinformatie\% processortijd
SQLServer:Latches\Average Latch Wait Time (ms)
SQLServer:Latches\Latch Waits/sec
Bijhouden
Werkstroomtracking kan worden gebruikt om de voortgang van een werkstroom bij te houden. De informatie die is opgenomen in de traceringsgebeurtenissen, wordt bepaald door een traceringsprofiel. Hoe complexer het traceringsprofiel, hoe duurder het bijhouden wordt.
WF3 wordt geleverd met een traceringsservice op basis van SQL. Deze service kan werken in batchmodus en niet-batchgewijs. In de niet-batchmodus worden traceringsgebeurtenissen rechtstreeks naar de database geschreven. In de batchmodus worden traceringsgebeurtenissen verzameld in dezelfde batch als de status van het werkstroomexemplaren. De batchmodus heeft de beste prestaties voor het breedste scala aan werkstroomontwerpen. Batchverwerking kan echter een negatieve invloed hebben op de prestaties als de werkstroom veel activiteiten uitvoert zonder persistent te blijven en deze activiteiten worden bijgehouden. Dit gebeurt meestal in lussen en de beste manier om dit scenario te voorkomen, is door grote lussen te ontwerpen om een persistentiepunt te bevatten. Het introduceren van een persistentiepunt in een lus kan ook een negatieve invloed hebben op de prestaties, zodat het belangrijk is om de kosten van elk punt te meten en een evenwicht te vinden.
WF4 wordt niet geleverd met een SQL-traceringsservice. Het vastleggen van traceringsgegevens naar een SQL-database kan beter worden verwerkt vanuit een toepassingsserver in plaats van ingebouwd in .NET Framework. Daarom wordt SQL-tracering nu verwerkt door AppFabric. De out-of-the-box tracking provider in WF4 is gebaseerd op Event Tracing for Windows (ETW).
ETW is een gebeurtenissysteem op kernelniveau met lage latentie dat is ingebouwd in Windows. Het maakt gebruik van een provider-/consumentenmodel waarmee alleen de boete voor gebeurtenistracering kan worden opgelegd wanneer er daadwerkelijk een consument is. Naast kernel-gebeurtenissen zoals processor, schijf, geheugen en netwerkgebruik maken veel toepassingen ook gebruik van ETW. ETW-gebeurtenissen zijn krachtiger dan prestatiemeteritems in die gebeurtenissen kunnen worden aangepast aan de toepassing. Een gebeurtenis kan tekst bevatten, zoals een werkstroom-id of een informatief bericht. Bovendien worden gebeurtenissen gecategoriseerd met bitmaskers, zodat het verbruik van een bepaalde subset van gebeurtenissen minder invloed heeft op de prestaties dan het vastleggen van alle gebeurtenissen.
Voordelen van het gebruik van ETW voor tracering in plaats van SQL zijn:
Het verzamelen van traceringsevenementen kan worden gescheiden door een ander proces. Dit biedt meer flexibiliteit in de wijze waarop de gebeurtenissen worden vastgelegd.
ETW-traceringsevenementen worden eenvoudig gecombineerd met de WCF ETW-gebeurtenissen of andere ETW-providers, zoals een SQL Server- of kernelprovider.
Werkstroomauteurs hoeven een werkstroom niet te wijzigen om beter te kunnen werken met een bepaalde tracerings-implementatie, zoals de batchmodus van de WF3 SQL-traceringsservice.
Een beheerder kan tracering in- of uitschakelen zonder het hostproces te recyclen.
De prestatievoordelen voor ETW-tracering hebben een nadeel. ETW-gebeurtenissen kunnen verloren gaan als het systeem onder intensieve resourcedruk staat. De verwerking van gebeurtenissen is niet bedoeld om de normale uitvoering van programma's te blokkeren en daarom is het niet gegarandeerd dat alle ETW-gebeurtenissen worden uitgezonden naar hun abonnees. Dit maakt ETW-tracering geweldig voor statuscontrole, maar niet geschikt voor controle.
Hoewel WF4 geen SQL-traceringsprovider heeft, doet AppFabric dat wel. De SQL-traceringsbenadering van AppFabric is het abonneren op ETW-gebeurtenissen met een Windows-service die de gebeurtenissen batcheert en schrijft naar een SQL-tabel die is ontworpen voor snelle invoegingen. Met een afzonderlijke taak worden de gegevens uit deze tabel verwijderd en wordt deze omgezet in rapportagetabellen die op het AppFabric-dashboard kunnen worden weergegeven. Dit betekent dat een batch traceringsgebeurtenissen wordt verwerkt, onafhankelijk van de werkstroom waaruit deze afkomstig is en daarom niet hoeft te wachten op een persistentiepunt voordat deze wordt vastgelegd.
ETW-gebeurtenissen kunnen worden vastgelegd met hulpprogramma's zoals logman of xperf. Het compacte ETL-bestand kan worden weergegeven met een hulpprogramma zoals xperfview of geconverteerd naar een beter leesbare indeling, zoals XML, met tracerpt. In WF3 is de enige optie voor het ophalen van tracking-gebeurtenissen zonder een SQL-database het maken van een aangepaste traceringsservice. Zie WCF Services en Event Tracing voor Windows - en Event Tracing - Windows-toepassingen voor meer informatie over ETW.
Het inschakelen van werkstroomtracking heeft invloed op de prestaties in verschillende mate. In de onderstaande benchmark wordt het hulpprogramma logman gebruikt om de ETW-traceringsevenementen te gebruiken en vast te leggen in een ETL-bestand. De kosten van het bijhouden van SQL in AppFabric vallen niet binnen het bereik van dit artikel. Het basistraceringsprofiel, dat ook wordt gebruikt in AppFabric, wordt weergegeven in deze benchmark. Ook inbegrepen zijn de kosten voor het bijhouden van alleen statuscontrolegebeurtenissen. Deze gebeurtenissen zijn handig voor het oplossen van problemen en het bepalen van de gemiddelde doorvoer van het systeem.
Configuratie van de omgeving
Testresultaten
Statuscontrole heeft ongeveer 3% invloed op doorvoer. De kosten van het basisprofiel bedragen ongeveer 8%.
Interop
WF4 is bijna een volledige herschrijf van WF en daarom zijn WF3-werkstromen en -activiteiten niet rechtstreeks compatibel met WF4. Veel klanten die Windows Workflow Foundation vroeg gebruiken, hebben interne of externe werkstroomdefinities en aangepaste activiteiten voor WF3. Een manier om de overgang naar WF4 te vereenvoudigen, is door de Interop-activiteit te gebruiken, waarmee WF3-activiteiten vanuit een WF4-werkstroom kunnen worden uitgevoerd. Het wordt aanbevolen om de Interop activiteit alleen te gebruiken wanneer dat nodig is. Raadpleeg de WF4-migratierichtlijnen voor meer informatie over migreren naar WF4.
Configuratie van de omgeving
Testresultaten
In de volgende tabel ziet u de resultaten van het uitvoeren van een werkstroom met vijf activiteiten in een reeks in verschillende configuraties.
| Testen | Doorvoer (werkstromen per seconde) |
|---|---|
| WF3-reeks in WF3-runtime | 1,576 |
| WF3-reeks in WF4-runtime met behulp van Interop | 2,745 |
| WF4-reeks | 153,582 |
Er is een opmerkelijke prestatieverhoging voor het gebruik van Interop via rechte WF3. In vergelijking met WF4-activiteiten is de toename echter te verwaarlozen.
Samenvatting
Zware investeringen in prestaties voor WF4 hebben op veel cruciale gebieden afbetaald. Prestaties van afzonderlijke werkstroomonderdelen zijn in sommige gevallen honderden keren sneller in WF4 in vergelijking met WF3 vanwege een slankere WF-runtime. Latentienummers zijn ook aanzienlijk beter. Dit betekent dat de prestatiestraf voor het gebruik van WF in plaats van handcodering van WCF-indelingsservices zeer klein is, gezien de toegevoegde voordelen van het gebruik van WF. De persistentieprestaties zijn met een factor van 2,5 - 3,0 toegenomen. Statuscontrole door middel van werkstroomtracering heeft nu zeer weinig overhead. Er is een uitgebreide set migratiehandleidingen beschikbaar voor degenen die overwegen om over te stappen van WF3 naar WF4. Dit alles moet WF4 een aantrekkelijke optie maken voor het schrijven van complexe toepassingen.
