¿Son las Statemachines de Windows Workflow Foundation adecuadas para escenarios de alto rendimiento?

Question

Actualmente estoy tratando con un sistema en el que tengo que rastrear el estado de varios miles de objetos en paralelo que envían posibles actualizaciones de estado varias veces por minuto. Además, tengo que realizar cálculos adicionales (nada de cosas IO lentas, simplemente usando CPU).

Actualmente uso una implementación de máquina de estado personalizada. sin embargo, como WF se usa en otras partes del sistema, me pregunto si la máquina de estado WF puede ser adecuada para tal escenario con un puñado (< 5) de estados.

Me temo que la sobrecarga puede ser demasiado grande cuando se trata de rendimiento. Dado que la documentación de MS no cubre temas relacionados con el rendimiento de las máquinas de estado de WF, me pregunto si algún miembro de SO tiene alguna información o recursos que registren el rendimiento de la máquina de estado de WF.

respetos j.

Answer 1

Las máquinas de estado son ideales para un sistema de alto rendimiento. Si realmente necesita un rendimiento muy alto con la base de flujo de trabajo agrega mucha complejidad y gastos generales. He descubierto que biztalk es totalmente inadecuado para un rendimiento muy alto.

Answer 2

Microsoft está utilizando actualmente WF en sus productos de servidor y están ampliando esto. Entonces, por ejemplo, el motor WF se puede encontrar en Share Point Server (MOSS) y en BizTalk Server. Ambos se escalan bastante bien y permiten escenarios de escalado: es decir, se agrega hardware más (barato) en un clúster de equilibrio de carga si se necesita más potencia de cálculo.

HTH, Thomas

Answer 3

Esto no habla directamente del rendimiento, pero si planea eventualmente pasar a WF 4.0, debe tener en cuenta que es probable que StateMachineActivity won't be making the cut.

Answer 4

Si está buscando una máquina de estado de alto rendimiento basada en .Net, recomendaría Stateless. Aquí es un extracto del sitio del proyecto:

La mayoría de los constructos de máquina de estado estándar son compatibles:

• soporte genérico para los estados y desencadenantes de cualquier tipo .NET (números, cuerdas, enumeraciones, etc.)
• estados jerárquicos de entrada/salida eventos para los estados
• cláusulas de la Guardia de apoyo condicional transiciones
• introspección también se proporcionan

Algunas extensiones útiles:

• Capacidad para almacenar el estado de externamente (por ejemplo, en una propiedad rastreada por Linq a SQL)
• parametrizado desencadena
• estados reentrada

configuración es la siguiente:

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

Y lo bueno es que ya que implementa los genéricos, puede utilizar int o cadena para representar los estados y desencadena, lo que le permite integrarse muy fácilmente con su base de datos o ORM. Lo bueno es que no hay un host de tiempo de ejecución adicional del que tenga que preocuparse, solo cargue la máquina de estado con el estado actual de un objeto o un registro y estará listo.