Forked Task Processes for a Workflow

A curious issue has been raised against teamsite performance when a workflow with a lot of tasks is initiated. To put the question simply:
"Every task on first activation is forked as a new process (OS specific). Upon succession the previous task may be inactiavted but the process for predecessor tasks is still very much in memory. So if I'm on a nth task in the workflow, there are (n-1) processes running for the workflow + maybe one master process for the job."

I find it rather hard to believe, given I don't have much hands on with Teamsite.

Please enlighten me on if this is true and why this is so. Why should the inactive task processes be still in memory? This would be a huge performance impact if we have big workflows with multiple tasks. Would really appreciate best-practices so as to mitigate this.

Find more posts tagged with

Comments

Adam Stoller

I can neither confirm nor deny the implementation specifics (don't know them) - but it might help if you provided a bit more information about your environment:

What version of TeamSite?
What platform?

I know there were some significant improvements to Workflow performance in 5.5.2 - and probably more on the way - but if we don't know where you are, it's hard for us to tell you if there is something you can do about it "now".

--fish
(Interwoven Senior Technical Consultant)

kapil_koul

This was reported on: Teamsite 5.5.2 (Solaris 5.8).
I have come to know of 2 mitigations:
1. Break up the workflow into multiple workflows and when transitioning to the next workflow, killing the previous workflow job.
2. Using nested workflows. As soon as the nested workflow is complete the job corresponding to it goes out of memory.

But as I said, I have very little hands-on-experience with Teamsite and so am not sure whether these are the correct approaches.

Now that you speak about "platforms", is is possible that it was implemented differently for Microsoft platforms. If, yes, then please provide any details.

james1

> "Every task on first activation is forked as a new process (OS
> specific). Upon succession the previous task may be inactiavted
> but the process for predecessor tasks is still very much in
> memory. So if I'm on a nth task in the workflow, there are (n-1)
> processes running for the workflow + maybe one master process
> for the job."

This is quite far from the truth. How did you come to this conclusion?

All workflow processing (i.e., task activation and inactivation) occurs within the iwserver process. External tasks are fork()ed to run whatever program you instruct the workflow engine to run. CGI tasks are separate (CGI) processes, running in a web server environment. You should not have N+1 processes running for a workflow "on the Nth task".

-- James

--
James H Koh
Interwoven Engineering

kapil_koul

Thanks for clearing that up. But one more question regarding this, do all the jobs(workflow instances) run in the same iwserver process (with external tasks ofcourse being forked). So of I have ten content items going through ten different jobs(workflow instances), how may processes is that? Should be "1", right..

Edited by kapil_koul on 02/28/03 00:48 AM (server time).