locked
Workflow performance on batch processing RRS feed

  • Question

  • Hi, I'm just getting familiar with WF4 and have done some basic testing. I find the performance pretty poor, and I wonder if it's possible for me as a developer to do something with it. I'll explain:

    I'm creating a service where the input is a batch of ~1000 entities which will be processed by a Workflow. For testing purposes I created a unit test that sent a list of 30 items to an activity that takes an array of that object type as input and processes them with the ForEach-activity. Inside the ForEach there are two simple If-else activities that assign a value to a property of the individual objects depending on the result. Executing this loop in a unit test took ~8 seconds, which means ~250ms per iteration. If I would have coded that as C# code with if/else, the total time would have been in milliseconds.

    Now I understand why there is an overhead here - we're not dealing with compiled code. But are the statements (i.e. the conditions in the individual workflow actions) not compiled before execution? Are they evaluated each time for each iteration?

    I have also tried to run the code in Release mode from a Form without improvement. I also understand I could do a ParallellForEach, but that would not decrease the total CPU-Core-hours (if that is a unit of measurement).

    So, is it anything I can do programatically to improve performance and decrease CPU load?

    Thursday, November 10, 2011 3:46 PM

Answers

  • Turns out there is a HUGE difference whether you run the solution through Visual Studio or not, regardless of the build configuration (debug/release). Running the release-build directly from the shell now made the 30 iterations run with an average of 9ms per iteration. This is how it SHOULD be! :-)

    • Marked as answer by FrodeNilsen2 Friday, November 11, 2011 11:19 AM
    Friday, November 11, 2011 11:19 AM

All replies

  • Each activity is a unit that has the potential to incur some overhead with the hooks for tracking, persistence, etc- if you don't need to track or persist at the iteration level, you could move some of the batch processing to C# code within a custom activity and see how that improves speed.

    Thursday, November 10, 2011 9:19 PM
  • It's not that clear from your description, whether you are doing multiple Workflow Invokes, etc but you might find this a good read:

    http://blogs.msdn.com/b/rjacobs/archive/2011/02/12/wf4-performance-tip-cache-activities.aspx

    Tim

    Friday, November 11, 2011 9:04 AM
  • Each activity is a unit that has the potential to incur some overhead with the hooks for tracking, persistence, etc- if you don't need to track or persist at the iteration level, you could move some of the batch processing to C# code within a custom activity and see how that improves speed.

    If I move the business logic to C# code, I lose the benefit of using workflow.

    If I move the loop function to C# code, I'll have to do multiple Workflow invokes, which increases execution time even more.

    Friday, November 11, 2011 10:20 AM
  • It's not that clear from your description, whether you are doing multiple Workflow Invokes, etc but you might find this a good read:

    http://blogs.msdn.com/b/rjacobs/archive/2011/02/12/wf4-performance-tip-cache-activities.aspx

    Tim


    I'm not duing multiple Workflow Invokes. The loop is in the workflow itself as a ForEach activity.

    edit: The foreach-activity is in one Activity-file, and the logic is in the other. I'll try to merge them, maybe this is an issue. I'm baffled over how the guy in the example you linked to managed to run ANY workflow at 4ms per iteration. i must be doing something seriously wrong.

    Friday, November 11, 2011 10:20 AM
  • Turns out there is a HUGE difference whether you run the solution through Visual Studio or not, regardless of the build configuration (debug/release). Running the release-build directly from the shell now made the 30 iterations run with an average of 9ms per iteration. This is how it SHOULD be! :-)

    • Marked as answer by FrodeNilsen2 Friday, November 11, 2011 11:19 AM
    Friday, November 11, 2011 11:19 AM