Sind Windows Workflow Foundation-StateMachines für Hochleistungs- Szenarien geeignet?

Question

Ich beschäftige mich derzeit mit einem System, wo ich den Zustand für mehrere tausend Objekte parallel verfolgen muss, die mögliche Statusupdates einige Male jede Minute senden. Außerdem muss ich zusätzliche Berechnungen durchführen (keine langsamen IO-Sachen, nur mit CPU).

Ich verwende derzeit eine benutzerdefinierte State Machine-Implementierung. Da WF jedoch in anderen Teilen des Systems verwendet wird, frage ich mich, ob die WF-Zustandsmaschine für ein solches Szenario mit einer Handvoll (< 5) Zuständen geeignet sein könnte.

Ich befürchte, dass der Overhead zu groß sein könnte, wenn es um die Leistung geht. Da die MS-Dokumentation nicht wirklich Themen in Bezug auf die Leistung von WF-Zustandsautomaten behandelt, frage ich mich, ob ein SO-Mitglied einige Informationen oder Ressourcen hat, die die Leistung der WF-Zustandsmaschine einschätzen.

grüße j.

Answer 1

Zustandsmaschinen sind für ein Hochleistungssystem. Wenn Sie wirklich sehr hohe Leistung mit Workflow-Foundation benötigen, fügt eine Menge Komplexität und Overhead hinzu. Ich habe herausgefunden, dass BizTalk für sehr hohe Leistung völlig ungeeignet ist.

Answer 2

Microsoft verwendet derzeit WF in ihren Serverprodukten, und diese werden erweitert. So kann die WF-Engine beispielsweise im Share Point Server (MOSS) und in BizTalk Server gefunden werden. Beide skalieren ziemlich gut und erlauben Scale-out-Szenarien - d. H., Sie fügen mehr (billige) Hardware in einen Load-Balanced-Cluster ein, wenn Sie mehr Rechenleistung benötigen.

HTH, Thomas

Answer 3

Dies spricht nicht direkt mit der Leistung, aber wenn Sie planen, schließlich zu WF 4.0 zu wechseln, sollten Sie beachten, dass StateMachineActivity wahrscheinlich won't be making the cut.

Answer 4

Wenn Sie nach einer .Net-basierten Hochleistungs-Zustandsmaschine suchen, empfehle ich Stateless. Hier ist ein Auszug aus der Projekt-Website:

Die meisten Standard-Zustandsmaschine Konstrukte unterstützt:

• Allgemeine Unterstützung für Staaten und Auslöser von jedem .NET-Typ (Zahlen, Streicher, Aufzählungen, usw.)
• Hierarchical Staaten Entry/Exit Veranstaltungen für Staaten
• Schutz Klauseln bedingte Übergänge
• Introspection

einige nützliche Erweiterungen sind ebenfalls vorhanden zu unterstützen:

• Fähigkeit Zustand zu speichern, external (zum Beispiel in einer Eigenschaft verfolgt von Linq nach SQL)
• Parametrierter löst
• Reentrante Staaten

Konfiguration ist wie folgt:

var phoneCall = new StateMachine<State, Trigger>(State.OffHook); 

phoneCall.Configure(State.OffHook) 
    .Permit(Trigger.CallDialed, State.Ringing); 

phoneCall.Configure(State.Ringing) 
    .Permit(Trigger.HungUp, State.OffHook) 
    .Permit(Trigger.CallConnected, State.Connected); 

phoneCall.Configure(State.Connected) 
    .OnEntry(() => StartCallTimer()) 
    .OnExit(() => StopCallTimer()) 
    .Permit(Trigger.LeftMessage, State.OffHook) 
    .Permit(Trigger.HungUp, State.OffHook) 
    .Permit(Trigger.PlacedOnHold, State.OnHold); 

// ... 

phoneCall.Fire(Trigger.CallDialled); 
Assert.AreEqual(State.Ringing, phoneCall.State); 

Und das Schöne daran ist, dass, da es Generics implementiert, Sie int oder String repräsentieren die Zustände verwenden können und Trigger, so dass Sie sehr einfach in Ihre Datenbank oder ORM integrieren können. Das Schöne ist, dass es keinen zusätzlichen Laufzeit-Host gibt, um den Sie sich sorgen müssen. Laden Sie einfach den Zustandsautomaten mit dem aktuellen Status von einem Objekt oder einem Datensatz und Sie können loslegen.