Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
.NET Framework 4 enthält eine wichtige Überarbeitung der Windows Workflow Foundation (WF) mit umfangreichen Investitionen in die Leistung. Diese neue Revision führt erhebliche Entwurfsänderungen aus den vorherigen Versionen von WF ein, die als Teil von .NET Framework 3.0 und .NET Framework 3.5 ausgeliefert wurden. Es wurde vom Kern des Programmiermodells, der Laufzeit und der Tools neu entwickelt, um die Leistung und Benutzerfreundlichkeit erheblich zu verbessern. Dieses Thema zeigt die wichtigen Leistungsmerkmale dieser Überarbeitungen und vergleicht sie mit denen der vorherigen Version.
Die Leistung einzelner Workflowkomponenten hat sich um Größenordnungen zwischen WF3 und WF4 erhöht. Dadurch bleibt die Lücke zwischen handcodierten Windows Communication Foundation (WCF)-Diensten und WCF-Workflowdiensten recht klein. Die Workflowlatenz wurde in WF4 erheblich reduziert. Die Persistenzleistung ist um den Faktor 2,5 - 3,0 gestiegen. Die Gesundheitsüberwachung durch Workflownachverfolgung hat deutlich weniger Aufwand. Dies sind überzeugende Gründe, um zu WF4 in Ihren Anwendungen zu migrieren oder es zu übernehmen.
Terminologie
Die in .NET Framework 4 eingeführte WF-Version wird für den Rest dieses Themas als WF4 bezeichnet. WF wurde in .NET Framework 3.0 eingeführt und hatte einige kleinere Überarbeitungen über .NET Framework 3.5 SP1. Die .NET Framework 3.5-Version von Workflow Foundation wird für den Rest dieses Themas als WF3 bezeichnet. WF3 wird in .NET Framework 4 parallel mit WF4 ausgeliefert. Weitere Informationen zum Migrieren von WF3-Artefakten zu WF4 finden Sie im Windows Workflow Foundation 4-Migrationshandbuch.
Windows Communication Foundation (WCF) ist das einheitliche Programmiermodell von Microsoft zum Erstellen dienstorientierter Anwendungen. Es wurde zunächst zusammen mit WF3 als Teil von .NET Framework 3.0 eingeführt und ist jetzt eine der wichtigsten Komponenten von .NET Framework.
Windows Server AppFabric ist eine Reihe integrierter Technologien, die das Erstellen, Skalieren und Verwalten von Web- und Verbundanwendungen erleichtern, die auf IIS ausgeführt werden. Es bietet Tools zum Überwachen und Verwalten von Diensten und Workflows. Weitere Informationen finden Sie unter Windows Server AppFabric 1.0.
Ziele
Ziel dieses Themas ist es, die Leistungsmerkmale von WF4 mit daten zu zeigen, die für verschiedene Szenarien gemessen werden. Es bietet auch detaillierte Vergleiche zwischen WF4 und WF3 und zeigt somit die großen Verbesserungen, die in dieser neuen Überarbeitung vorgenommen wurden. Die in diesem Artikel vorgestellten Szenarien und Daten quantifizieren die zugrunde liegenden Kosten verschiedener Aspekte von WF4 und WF3. Diese Daten sind nützlich, um die Leistungsmerkmale von WF4 zu verstehen und kann bei der Planung von Migrationen von WF3 zu WF4 oder bei der Verwendung von WF4 in der Anwendungsentwicklung hilfreich sein. Die Schlussfolgerungen aus den in diesem Artikel vorgestellten Daten sollten jedoch berücksichtigt werden. Die Leistung einer zusammengesetzten Workflowanwendung hängt stark davon ab, wie der Workflow implementiert wird und wie verschiedene Komponenten integriert werden. Eine muss jede Anwendung messen, um die Leistungsmerkmale dieser Anwendung zu bestimmen.
Übersicht über WF4-Leistungsverbesserungen
WF4 wurde sorgfältig entworfen und mit hoher Leistung und Skalierbarkeit implementiert, die in den folgenden Abschnitten beschrieben werden.
WF-Laufzeit
Kern der WF-Laufzeit ist ein asynchroner Scheduler, der die Ausführung der Aktivitäten in einem Workflow steuert. Sie stellt eine leistungsfähige, vorhersehbare Ausführungsumgebung für Aktivitäten bereit. Die Umgebung verfügt über einen gut definierten Vertrag für Ausführung, Fortsetzung, Abschluss, Abbruch, Ausnahmen und ein vorhersehbares Threadingmodell.
Im Vergleich zu WF3 verfügt die WF4-Laufzeit über einen effizienteren Scheduler. Er nutzt den gleichen E/A-Threadpool, der für WCF verwendet wird, was bei der Ausführung von Batcharbeitselementen sehr effizient ist. Die interne Arbeitsaufgabenplanungswarteschlange ist für die häufigsten Verwendungsmuster optimiert. Die WF4-Laufzeit verwaltet auch die Ausführungszustände auf sehr einfache Weise mit minimalem Synchronisations- und Ereignisbehandlungsaufwand, während WF3 auf aufwändige Ereignisregistrierung und Aufrufe angewiesen ist, um komplexe Synchronisierungen für Zustandsübergänge durchzuführen.
Datenspeicherung und -fluss
In WF3 werden daten, die einer Aktivität zugeordnet sind, durch Abhängigkeitseigenschaften modelliert, die vom Typ DependencyPropertyimplementiert werden. Das Abhängigkeitseigenschaftsmuster wurde in Windows Presentation Foundation (WPF) eingeführt. Im Allgemeinen ist dieses Muster sehr flexibel, um einfache Datenbindung und andere UI-Features zu unterstützen. Das Muster erfordert jedoch, dass die Eigenschaften in der Workflowdefinition als statische Felder definiert werden. Jedes Mal, wenn die WF-Laufzeit die Eigenschaftswerte festlegt oder abruft, wird eine komplexe Suchlogik angewendet.
WF4 verwendet klare Datendefinitionslogik, um die Verarbeitung von Daten in einem Workflow erheblich zu verbessern. Sie trennt die in einer Aktivität gespeicherten Daten von den Daten, die über die Aktivitätsgrenzen fließen, indem sie zwei verschiedene Konzepte verwenden: Variablen und Argumente. Da ein klarer hierarchischer Bereich für Variablen und „In/Out-/InOut“-Argumente verwendet wird, wird die Datenverwendungskomplexität für Aktivitäten dramatisch reduziert, und die Lebensdauer der Daten wird ebenfalls automatisch bewertet. Aktivitäten weisen eine gut definierte Signatur auf, die durch ihre Argumente beschrieben wird. Indem Sie eine Aktivität einfach untersuchen, können Sie bestimmen, welche Daten sie zu empfangen erwartet und welche Daten als Ergebnis ihrer Ausführung produziert werden.
WF3-Aktivitäten wurden initialisiert, wenn ein Workflow erstellt wurde. Aktivitäten in WF 4 werden nur dann initialisiert, wenn die entsprechenden Aktivitäten ausgeführt werden. Dies ermöglicht einen einfacheren Aktivitätslebenszyklus, ohne Initialize/Uninitialize-Vorgänge auszuführen, wenn eine neue Workflowinstanz erstellt wird und somit mehr Effizienz erzielt hat.
Kontrollfluss
Genau wie in jeder Programmiersprache bietet WF Unterstützung für Steuerungsflüsse für Workflowdefinitionen, indem eine Reihe von Steuerungsflussaktivitäten für Sequenzierung, Schleifen, Verzweigung und andere Muster eingeführt werden. In WF3, wenn dieselbe Aktivität erneut ausgeführt werden muss, wird eine neue ActivityExecutionContext erstellt, und die Aktivität wird mittels ressourcenintensiver Serialisierungs- und Deserialisierungslogik basierend auf BinaryFormatter geklont. In der Regel ist die Leistung für iterative Kontrollflüsse viel langsamer als die Ausführung einer Abfolge von Aktivitäten.
WF4 behandelt dies ganz anders. Es verwendet die Aktivitätsvorlage, erstellt ein neues ActivityInstance -Objekt und fügt es der Schedulerwarteschlange hinzu. Dieser gesamte Prozess umfasst nur die explizite Objekterstellung und ist sehr leicht.
Asynchrone Programmierung
Anwendungen verfügen in der Regel über eine bessere Leistung und Skalierbarkeit mit asynchroner Programmierung für lange ausgeführte Blockierungsvorgänge wie E/A oder verteilte Computervorgänge. WF4 bietet asynchrone Unterstützung über Basisaktivitätstypen AsyncCodeActivity, AsyncCodeActivity<TResult>. Die Laufzeit versteht asynchrone Aktivitäten systemintern und kann daher die Instanz automatisch in eine Zone ohne Persistenz verschieben, während die asynchrone Arbeit aussteht. Benutzerdefinierte Aktivitäten können von diesen Typen abgeleitet werden, um asynchrone Arbeit auszuführen, ohne den Workflowplanerthread zu halten und alle Aktivitäten zu blockieren, die parallel ausgeführt werden können.
Nachrichtenübermittlung
Anfänglich hatte WF3 sehr beschränkte Messagingunterstützung über externe Ereignisse oder Webdienstaufrufe. In .NET Framework 3.5 können Workflows als WCF-Clients implementiert oder als WCF-Dienste über SendActivity und ReceiveActivityverfügbar gemacht werden. In WF4 wurde das Konzept der workflowbasierten Messaging-Programmierung durch die enge Integration von WCF-Messaginglogik in WF weiter gestärkt.
Die in WCF in .NET 4 bereitgestellte Vereinheitlichte Nachrichtenverarbeitungspipeline hilft WF4-Diensten, deutlich bessere Leistung und Skalierbarkeit als WF3 zu erzielen. WF4 bietet auch eine umfassendere Unterstützung für die Messagingprogrammierung, die komplexe Nachrichtenaustauschmuster (MEPs) modelliert. Entwickler können entweder typierte Serviceverträge verwenden, um einfache Programmierungs- oder untypierte Serviceverträge zu erzielen, um eine bessere Leistung zu erzielen, ohne serialisierungskosten zu bezahlen. Die clientseitige Kanalzwischenspeicherungsunterstützung über die SendMessageChannelCache Klasse in WF4 hilft Entwicklern, schnelle Anwendungen mit minimalem Aufwand zu erstellen. Weitere Informationen finden Sie unter Ändern der Cachefreigabeebenen für Sendeaktivitäten.
Deklarative Programmierung
WF4 bietet ein klares und einfaches deklaratives Programmierframework zum Modellieren von Geschäftsprozessen und -diensten. Das Programmiermodell unterstützt die vollständig deklarative Komposition von Aktivitäten ohne Code-Beside, was die Workflowerstellung sehr vereinfacht. In .NET Framework 4 wurde das XAML-basierte deklarative Programmierframework in die einzelne Assembly System.Xaml.dll vereinheitlicht, um sowohl WPF als auch WF zu unterstützen.
In WF4 bietet XAML eine wirklich deklarative Oberfläche und ermöglicht die vollständige Definition des Workflows in XML-Markup, verweisen auf Aktivitäten und Typen, die mit .NET erstellt wurden. Ohne Einbeziehen benutzerdefinierter Code-Behind-Logik war dies in WF3 mit dem XOML-Format schwierig. Der neue XAML-Stapel in .NET 4 verfügt über eine wesentlich bessere Leistung bei der Serialisierung/Deserialisierung von Workflowartefakten und macht die deklarative Programmierung attraktiver und solider.
Workflow-Designer
Vollständig deklarative Programmierungsunterstützung für WF4 erzwingt explizit höhere Anforderungen an die Entwurfszeitleistung für große Workflows. Der Workflow-Designer in WF4 hat für große Workflows viel bessere Skalierbarkeit als für WF3. Mit unterstützung der UI-Virtualisierung kann der Designer einen großen Workflow mit 1000 Aktivitäten in wenigen Sekunden problemlos laden, während es fast unmöglich ist, einen Workflow mit ein paar hundert Aktivitäten mit dem WF3-Designer zu laden.
Leistungsvergleiche auf Komponentenebene
Dieser Abschnitt enthält Daten zu direkten Vergleichen zwischen einzelnen Aktivitäten in WF3- und WF4-Workflows. Wichtige Bereiche wie Persistenz haben einen tieferen Einfluss auf die Leistung als die einzelnen Aktivitätskomponenten. Die Leistungsverbesserungen in einzelnen Komponenten in WF4 sind zwar wichtig, da die Komponenten nun schnell genug sind, um mit der handcodierten Orchestrierungslogik verglichen zu werden. Ein Beispiel hierfür wird im nächsten Abschnitt behandelt: "Dienstkompositions-Szenario".
Einrichtung der Umgebung
Die obige Abbildung zeigt die Computerkonfiguration, die für die Leistungsmessung auf Komponentenebene verwendet wird. Ein einzelner Server und fünf Clients, die über eine 1-Gbit/s Ethernet-Netzwerkschnittstelle verbunden sind. Für einfache Messungen ist der Server so konfiguriert, dass ein einzelner Kern eines Dual-Proc/Quad-Core-Servers unter Windows Server 2008 x86 verwendet wird. Die CPU-Auslastung des Systems wird bei annähernd 100 % gehalten.
Testdetails
Das WF3 CodeActivity ist wahrscheinlich die einfachste Aktivität, die in einem WF3-Workflow verwendet werden kann. Die Aktivität ruft eine Methode im Code-Behind auf, in die der Workflowprogrammierer benutzerdefinierten Code einfügen kann. In WF4 gibt es keine direkte Analogie zu WF3 CodeActivity , die die gleiche Funktionalität bereitstellt. Beachten Sie, dass es eine CodeActivity Basisklasse in WF4 gibt, die nicht mit dem WF3 CodeActivityverknüpft ist. Workflowautoren werden ermutigt, benutzerdefinierte Aktivitäten zu erstellen und NUR XAML-Workflows zu erstellen. In den folgenden Tests wird eine Aktivität namens Comment anstelle einer leeren CodeActivity in WF4 Workflows verwendet. Der Code in der Comment Aktivität lautet wie folgt:
[ContentProperty("Body")]
public sealed class Comment : CodeActivity
{
public Comment()
: base()
{
}
[DefaultValue(null)]
public Activity Body
{
get;
set;
}
protected override void Execute(CodeActivityContext context)
{
}
}
Leerer Workflow
Dieser Test verwendet einen Sequenzworkflow ohne untergeordnete Aktivitäten.
Einzelne Aktivität
Der Workflow ist ein Sequenzworkflow, der eine untergeordnete Aktivität enthält. Im WF3-Fall ist die Aktivität eine CodeActivity ohne Code und im WF4-Fall eine Comment Aktivität.
Bei 1000 Iterationen
Der Sequenzworkflow enthält eine While-Aktivität mit einer untergeordneten Aktivität in der Schleife, die keine Arbeit ausführt.
Replikationsdienst im Vergleich zu ParallelForEach
ReplicatorActivity in WF3 weist sequenzielle und parallele Ausführungsmodi auf. Im sequenziellen Modus ähnelt die Leistung der Aktivität dem WhileActivity. Dies ReplicatorActivity ist am nützlichsten für die parallele Ausführung. Das WF4-Analog dazu ist die ParallelForEach<T>-Aktivität.
Das folgende Diagramm zeigt die Workflows, die für diesen Test verwendet werden. Der WF3-Workflow befindet sich links und der WF4-Workflow befindet sich rechts.
Sequenzieller Workflow mit fünf Aktivitäten
Dieser Test soll zeigen, dass mehrere Aktivitäten sequenziert ausgeführt werden. Es gibt fünf Aktivitäten in der Sequenz.
Transaktionsbereich
Der Transaktionsbereichstest unterscheidet sich geringfügig von den anderen Tests, da für jede Iteration keine neue Workflowinstanz erstellt wird. Stattdessen ist der Workflow mit einer While-Schleife strukturiert, die eine TransactionScope Aktivität enthält, die eine einzelne Aktivität enthält, die nicht funktioniert. Jede Ausführung eines Batches von 50 Iterationen durch die While-Schleife wird als einzelner Vorgang gezählt.
Vergütung
Der WF3-Workflow verfügt über eine einzelne ausgleichbare Aktivität namens WorkScope. Die Aktivität implementiert einfach die ICompensatableActivity Schnittstelle:
class WorkScope :
CompositeActivity, ICompensatableActivity
{
public WorkScope() : base() { }
public WorkScope(string name)
{
this.Name = name;
}
public ActivityExecutionStatus Compensate(
ActivityExecutionContext executionContext)
{
return ActivityExecutionStatus.Closed;
}
}
Der Fehlerhandler zielt auf die WorkScope Aktivität ab. Der WF4-Workflow ist ebenso vereinfacht. Eine CompensableActivity verfügt über einen Textkörper und einen Kompensierungshandler. Als Nächstes folgt eine explizite Kompensierung in der Sequenz. Die Körperaktivität und die Kompensationshandleraktivität sind beide leere Implementierungen.
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) { }
}
Das folgende Diagramm zeigt den grundlegenden Vergütungsworkflow. Der WF3-Workflow befindet sich links und der WF4-Workflow befindet sich rechts.
Leistungstestergebnisse
Alle Tests werden in Workflows pro Sekunde gemessen, mit Ausnahme des Transaktionsbereichstests. Wie oben angezeigt, wurde die Leistung der WF-Laufzeit im gesamten System verbessert, insbesondere in Bereichen, die mehrere Ausführungen derselben Aktivität erfordern wie etwa die while-Schleife.
Dienstkompositionsszenario
Wie im vorherigen Abschnitt gezeigt, "Leistungsvergleiche auf Komponentenebene", wurde der Mehraufwand zwischen WF3 und WF4 erheblich reduziert. WCF-Workflowdienste können nun fast mit der Leistung von handcodierten WCF-Diensten übereinstimmen, aber dennoch alle Vorteile der WF-Laufzeit haben. In diesem Testszenario wird ein WCF-Dienst mit einem WCF-Workflowdienst in WF4 verglichen.
Online Store-Dienst
Eine der Stärken von Windows Workflow Foundation ist die Möglichkeit, Prozesse mit mehreren Diensten zu verfassen. In diesem Beispiel gibt es einen Online-Store-Dienst, der zwei Serviceanrufe zum Kauf einer Bestellung koordiniert. Der erste Schritt besteht darin, die Bestellung mithilfe eines Bestellüberprüfungsdiensts zu überprüfen. Der zweite Schritt besteht darin, den Auftrag mit einem Warehouse Service auszufüllen.
Die beiden Back-End-Dienste, Order Validating Service und Warehouse Service, bleiben für beide Tests gleich. Der Teil, der sich ändert, ist der Online-Shop-Dienst, der die Orchestrierung durchführt. In einem Fall ist der Dienst als WCF-Dienst handcodiert. Für den anderen Fall wird der Dienst als WCF-Workflowdienst in WF4 geschrieben. WF-spezifische Features wie Tracking und Persistenz werden für diesen Test deaktiviert.
Umwelt
Clientanforderungen werden über HTTP von mehreren Computern an den Onlineshop-Service gesendet. Ein einzelner Computer hostt alle drei Dienste. Die Transportschicht zwischen dem Online Store-Dienst und den Back-End-Diensten ist TCP oder HTTP. Die Messung der Vorgänge/Sekunde basiert auf der Anzahl der abgeschlossenen PurchaseOrder Anrufe an den Online Store-Dienst. Kanalpooling ist ein neues Feature, das in WF4 verfügbar ist. Im WCF-Teil dieses Tests wird das Channelpooling nicht vordefiniert bereitgestellt. Daher wurde eine handcodierte Implementierung einer einfachen Poolingtechnik im Onlineshopdienst verwendet.
Leistung
Beim Herstellen einer Verbindung zu Back-End-TCP-Diensten ohne Channelpooling weist der WF-Dienst Auswirkungen von 17,2 % auf den Durchsatz auf. Mit Channelpooling beträgt der Abzug etwa 23,8 %. Für HTTP ist die Auswirkung viel weniger: 4.3% ohne Pooling und 8.1% mit Pooling. Es ist auch wichtig zu beachten, dass die Kanalpooling bei der Verwendung von HTTP sehr wenig Vorteile bietet.
Obwohl durch die WF4-Laufzeit zusätzlicher Aufwand im Vergleich zu einem handcodierten WCF-Dienst in diesem Test entsteht, könnte dies als ungünstigster Fall angesehen werden. Die beiden Back-End-Dienste in diesem Test funktionieren nur sehr wenig. In einem echten End-to-End-Szenario würden diese Dienste teurere Vorgänge wie Datenbankaufrufe ausführen, wodurch die Leistung der Transportschicht weniger wichtig ist. Dies und die Vorteile der in WF4 verfügbaren Features machen Workflow Foundation zu einer lebensfähigen Wahl für die Erstellung von Orchestrierungsdiensten.
Kernleistungsüberlegungen
Die Featurebereiche in diesem Abschnitt, mit Ausnahme der Interoperabilität, haben sich zwischen WF3 und WF4 erheblich geändert. Dies wirkt sich sowohl auf den Entwurf von Workflowanwendungen als auch auf die Leistung aus.
Workflow-Aktivierungslatenz
In einer WCF-Workflowdienstanwendung ist die Latenz beim Starten eines neuen Workflows oder laden eines vorhandenen Workflows wichtig, da er blockiert werden kann. Dieser Testfall misst einen WF3 XOML-Host für einen WF4-XAMLX-Host in einem typischen Szenario.
Einrichtung der Umgebung
Testaufbau
Im Szenario kontaktiert ein Clientcomputer einen WCF-Workflowdienst mithilfe kontextbasierter Korrelation. Die Kontextkorrelation erfordert eine spezielle Kontextbindung und verwendet einen Kontextheader oder ein Cookie, um Nachrichten mit der richtigen Workflowinstanz zu verknüpfen. Es hat einen Leistungsvorteil, dass sich die Korrelations-ID im Nachrichtenkopf befindet, sodass der Nachrichtentext nicht analysiert werden muss.
Der Dienst erstellt einen neuen Workflow mit der Anforderung und sendet eine sofortige Antwort, sodass die Messung der Latenz nicht die Zeit für die Ausführung des Workflows enthält. Der WF3-Workflow basiert auf XOML mit Code-Behind, und der WF4-Workflow basiert vollständig auf XAML. Der WF4-Workflow sieht wie folgt aus:
Die Receive Aktivität erstellt die Workflowinstanz. Ein in der empfangenen Nachricht übergebener Wert wird in der Antwortnachricht wiedergegeben. Eine Sequenz nach der Antwort enthält den Rest des Workflows. Im obigen Fall wird nur eine Kommentaraktivität angezeigt. Die Anzahl der Kommentaraktivitäten wird geändert, um die Workflowkomplexität zu simulieren. Eine Kommentaraktivität entspricht einem WF3 CodeActivity , das keine Arbeit ausführt. Weitere Informationen zur Kommentaraktivität finden Sie weiter oben in diesem Artikel im Abschnitt "Leistungsvergleich auf Komponentenebene".
Testergebnisse
Kalte und warme Latenz für WCF-Workflowdienste:
Im obigen Diagramm verweist „kalt“ auf den Fall, in dem kein WorkflowServiceHost für den angegebenen Workflow vorhanden ist. Mit anderen Worten: Die kalte Latenz ist der Zeitpunkt, an dem der Workflow zum ersten Mal verwendet wird und das XOML oder XAML kompiliert werden muss. Warme Latenzzeit ist die Zeit zum Erstellen einer neuen Workflowinstanz, wenn der Workflowtyp bereits kompiliert wurde. Die Komplexität des Workflows macht im WF4-Fall sehr wenig Unterschied, hat aber eine lineare Entwicklung im WF3-Fall.
Korrelationsdurchsatz
WF4 führt ein neues inhaltsbasiertes Korrelationsfeature ein. WF3 hat nur kontextbasierte Korrelation bereitgestellt. Kontextbasierte Korrelation konnte nur über bestimmte WCF-Kanalbindungen erfolgen. Die Workflow-ID wird bei Verwendung dieser Bindungen in den Nachrichtenkopf eingefügt. Die WF3-Laufzeit konnte einen Workflow nur anhand seiner ID identifizieren. Mit inhaltsbasierter Korrelation kann der Workflowautor einen Korrelationsschlüssel aus einem relevanten Datenteil wie einer Kontonummer oder Kunden-ID erstellen.
Kontextbasierte Korrelation hat einen Leistungsvorteil, da sich der Korrelationsschlüssel im Nachrichtenkopf befindet. Der Schlüssel kann aus der Nachricht gelesen werden, ohne dass eine Deserialisierung/Nachrichtkopie erfolgt. In inhaltsbasierter Korrelation wird der Korrelationsschlüssel im Nachrichtentext gespeichert. Ein XPath-Ausdruck wird verwendet, um den Schlüssel zu suchen. Die Kosten dieser zusätzlichen Verarbeitung hängen von der Größe der Nachricht, der Tiefe des Schlüssels im Textkörper und der Anzahl der Schlüssel ab. Dieser Test vergleicht kontext- und inhaltsbasierte Korrelation und zeigt auch die Leistungsbeeinträchtigung bei Verwendung mehrerer Schlüssel an.
Einrichtung der Umgebung
Testaufbau
Der vorherige Workflow ist identisch, der im Abschnitt "Persistenz " verwendet wird. Für die Korrelationstests ohne Persistenz ist kein Persistenzanbieter in der Laufzeit installiert. Korrelation erfolgt an zwei Stellen: CreateOrder und CompleteOrder.
Testergebnisse
Dieses Diagramm zeigt eine Abnahme der Leistung, da die Anzahl der schlüssel, die in der inhaltsbasierten Korrelation verwendet werden, zunimmt. Die Ähnlichkeit der Kurven zwischen TCP und HTTP weist auf den mit diesen Protokollen verbundenen Overhead hin.
Korrelation mit Persistenz
Bei einem beibehaltenen Workflow wechselt der CPU-Druck von inhaltsbasierter Korrelation von der Workflowlaufzeit in die SQL-Datenbank. Die gespeicherten Prozeduren im SQL-Persistenzanbieter führen die Arbeit des Abgleichs der Schlüssel aus, um den entsprechenden Workflow zu finden.
Kontextbasierte Korrelation ist immer noch schneller als inhaltsbasierte Korrelation. Der Unterschied ist jedoch weniger ausgeprägt, da die Persistenz mehr Auswirkungen auf die Leistung hat als die Korrelation.
Komplexer Workflowdurchsatz
Die Komplexität eines Workflows wird nicht nur durch die Anzahl der Aktivitäten gemessen. Zusammengesetzte Aktivitäten können viele untergeordnete Elemente enthalten, und bei diesen untergeordneten Elementen kann es sich auch um zusammengesetzte Aktivitäten handeln. Mit der Anzahl der Schachtelungsebenen steigt auch die Anzahl der Aktivitäten, die derzeit den Status "Wird ausgeführt" aufweisen, sowie die Anzahl der Variablen, die diesen Status besitzen können. Dieser Test vergleicht den Durchsatz zwischen WF3 und WF4 beim Ausführen komplexer Workflows.
Testaufbau
Diese Tests wurden auf einem Intel Xeon X5355 @ 2,66GHz Vier-Wege-Computer mit 4 GB RAM mit Windows Server 2008 x64 durchgeführt. Der Testcode wird in einem einzelnen Prozess mit einem Thread pro Kern ausgeführt, um 100% CPU-Auslastung zu erreichen.
Die für diesen Test generierten Workflows weisen zwei Hauptvariablen auf: Tiefe und Anzahl von Aktivitäten in jeder Sequenz. Jede Tiefenebene enthält eine parallele Aktivität, while-Schleife, Entscheidungen, Zuweisungen und Sequenzen. Im unten dargestellten WF4-Designer wird das Flussdiagramm der obersten Ebene dargestellt. Jede Flussdiagrammaktivität ähnelt dem Hauptflussdiagramm. Es kann hilfreich sein, ein Fraktal beim Darstellen dieses Workflows zu betrachten, bei dem die Tiefe auf die Parameter des Tests beschränkt ist.
Die Anzahl der Aktivitäten in einem bestimmten Test wird durch die Komplexität und die Anzahl der Aktivitäten pro Sequenz bestimmt. Die folgende Formel berechnet die Anzahl der Aktivitäten im WF4-Test:
Die Aktivitätsanzahl des WF3-Tests kann aufgrund einer zusätzlichen Sequenz mit einer etwas anderen Formel berechnet werden:
D ist die Tiefe und eine ist die Anzahl der Aktivitäten pro Sequenz. Die Logik hinter diesen Gleichungen besteht darin, dass die erste Konstante, multipliziert mit a, die Anzahl der Sequenzen und die zweite Konstante die statische Anzahl von Aktivitäten auf der aktuellen Ebene ist. In jedem Flussdiagramm sind drei untergeordnete Flussdiagrammaktivitäten vorhanden. Auf der unteren Tiefenebene sind diese Flussdiagramme leer, aber auf den anderen Ebenen sind sie Kopien des Hauptflussdiagramms. Die Anzahl der Aktivitäten in der Workflowdefinition der einzelnen Testvariationen wird in der folgenden Tabelle angegeben:
Die Anzahl der Aktivitäten in der Workflowdefinition nimmt mit jeder Tiefenebene stark zu. In einer bestimmten Workflowinstanz wird jedoch nur ein Pfad pro Entscheidungspunkt ausgeführt, sodass nur eine kleine Teilmenge der tatsächlichen Aktivitäten ausgeführt wird.
Ein entsprechender Workflow wurde für WF3 erstellt. Der WF3-Designer zeigt den ganzen Workflow im Entwurfsbereich anstelle der Schachtelung an. Er ist daher für eine Anzeige in diesem Thema zu groß. Unten sehen Sie einen Codeausschnitt des Workflows.
Ein anderer Workflow, der Teil dieses Tests ist, verwendet 100 geschachtelte Sequenzen, um die Schachtelung im Extremfall zu üben. In der innersten Sequenz befindet sich ein einzelner Comment oder eine einzelne CodeActivity.
Nachverfolgung und Persistenz werden nicht als Teil dieses Tests verwendet.
Testergebnisse
Auch bei komplexen Workflows mit viel Tiefe und einer hohen Anzahl von Aktivitäten sind die Leistungskennzahlen mit den weiter oben in diesem Artikel gezeigten Durchsatzzahlen konsistent. Der Durchsatz von WF4 ist um ein Vielfaches schneller und muss auf einer logarithmischen Skala verglichen werden.
Gedächtnis
Der Arbeitsspeicheraufwand von Windows Workflow Foundation wird in zwei Schlüsselbereichen gemessen: Workflowkomplexität und Anzahl von Workflowdefinitionen. Arbeitsspeichermessungen wurden auf einer Windows 7 64-Bit-Arbeitsstation durchgeführt. Es gibt viele Möglichkeiten, die Messung der Arbeitssatzgröße abzurufen, z. B. Überwachen von Leistungsindikatoren, Abfragen von Environment.WorkingSet oder Verwenden eines Tools wie VMMap, das über VMMap verfügbar ist. Eine Kombination von Methoden wurde verwendet, um die Ergebnisse der einzelnen Tests zu erhalten und zu überprüfen.
Test der Workflowkomplexität
Der Workflowkomplexitätstest misst den Arbeitssatzunterschied basierend auf der Komplexität des Workflows. Zusätzlich zu den komplexen Workflows, die im vorherigen Abschnitt verwendet werden, werden neue Variationen hinzugefügt, um zwei Grundlegendes zu behandeln: einen einzelnen Aktivitätsworkflow und eine Sequenz mit 1000 Aktivitäten. Bei diesen Tests werden die Workflows für einen Zeitraum von einer Minute initialisiert und zum Abschluss in einer einzelnen seriellen Schleife ausgeführt. Jede Testvariation wird dreimal ausgeführt, und die aufgezeichneten Daten sind der Mittelwert dieser drei Läufe.
Die beiden neuen grundlegenden Tests verfügen über Workflows, die wie unten dargestellt aussehen:
Im oben gezeigten WF3-Workflow werden leere CodeActivity Aktivitäten verwendet. Der obige WF4-Workflow verwendet Comment Aktivitäten. Die Comment Aktivität wurde weiter oben in diesem Artikel im Abschnitt "Leistungsvergleiche auf Komponentenebene" beschrieben.
Einer der klaren Trends in diesem Diagramm ist, dass die Schachtelung relativ geringe Auswirkungen auf die Speicherauslastung in WF3 und WF4 hat. Die wichtigsten Auswirkungen auf den Arbeitsspeicher stammen aus der Anzahl der Aktivitäten in einem bestimmten Workflow. Angesichts der Daten aus der Sequenz mit der Zahl 1000, den Variationen der Sequenz mit komplexer Tiefe 5, Sequenz 5 und der Sequenz mit komplexer Tiefe 7, Sequenz 1, wird deutlich, dass, wenn die Anzahl der Aktivitäten in die Tausende steigt, die Speichernutzung spürbarer zunimmt. Im Extremfall (Tiefe 7 Sequenz 1) mit ~ 29.000 Aktivitäten verwendet WF4 fast 79 % weniger Arbeitsspeicher als WF3.
Test mit mehreren Workflowdefinitionen
Die Messung des Arbeitsspeichers pro Workflowdefinition ist aufgrund der verfügbaren Optionen für das Hosten von Workflows in WF3 und WF4 in zwei verschiedenen Tests unterteilt. Die Tests werden anders ausgeführt als der Workflowkomplexitätstest, bei dem ein bestimmter Workflow instanziert und nur einmal pro Definition ausgeführt wird. Dies liegt daran, dass die Workflowdefinition und ihr Host für die Lebensdauer der AppDomain im Arbeitsspeicher verbleiben. Der Arbeitsspeicher, der für die Ausführung einer angegebenen Workflowinstanz verwendet wurde, sollte während der automatischen Speicherbereinigung bereinigt werden. Der Migrationsleitfaden für WF4 enthält ausführlichere Informationen zu den Hostingoptionen. Weitere Informationen finden Sie unter WF Migration Cookbook: WorkflowHosting.
Das Erstellen vieler Workflowdefinitionen für einen Workflowdefinitionstest kann auf verschiedene Arten erfolgen. So könnte beispielsweise eine Codegenerierung verwendet werden, um eine Gruppe von 1000 Workflows zu erstellen, die mit Ausnahme des Namens identisch sind, und jeden dieser Workflows in separaten Dateien speichern. Dieser Ansatz wurde für den vom Konsolen gehosteten Test durchgeführt. In WF3 wurde die WorkflowRuntime Klasse verwendet, um die Workflowdefinitionen auszuführen. WF4 kann entweder WorkflowApplication verwenden, um eine einzelne Workflowinstanz zu erstellen, oder WorkflowInvoker, um die Aktivität direkt auszuführen, als wäre es ein Methodenaufruf. WorkflowApplication ist ein Host einer einzelnen Workflowinstanz und weist eine engere Featureparität auf WorkflowRuntime , sodass sie in diesem Test verwendet wurde.
Beim Hosten von Workflows in IIS ist es möglich, einen VirtualPathProvider zu verwenden, um einen neuen WorkflowServiceHost zu erzeugen, anstatt alle XAMLX- oder XOML-Dateien zu generieren. Die VirtualPathProvider eingehende Anforderung verarbeitet und antwortet mit einer "virtuellen Datei", die aus einer Datenbank geladen werden kann oder in diesem Fall automatisch generiert wird. Daher ist es unnötig, 1000 physische Dateien zu erstellen.
Die im Konsolentest verwendeten Workflowdefinitionen waren einfache sequenzielle Workflows mit einer einzigen Aktivität. Die einzelne Aktivität war eine leere CodeActivity für WF3 und eine Comment-Aktivität für WF4. Der von IIS gehostete Fall verwendet Workflows, die mit dem Empfangen einer Nachricht beginnen und mit dem Senden einer Antwort enden:
Die folgende Abbildung zeigt einen WF3-Workflow mit ReceiveActivity und einen WF4-Workflow mit Anforderungs-/Antwortmuster:
In der folgenden Tabelle wird die Differenz im Workingset zwischen einer einzelnen Workflowdefinition und 1001 Definitionen dargestellt:
| Hostingoptionen | WF3-Workingset-Differenz | WF4-Workingset-Differenz |
|---|---|---|
| Gehostete Workflows für Konsolenanwendung | 18 MB | 9 MB |
| Von IIS gehostete Workflowdienste | 446 MB | 364 MB |
Das Hosten von Workflowdefinitionen in IIS verbraucht aufgrund der WorkflowServiceHostdetaillierten WCF-Dienstartefakte und der dem Host zugeordneten Nachrichtenverarbeitungslogik viel mehr Arbeitsspeicher.
Für das Konsolenhosting in WF3 wurden die Workflows im Code anstelle von XOML implementiert. In WF4 wird standardmäßig XAML verwendet. Der XAML-Code wird als eingebettete Ressource in der Assembly gespeichert und während der Laufzeit kompiliert, um die Implementierung des Workflows bereitzustellen. Diesem Prozess ist ein gewisses Mehraufwand zugeordnet. Um einen fairen Vergleich zwischen WF3 und WF4 zu erzielen, wurden codierte Workflows anstelle von XAML verwendet. Ein Beispiel für einen der WF4-Workflows ist unten dargestellt:
public class Workflow1 : Activity
{
protected override Func<Activity> Implementation
{
get
{
return new Func<Activity>(() =>
{
return new Sequence
{
Activities = {
new Comment()
}
};
});
}
set
{
base.Implementation = value;
}
}
}
Es gibt viele andere Faktoren, die sich auf die Arbeitsspeichernutzung auswirken können. Die gleiche Empfehlung für alle verwalteten Programme gilt noch. In von IIS gehosteten Umgebungen bleibt das WorkflowServiceHost für eine Workflowdefinition erstellte Objekt im Arbeitsspeicher, bis der Anwendungspool wiederverwendet wird. Dies sollte beim Schreiben von Erweiterungen beachtet werden. Außerdem empfiehlt es sich, "globale" Variablen (Variablen, die auf den gesamten Workflow beschränkt sind) zu vermeiden und den Umfang von Variablen möglichst einzuschränken.
Workflow-Ausführungsdienste
Ausdauer
WF3 und WF4 werden beide mit einem SQL-Persistenzanbieter ausgeliefert. Der WF3 SQL-Persistenzanbieter ist eine einfache Implementierung, die die Workflowinstanz serialisiert und in einem Blob speichert. Aus diesem Grund hängt die Leistung dieses Anbieters stark von der Größe der Workflowinstanz ab. In WF3 könnte sich die Instanzgröße aus vielen Gründen erhöhen, wie bereits in diesem Dokument beschrieben. Viele Kunden entscheiden sich, den Standardmäßigen SQL-Persistenzanbieter nicht zu verwenden, da das Speichern einer serialisierten Instanz in einer Datenbank keinen Einblick in den Status des Workflows gibt. Um einen bestimmten Workflow zu finden, ohne die Workflow-ID zu kennen, müsste man jede beibehaltene Instanz deserialisieren und den Inhalt untersuchen. Viele Entwickler bevorzugen das Verfassen eigener Persistenzanbieter, um dieses Hindernis zu umgehen.
Der WF4 SQL-Persistenzanbieter hat versucht, einige dieser Bedenken zu beheben. Die Persistenztabellen machen bestimmte Informationen verfügbar, wie die aktiven Lesezeichen und beförderbare Eigenschaften. Das neue inhaltsbasierte Korrelationsfeature in WF4 würde mit dem WF3 SQL-Persistenzansatz nicht gut funktionieren, was Änderungen in der Organisation der gespeicherten Workflowinstanz bewirkt hat. Dies macht die Aufgabe des Persistenzanbieters komplexer und setzt zusätzlichen Stress auf die Datenbank.
Einrichtung der Umgebung
Testaufbau
Auch bei einem verbesserten Featuresatz und einer besseren Parallelitätsbehandlung ist der SQL-Persistenzanbieter in WF4 schneller als der Anbieter in WF3. Um dies zu präsentieren, werden zwei Workflows, die im Wesentlichen die gleichen Vorgänge in WF3 und WF4 ausführen, unten verglichen.
Die beiden Workflows werden beide von einer empfangenen Nachricht erstellt. Nach dem Senden einer ersten Antwort wird der Workflow beibehalten. In WF3 wird eine leere TransactionScopeActivity verwendet, um die Persistenz zu initiieren. Dasselbe kann in WF3 erreicht werden, indem eine Aktivität mit „Beim Schließen beibehalten“ markiert wird. Eine zweite, korrelierte Meldung schließt den Workflow ab. Die Workflows werden beibehalten, aber nicht entladen.
Testergebnisse
Wenn der Transport zwischen Client und mittlerer Ebene HTTP ist, zeigt die Persistenz in WF4 eine Verbesserung von 2,6 Mal an. Der TCP-Transport erhöht diesen Faktor auf 3,0 Mal. In allen Fällen beträgt die CPU-Auslastung auf der mittleren Ebene 98% oder höher. Der Grund, warum WF4-Durchsatz größer ist, liegt an der schnelleren Workflowlaufzeit. Die Größe der serialisierten Instanz ist für beide Fälle niedrig und ist in dieser Situation kein wesentliches Element.
Sowohl die WF3- als auch WF4-Workflows in diesem Test verwenden eine Aktivität, um explizit anzugeben, wann persistenz auftreten soll. Dies hat den Vorteil, dass der Workflow beibehalten wird, ohne ihn zu entladen. In WF3 ist es auch möglich, die Verwendung des TimeToUnload Features beizubehalten, aber dadurch wird die Workflowinstanz aus dem Arbeitsspeicher entladen. Wenn ein Entwickler, der WF3 verwendet, sicherstellen möchte, dass ein Workflow an bestimmten Stellen beibehalten wird, muss er entweder die Workflowdefinition ändern oder die Kosten für das Entladen und erneutes Laden der Workflowinstanz bezahlen. Eine neue Funktion in WF4 ermöglicht es, ohne Entladen fortzubestehen: TimeToPersist. Mit diesem Feature kann die Workflowinstanz im Leerlauf gespeichert werden und im Arbeitsspeicher bleiben, bis der TimeToUnload Schwellenwert erreicht oder die Ausführung fortgesetzt wird.
Beachten Sie, dass der WF4 SQL-Persistenzanbieter mehr Arbeit auf der Datenbankebene ausführt. Die SQL-Datenbank kann zu einem Engpass werden, sodass es wichtig ist, die CPU- und Datenträgerauslastung dort zu überwachen. Achten Sie darauf, die folgenden Leistungsindikatoren aus der SQL-Datenbank einzuschließen, wenn Workflowanwendungen für Leistungstests ausgeführt werden:
Physischer Datenträger\Lesezeit (%)
Physischer Datenträger\Zeit (%)
Physischer Datenträger\Schreibzeit (%)
PhysicalDisk\% Durchschnittliche Datenträger-Warteschlangenlänge
Physischer Datenträger\Durchschnittl. Warteschlangenlänge der Datenträger-Lesevorgänge
Physischer Datenträger\Durchschnittl. Warteschlangenlänge der Datenträger-Schreibvorgänge
Physischer Datenträger\Aktuelle Warteschlangenlänge
Prozessorinformationen\% Prozessorzeit
SQLServer:Latches\Durchschnittliche Latchwartezeit (ms)
SQLServer:Latches\Latchwartezeiten/s
Nachverfolgung
Die Workflownachverfolgung kann verwendet werden, um den Fortschritt eines Workflows nachzuverfolgen. Die Informationen, die in den Tracking-Ereignissen enthalten sind, werden durch ein Tracking-Profil bestimmt. Je komplexer das Tracking-Profil ist, desto teurer wird die Nachverfolgung.
WF3 wurde mit einem SQL-basierten Tracking-Dienst ausgeliefert. Dieser Dienst kann in Batch- und Nicht-Batch-Modi funktionieren. Im Nicht-Batch-Modus werden Nachverfolgungsereignisse direkt in die Datenbank geschrieben. Im Batchmodus werden Nachverfolgungsereignisse im selben Batch wie der Workflowinstanzstatus erfasst. Der Batchmodus bietet die beste Leistung für die breiteste Palette von Workflowdesigns. Die Batchverarbeitung kann jedoch negative Auswirkungen auf die Leistung haben, wenn der Workflow viele Aktivitäten ausführt, ohne dass sie beibehalten werden und diese Aktivitäten nachverfolgt werden. Dies geschieht häufig in Schleifen, und die beste Möglichkeit, dieses Szenario zu vermeiden, besteht darin, große Schleifen so zu entwerfen, dass sie einen Persistenzpunkt enthalten. Die Einführung eines Persistenzpunkts in eine Schleife kann auch die Leistung negativ beeinflussen, sodass es wichtig ist, die Kosten der einzelnen zu messen und ein Gleichgewicht zu erzielen.
WF4 wird nicht mit einem SQL-Nachverfolgungsdienst ausgeliefert. Die Aufzeichnung von Nachverfolgungsinformationen in einer SQL-Datenbank kann besser von einem Anwendungsserver verarbeitet werden, anstatt in .NET Framework integriert zu werden. Daher wird die SQL-Nachverfolgung jetzt von AppFabric behandelt. Der sofort einsatzbereite Tracking-Anbieter in WF4 basiert auf "Event Tracing for Windows" (ETW).
ETW ist ein in Windows integriertes Ereignissystem auf Kernelebene mit niedriger Latenz. Es verwendet ein Anbieter-/Verbrauchermodell, durch das Kosten für die Ereignisprotokollierung nur dann anfallen, wenn tatsächlich ein Verbraucher vorhanden ist. Neben Kernelereignissen wie Prozessor, Datenträger, Arbeitsspeicher und Netzwerknutzung nutzen viele Anwendungen auch ETW. ETW-Ereignisse sind leistungsstärker als Leistungsindikatoren, in denen Ereignisse an die Anwendung angepasst werden können. Ein Ereignis kann Text wie eine Workflow-ID oder eine Informationsmeldung enthalten. Darüber hinaus werden Ereignisse mit Bitmasken kategorisiert, sodass die Verwendung einer bestimmten Teilmenge von Ereignissen weniger Auswirkungen auf die Leistung hat als das Erfassen aller Ereignisse.
Zu den Vorteilen der Verwendung von ETW für die Nachverfolgung anstelle von SQL gehören:
Eine Auflistung von Nachverfolgungsereignissen kann in einem anderen Prozess abgetrennt werden. Dies bietet mehr Flexibilität bei der Aufzeichnung der Ereignisse.
ETW-Nachverfolgungsereignisse können problemlos mit den WCF ETW-Ereignissen oder anderen ETW-Anbietern wie einem SQL Server- oder Kernelanbieter kombiniert werden.
Workflowautoren müssen keinen Workflow ändern, um mit einer bestimmten Nachverfolgungsimplementierung besser zu arbeiten, z. B. den Batchmodus des WF3 SQL-Nachverfolgungsdiensts.
Ein Administrator kann die Nachverfolgung aktivieren oder deaktivieren, ohne den Hostprozess wiederzuverwenden.
Die Leistungsvorteile der ETW-Nachverfolgung haben einen Nachteil. ETW-Ereignisse können verloren gehen, wenn das System unter intensivem Ressourcendruck liegt. Die Verarbeitung von Ereignissen ist nicht dazu gedacht, die normale Programmausführung zu blockieren und daher nicht garantiert, dass alle ETW-Ereignisse an ihre Abonnenten übertragen werden. Dies macht ETW-Tracking hervorragend für die Gesundheitsüberwachung geeignet, aber nicht für Audits.
Während WF4 nicht über einen SQL-Tracking-Anbieter verfügt, besitzt AppFabric einen. Der SQL-Tracking-Ansatz von AppFabric besteht darin, ETW-Ereignisse mit einem Windows-Dienst zu abonnieren, der die Ereignisse batchet und in eine SQL-Tabelle schreibt, die für schnelle Einfügungen entwickelt wurde. Ein separater Auftrag extrahiert die Daten aus dieser Tabelle und wandelt sie in Berichtstabellen um, die im AppFabric-Dashboard angezeigt werden können. Dies bedeutet, dass eine Reihe von Nachverfolgungsereignissen unabhängig vom Workflow behandelt wird, von dem er stammt und daher nicht auf einen Persistenzpunkt warten muss, bevor er aufgezeichnet wird.
ETW-Ereignisse können mit Tools wie Logman oder Xperf aufgezeichnet werden. Die kompakte ETL-Datei kann mit einem Tool wie xperfview angezeigt oder in ein besser lesbares Format wie XML mit Tracerpt konvertiert werden. In WF3 besteht die einzige Option zum Abrufen von Nachverfolgungsereignissen ohne SQL-Datenbank darin, einen benutzerdefinierten Nachverfolgungsdienst zu erstellen. Weitere Informationen zu ETW finden Sie unter WCF-Dienste und Ereignisablaufverfolgung für Windows - und Ereignisablaufverfolgung – Windows-Anwendungen.
Das Aktivieren der Workflownachverfolgung wirkt sich auf die Leistung in unterschiedlichem Grad aus. Der folgende Benchmark verwendet das Logman-Tool, um die ETW-Tracking-Ereignisse zu nutzen und sie in einer ETL-Datei aufzuzeichnen. Die Kosten für die SQL-Nachverfolgung in AppFabric liegen außerhalb des Rahmens dieses Artikels. Das grundlegende Tracking-Profil, das auch in AppFabric verwendet wird, wird in diesem Benchmark gezeigt. Ebenfalls enthalten sind die Kosten für die Nachverfolgung von Systemüberwachungsereignissen. Diese Ereignisse sind nützlich für die Problembehandlung und die Ermittlung des durchschnittlichen Durchsatzes des Systems.
Einrichtung der Umgebung
Testergebnisse
Die Systemüberwachung wirkt sich in etwa zu 3 % auf den Durchsatz aus. Die Kosten des grundlegenden Profils liegen bei etwa 8 %.
Interoperabilität
WF4 ist fast eine vollständige Umschreibung von WF und daher sind WF3-Workflows und -Aktivitäten nicht direkt mit WF4 kompatibel. Viele Kunden, die Windows Workflow Foundation frühzeitig übernommen haben, verfügen über interne oder Drittanbieter-Workflowdefinitionen und benutzerdefinierte Aktivitäten für WF3. Eine Möglichkeit zum Vereinfachen des Übergangs zu WF4 ist die Verwendung der Interop-Aktivität, die WF3-Aktivitäten innerhalb eines WF4-Workflows ausführen kann. Es wird empfohlen, die Interop Aktivität nur bei Bedarf zu verwenden. Weitere Informationen zum Migrieren zu WF4 finden Sie in den WF4-Migrationsleitfaden.
Einrichtung der Umgebung
Testergebnisse
Die folgende Tabelle zeigt die Ergebnisse der Ausführung eines Workflows mit fünf Aktivitäten in einer Sequenz in verschiedenen Konfigurationen.
| Testen | Durchsatz (Workflows/Sek) |
|---|---|
| WF3-Sequenz in WF3-Laufzeit | 1,576 |
| WF3-Sequenz in WF4-Laufzeit mit Interop | 2.745 |
| WF4-Sequenz | 153,582 |
Bei der Verwendung von Interop ist eine enorme Leistungszunahme im Vergleich zur alleinigen Verwendung von WF3 zu verzeichnen. Im Vergleich zu WF4-Aktivitäten ist der Anstieg jedoch vernachlässigbar.
Zusammenfassung
Hohe Investitionen in die Performance für WF4 haben sich in vielen wichtigen Bereichen bezahlt. Die Leistung einzelner Workflowkomponenten ist in einigen Fällen aufgrund einer schlankeren WF-Laufzeit in WF4 hundertmal schneller als WF3. Die Latenzzeiten sind ebenfalls bedeutend besser. Dies bedeutet, dass die Leistungseinbuße bei der Verwendung von WF anstelle von handcodierten WCF-Orchestrierungsdiensten sehr gering ist, wenn man die zusätzlichen Vorteile der Verwendung von WF berücksichtigt. Die Persistenzleistung ist um den Faktor 2,5 - 3,0 gestiegen. Die Gesundheitsüberwachung mithilfe der Workflownachverfolgung hat jetzt sehr wenig Aufwand. Eine umfassende Gruppe von Migrationshandbüchern steht für Diejenigen zur Verfügung, die einen Wechsel von WF3 zu WF4 in Betracht ziehen. All dies sollte WF4 zu einer attraktiven Option zum Schreiben komplexer Anwendungen machen.
Zusammenarbeit auf GitHub
Die Quelle für diesen Inhalt finden Sie auf GitHub, wo Sie auch Issues und Pull Requests erstellen und überprüfen können. Weitere Informationen finden Sie in unserem Leitfaden für Mitwirkende.
