locked
Does a workflow created in SharePoint Designer use more memory then one developed in Visual Studio? RRS feed

  • Question

  • Brief background:

    I’m attempting to determine if there is a memory leak in my SPD workflow and if I should convert it to one I develop in Visual Studio.

     

    Questions:

    Do workflows developed in Visual Studio tend to be more efficient with memory usage?

    Does the OOTB “Pause” workflow activity keep the instance of the workflow in memory?

     

    Longer background:

    I’ve been tasked to determine and fix why a workflow created in SPD took down a production instance of SharePoint. The workflow is fairly complex. It has 8 steps, several pauses and uses “Useful SharePoint Designer Custom Workflow Activities”. It is attached to a custom list and kicks off when a new item is created. When initiating one at a time, we did not run into any problems. We developed an app that adds multiple items into this list programmatically, effectively kicking off multiple workflows at once. They kicked off the workflow with 15 users and it froze up the server. Now I’m tasked with figuring out the why and how to fix it.

     

    I did the following stress tests in a development environment with some interesting results:

    - I ensured the same steps were taken for each test and only the workflow changed.

    - For each test I initiated 90 workflows.

     

    Test 1:

    -         Original WF

    -         W3WP Process

    o       Started at 92MB

    o       Spiked at 357 MB

    o       Leveled at 256 MB

    -         OWSTIMER Process

    o       Started at 97MB

    o       Spiked at 256 MB

    o       Leveled at 252 MB

     

    Test 2:

    -         Original WF with 1 second throttle between when each item is added

    -         W3WP Process

    o       Started at 105 MB

    o       Spiked at 282 MB

    o       Leveled at 265 MB

    -         OWSTIMER Process

    o       Started at 101 MB

    o       Spiked at 277 MB

    o       Leveled at 247 MB

     

    Test 3:

    -         Basic WF – 1 Step, 1 Action (write to history table)

    -         W3WP Process

    o       Started at 77 MB

    o       Spiked at 264 MB

    o       Leveled at 262 MB

    -         OWSTIMER Process

    o       Started at 96 MB

    o       Spiked at 99 MB

    o       Leveled at 98 MB

     

    Test 4:

    -         Basic WF Throttled – 1 Step, 1 Action (write to history table)

    -         W3WP Process

    o       Started at 87 MB

    o       Spiked at 167 MB

    o       Leveled at 166 MB

    -         OWSTIMER Process

    o       Started at 101 MB

    o       Spiked at 103 MB

    o       Leveled at 101 MB

     

    Test 5:

    -         OOTB Approval WF

    -         W3WP Process

    o       Started at 83 MB

    o       Spiked at 202 MB

    o       Leveled at 181 MB

    -         OWSTIMER Process

    o       Started at 101 MB

    o       Spiked at 112 MB

    o       Leveled at 105 MB

     

    Conclusions:

    -         Throttling significantly reduces the initial spike of memory usage for the W3WP process.

    -         OOTB approval workflow seems significantly more efficient with resources then even the simplest SPD workflows.

    -         The OWSTIMER process only make a significant jump in memory when I use the pause step.

    Wednesday, March 30, 2011 5:54 PM

All replies

  • Hello,

     Any code based, compiled VS workflow will be more memory efficient then the declarative SPD workflows which are not compiled, don't run from the GAC, etc.  No doubt about it.  If you need your workflow to be highly memory efficient you need to write it in VS or in SPS 2010, you can write it in SPD 2010, import into VS, and then complete as code.

    Thanks!

    Tom


    Tom Molskow - SharePoint Architect - Microsoft Community Contributor 2011 Award - Linked-In - SharePoint Gypsy
    Thursday, April 21, 2011 1:47 AM