Windows Workflow Foundation Statemachines est-il adapté aux scénarios de haute performance?

Question

Je travaille actuellement avec un système où je dois suivre l'état de plusieurs milliers d'objets en parallèle qui envoient des mises à jour d'état possibles quelques fois par minute. En outre, je dois effectuer des calculs supplémentaires (pas de choses IO lent, juste en utilisant le processeur). J'utilise actuellement une implémentation de machine d'état personnalisée. cependant, comme WF est utilisé dans d'autres parties du système, je me demande si la machine d'état WF peut convenir à un tel scénario avec une poignée d'états (< 5).

Je crains que la surcharge soit trop importante en termes de performances. Comme la documentation MS ne couvre pas vraiment les sujets concernant les performances des machines d'état WF, je me demande si un membre de SO a des informations ou des ressources sur les performances des machines d'état WF?

concerne j.

Answer 1

machines d'état sont idéales pour un système haute performance. Si vous avez vraiment besoin de très hautes performances, l'utilisation de la fondation de workflow ajoute beaucoup de complexité et de frais généraux. J'ai trouvé que biztalk était totalement inadapté pour de très hautes performances.

Answer 2

Microsoft utilise actuellement WF dans ses produits serveur et les étend. Ainsi, par exemple, le moteur WF peut être trouvé dans le serveur de point de partage (MOSS) et dans BizTalk Server. Les deux évoluent très bien et permettent des scénarios d'extension, c'est-à-dire que vous ajoutez du matériel (bon marché) dans un cluster à charge équilibrée si vous avez besoin de plus de puissance de calcul.

HTH, Thomas

Answer 3

Cela ne parle pas directement à la performance, mais si vous envisagez de passer éventuellement à WF 4.0, vous devez savoir que StateMachineActivity est susceptible de générer won't be making the cut.

Answer 4

Si vous recherchez une machine d'état à haute performance basée sur .Net, je recommanderais Stateless. Voici un extrait du site du projet:

La plupart des constructions de machines d'état standard sont pris en charge:

• support générique pour les états et déclencheurs de tout type .NET (nombres, chaînes, énumérations, etc.)
• états hiérarchiques d'entrée/sortie événements pour les États
• clauses de garde pour soutenir conditionnelles transitions
• Introspection

Certaines extensions utiles sont également fournis:

• Possibilité de stocker l'état à l'extérieur (par exemple, dans une propriété suivie par Linq to SQL)
• paramétrées déclenche
• états réentrantes

configuration est la suivante:

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); 

Et la bonne chose est que puisqu'il met en œuvre Generics, vous pouvez utiliser int ou une chaîne pour représenter les états et triggers, vous permettant de vous intégrer très facilement à votre base de données ou ORM. La beauté est qu'il n'y a pas d'hôte d'exécution supplémentaire dont vous avez à vous soucier, il suffit de charger la machine d'état avec l'état actuel d'un objet ou d'un enregistrement et vous êtes prêt à partir.