WF performance with new 20,000 persisted workflow instances each month

Question

Windows Workflow Foundation has a problem that is slow when doing WF instances persistace. I'm planning to do a project whose bussiness layer will be based on WF exposed WCF services. The project will have 20,000 new workflow instances created each month, each instance could take up to 2 months to finish. What I was lead to belive that given WF slownes when doing peristance my given problem would be unattainable given performance reasons. I have the following questions:

1. Is this true? Will my performance be crap with that load(given WF persitance speed limitations)
2. How can I solve the problem?

We currently have two possible solutions: 1. Each new buisiness process request(e.g. Give me a new drivers license) will be a new WF instance, and the number of persistance operations will be limited by forwarding all status request operations to saved state values in a separate database. 2. Have only a small amount of Workflow Instances up at any give time, without any persistance ofso ever(only in case of system crashes etc.), by breaking each workflow stap in to a separate worklof and that workflow handling each business process request instance in the system that is at that current step(e.g. I'm submitting my driver license reques form, which is step one... we have 100 cases of that, and my step one workflow will handle every case simultaneusly).

I'm very insterested in solution for that problem. If you want to discuss that problem pleas be free to mail me at [email protected]

Answer 1

The number of hydrated executing wokflows will be determined by environmental factors memory server through put etc. Persistence issue really only come into play if you are loading and unloading workflows all the time aka real(ish) time in that case workflow may not be the best solution.

Answer 2

In my current project we also use WF with persistence. We don't have quite the same volume (perhaps ~2000 instances/month), and they are usually not as long to complete (they are normally done within 5 minutes, in some cases a few days). We did decide to split up the main workflow in two parts, where the normal waiting state would be. I can't say that I have noticed any performance difference in the system due to this, but it did simplify it, since our system sometimes had problems matching incoming signals to the correct workflow instance (that was an issue in our code; not in WF).

I think that if I were to start a new project based on WF I would rather go for smaller workflows that are invoked in sequence, than to have big workflows handling the full process.

Answer 3

To be honest I am still investigating the performance characteristics of workflow foundation.

However if it helps, I have heard the WF team have made many performance improvements with the new release of WF 4.

Here are a couple of links that might help (if you havn't seem them already)

A Developer's Introduction to Windows Workflow Foundation (WF) in .NET 4 (discusses performance improvements)

Performance Characteristics of Windows Workflow Foundation (applies to WF 3.0)