locked
Composite activity memory footprint RRS feed

  • General discussion

  • 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/activities that are a mix of custom code activities, flow decisions, assigns, and containers(switches, sequence, for/parallel for).
    5. "Worker" activities handling things like file I/O, database interactions, validation are all done through code activities. The code activities were built using AsyncCodeActivity<T>.
    6. In my activities I am trying to cache metadata and the activities as recommended in various best practices articles.
    7. Each unique workflow instantiation uses about 50mb,  but multiple instantiations of the same workflow do not consume the same amount of extra memory.
    8. Must be deployed only to windows 2003 servers at least for this year.

    Thank you for any suggestions or insight you can provide.

    John

    Thursday, April 14, 2011 1:58 PM

All replies

  • Hi John,
    Are you using [DesignerAttribute], or going with IRegisterMetadata plugin-style? If the former you might see that you are loading assemblies which you shouldn't actually need for runtime, and switching over to IRegisterMetadata might help alleviate this.
    Tim
    Friday, May 27, 2011 6:44 AM