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


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.


 


 

Comments (3)

  1. What if one uses Dual Core/Hyperthreding e.g latest Xeon
    Would one see WF using up to 100 threads?

  2. irenak says:

    Multi-core technology replicates the per-CPU architecture on a single chip, enabling a single socket to contain multiple full CPUs. The number of cores is the number of threads that can be running simultaneously.

    As mentioned above, the default size for a thread pool is 25 threads per processor.

    It is my understanding that to get 100 threads you would need to have a four processor box or two hyperthreaded processors or a hyperthreaded dual core processor.

  3. Robin Maffeo says:

    In cases like this where the threadpool doesn’t rapidly increase the number of threads and the workload is lengthy, you may want to consider tuning the number of minimum threads with SetMinThreads(x,y).  This API tells the threadpool that if there is more work in the queue than x items, and x threads haven’t been created, then create them with minimal delay.

    Thus, in your example if you had set 20 minimum threads, the 40th instance would have completed much more quickly.  Of course, this setting is application dependent, but is appropriate for this type of workload (Sleep or little used CPU time).