SYSK 215: Testing the Limits of .NET 3.0 Workflow Foundation

  • Article

First, here is what triggered this investigation: since your application (windows/web) hosts the workflow runtime in process, and given that the WinWF is managed code, it made me think:

1. What application domain will it run in? Will it create its own or use my application domain? Will all instances of the workflow run in the same app domain?

2. Does it use the CLR thread pool? If not, does it have some limit on the number of concurrently running workflow instances?

My tests show (tested on the September 2006 release) that all workflow instances will run in the main application domain. So, if your workflow host application is a windows exe named WorkflowHost.exe, and you’re running from Visual Studio, the friendly name of the application domain from within a workflow instance would be WorkflowHost.vshost.exe.

 

Now, on to the next question. The CLR thread pool is set by default to allow a maximum of 25 threads per processor. My tests show that the WinWF runtime uses the CLR thread pool. So, here are some results:

 

Test 1: Running from Visual Studio

· App started – 15 threads… then go to 14 and back to 15

· Start 40 workflows – threads go up to 23… then 24

· When all workflow instances are finished, the thread count shows 19

 

Test 2: Outside Visual Studio

· App started – 10 threads… go down to 9, back to 10

· Start 40 workflows – up to 19… down to 18.

· When all workflow instances are finished, thread count goes down to 12

 

So, what’s the implication? What’s the meaning of all this?

My workflow consisted of one code segment that had a Thread.Sleep(10000) call. The last, 40th instance, took 53.5 seconds from the workflow.Start() method call to OnWorkflowCompleted delegate call. No wonder, with only 9 threads used to do the job, and 40 workflows trying to run in parallel, the queuing was necessary. For those of you who are curious, the first workflow instance took 10046 ms, 10000 of which was the Sleep call.

 

Bottom line: the number of workflows executing in parallel in WinWF is limited by the number of threads available in the CLR thread pool. In my test windows app, it was about 9.