Are Windows Workflow Foundation Statemachines suitable for high performance scenarios?

Question

hi there,

i´m currently dealing with a system where i have to track the state for several thousand objects in parallel that send possible state updates a few times every minute. In addition i have to perform additional computation (no slow IO stuff, just using CPU).

I currently use a custom state machine implementation. however, as WF is used within other parts of the system, i wonder if the WF state machine´s may be suitable for such a scenario with a handful (<5) of states.

I fear that the overhead might be too big when it comes to performance. As the MS documentation does not really cover topics regarding performance for WF state machines, i wonder if some SO member has some information or resources regaring WF state machine performance?

regards j.

Answer 1

Hi,

Microsoft is currently using WF in their server products and they are expanding this. So for example the WF engine can be found in Share Point Server (MOSS) and in BizTalk Server. Both scale quite well and allow scale out scenarios - i.e. you add more (cheap) hardware in a load balanced cluster if you need more computing power.

HTH, Thomas

Answer 2

State machines are great for a high performance system. If you really need very high performance using workflow foundation adds a lot of complexity and overhead. I've found biztalk to be totally unsuitable for very high performance.

Answer 3

This doesn't speak directly to performance, but if you're planning to eventually move to WF 4.0 you should be aware that StateMachineActivity likely won't be making the cut.

Answer 4

If you are looking for a .Net based high performance state machine I would recommend Stateless. Here is an excerpt from the project site:

Most standard state machine constructs are supported:

• Generic support for states and triggers of any .NET type (numbers, strings, enums, etc.)
• Hierarchical states Entry/exit events for states
• Guard clauses to support conditional transitions
• Introspection

Some useful extensions are also provided:

• Ability to store state externally (for example, in a property tracked by Linq to SQL)
• Parameterised triggers
• Reentrant states

Configuration is as follows:

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

And the nice thing is that since it implements Generics, you can use int or string to represent the states and triggers, allowing you to integrate very easily with your database or ORM. The beauty is that there is no additional runtime host that you have to worry about, just load the state machine with the current state from an object or a record and you are good to go.