Recently I rebuilt one of our image processing windows services as a proof of concept for workflow foundation. We are interested in the possiblility of leveraging WF for a number of other applications and we wanted to see how it compared to our .Net class/method
based implementations. What I learned from the exercise is that our workflows consumed significantly more memory than our legacy services. I was able to track the increase directly to the instantiation of the workflows themselves. The windows service went
from using < 50mb of memory to over 150mb. This wasn't horrible, but did raise concerns for overall memory consumption on our app servers that in theory could have 10-20 windows service running on them.
My question for the community is whether this increase in memory footprint size is expected or if there are better ways to build the workflows to save on memory consumption. Here are some details:
1. WF4.0 hosted in a windows service on a non blocking thread.
2. All workflow instances are created using the WorkflowApplication object to support cancellation requests when the service is paused or shutdown
3. Primary activities are composite xaml activities built in the designer. They all use flowchart activities and call 1-2 child composite xaml activities depending on execution path.
4. Each composite activity has 10-25 steps/activi
View Complete Post