You are viewing limited content. For full access, please sign in.

Question

Question

Pros & Cons of Running Workflow Activities Within Workflow?

asked on May 17, 2022

I am looking for ways to speed up some of most intense Workflow processes. I have been evaluating updates to the workflows themselves, database queries, etc. One thing that I have been wondering about is in the Workflow Administration Console-> Advanced Server Options-> Activity Performance, changing the configuration for the 'Run the following activities as tasks' and 'Run the following activities in an external process'. The help file says it will run the activities within Workflow, but not a lot of other information can be found about changing those settings.

What are the pros and cons of checking or unchecking the boxes listed?

2 0

Answer

SELECTED ANSWER
replied on May 18, 2022

Changing those settings is not recommended. Running activities in-process rather than as tasks will remove a lot of the infrastructure in place to protect performance and stability.

As Jason said, you could run database queries outside of the task system to gain some speed, but you are now putting more load on SQL both on the data source and on Workflow's SQL database because of the higher number of concurrent execution. Additionally, any driver instability will now be transferred to the Workflow server instead of being isolated in the task subsystem. ODBC driver crashes are very rare, but they do happen. If we're talking script activities, then crashes are not so rare anymore.

Overall, unless you have a specific problem to address and instructions from Tech Support, don't change them.

2 0
replied on January 27, 2023

@████████ we have a workflow server that has 4 workflows that run, none of them at the same time as 1 kicks off the other and they are set to run in 'Single instance mode'. They do various SQL queries (none very intensive) and run some scripts that create a CSV file. Do you think running those activities in-process rather than as tasks cause the issues that you mentioned?

 

0 0
replied on January 27, 2023

I will refer you back to this line: " Overall, unless you have a specific problem to address and instructions from Tech Support, don't change them." wink

From your description, it does not sound like the activities would spend much time if any in the execution queue. So there's no real benefit to moving them in-process.

1 0
replied on January 27, 2023

Thank you for the reply. While I was waiting, I decided to give it try and see what happened. It looks to have cut the queries and script times in about 1/2 and didn't increase the utilization of the CPU or RAM very much. For these specific workflows there are always documents waiting to be processed and has a financial impact, so the more we are able to push through the better for the company. While the overall time per query and script is not very long, it does add up. I'll be keeping an eye on the system and re-evaluate to see if it's something we want to keep in place. Thank you again for your expertise.

0 0
replied on January 27, 2023

Moving scripts out of tasks is riskier as you could have memory leaks or improperly disposed objects that may now affect the performance of Workflow Server directly. The option is for all scripts, so they may not even be in these workflows.

1 0

Replies

replied on May 17, 2022 Show version history

This is a bit anecdotal and speculative, but based on my experience fine tuning our various workflow servers over the years, I'd imagine it relates to how/if the workload is delegated.

When you run activities as tasks or external processes, it offloads the work so the activity is not consuming workflow's resources and they are available for other activities.

i.e., running them externally benefits the "overall" throughput/performance of the workflow server.

On the other hand, when you run them within workflow, there is probably less overhead and they can be executed more quickly, but they have more impact on the overall system.

I'd imagine it is comparable to how the DCC works, just more local and on a smaller scale.

Either you can have the main workflow threads doing all the work, or you can delegate some things to a subtask/subprocess and workflow can do other things while waiting for those to finish.

 

As for pros/cons,

I think turning those settings on means they aren't going to tie up resources that could be used for other things so your server can process more volume overall, but those specific tasks might be slower and could be prone to other (albeit rare) problems associated with asynchronous jobs.

Turning those settings off means they could possibly run faster, but they will be consuming a work thread as long as they are running so other things might have to wait; this could be especially impactful with large/long running queries or complex scripts.

As an example, I have some scripts that rescale document images if they are more than 300 DPI, I absolutely want that running as a task outside of workflow because drawing and image rendering activities like that can eat up a lot of memory and/or cause problems if something goes wrong.

On the other hand, if I have a high volume of lightweight database queries, I may not want those to run as tasks because I need them to be as efficient as possible and since they play a critical role in most of my workflows on that particular server, whatever impact they might have on overall throughput isn't as much of a concern.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.