workflow performance issue

Hi,
We have a complex workflow whereby around 20 Jobs are being created through a perl script at one time. At the time this script runs, the TeamSite Server is just frozen. For nearly 15 minutes, we cannot do any work on it.
Are there any ways the performance can be improved. We do have enough resources on the TS server which otherwise runs quite fast.
Would appreciate any help.
We are using TS Version: 5.0.1
Here is the part of the code which creates the job...
#################################################################
sub createJob {
#print "Template_file:" . $workflowfile;
my $wft = TeamSite::WFtemplate->new(
template => $workflowfile,
user => $workflowuser,
vpath => $vpath,
file => [],
debug => 0);
$wft->{tag}{'iw_user'}{value}="$workflowuser";
$wft->{tag}{'iw_branch'}{value}="$branch";
$wft->{tag}{'iw_workarea'}{value}="$vpath";
if (!defined $wft)
{
........
}else {
my @field_name_set = $wft->get_tags();
my $spec = $wft->get_workflow();
if (!defined $spec)
{
........
}else{
my $wf_system = TeamSite::WFsystem->new();
if (!defined $wf_system)
{
........
} else {
$workflow = $wf_system->CreateWorkflow($spec,$tempworkflowfile);
if ((!defined $workflow) || !$workflow->IsValid() || $workflow->GetError())
{
........
}else {
my $firsttask = $workflow->Invoke();#$workflow = new TeamSite::WFworkflow($wf_id);
($success, $factbooktask) = $workflow->GetTaskByName($taskname);
$taskid = $factbooktask->GetId();
}
}
}
}
}
#################################################################

Find more posts tagged with

Comments

Adam Stoller

I don't think this has ever been QA'd this way (though it's definitely an idea that I shall pass along).

Questions:
1) If you just run this to create one job - do you have problems with the server? If not, how about 5 jobs? 10 jobs? (i.e. can you find an approximate threshhold?)

2) If you put a 'sleep' into the process (1 second? 2 seconds? ...) does that help? (if so, at what value does it seem to help?)

I know there has been some performance improvements with regard to Workflow in 5.5.2 - but again, I don't believe this particular test has been used internally before (I could be wrong).

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

What are these 20 jobs doing when they start? Could the problem be that they are running CPU-intensive processes, rather than a problem with the creation of the jobs?

Your code looks fine. One thing that you might try is putting a short delay between the creation of these jobs. Perhaps they are competing for resources.

And of course I am obligated to suggest that you consider upgrading to version 5.5.2 which has drastically improved performance in many areas.

Brinko Kobrin
Interwoven Staff Engineer

rishi

Thanks for your tips.
The time the server is frozen varies as per the number of jobs that are created. The jobs are created in a loop, after parsing an XML file.
Sleep does not seem to help but instead just freezes the server for a longer time.
The 20 jobs are a separate workflow called from 1 workflow. Since, we need them to be mutually independent, we are not using nested jobs.
The other processes (XML parsing, etc) do not take a high amount of time. In fact, when i run the process without the job creation, it runs fine - does not hose the server.
The upgrade to version 5.5.2 is certainly under consideration.
But, I am not sure if this issue will be solved with the upgrade.
I cannot test a lot as we have a single development-production TeamSite server. ;-(

Migrateduser

Have you tried creating one of the "child" jobs without using the master workflow to see if that alone freezes the server? Alternatively, you could try to create 20 trivial jobs. If a job is freezing the server (and not actually calling iwfreeze), I would first suspect that (1) the job is performing some TeamSite-intensive operation (like creating hundreds of files), (2) the job is performing some CPU-intensive operation, or (3) the system is low on virtual memory. If (1) is the case, 5.5.2 would almost certainly help because almost all file operations were drastically sped up.

I have run tests on 5.5.2 where one job launched hundreds of other jobs in a tight loop and there was no problem. However, I don't know what the performance is like on 5.0.1.

Brinko Kobrin
Interwoven Staff Engineer

rishi

By freeze, I do not mean calling iwfreeze, but slowing down the server so much that no users are able to use it.
Job is not creating any files but attaching aruond 5-8 files per job.
Job is also having logic to find a duplicate job and then calling iwrmjob to delete it - a client requirement. I tried running without this, but it was still slow.
System has around 5GB of Virtual memory.
I am unable to test much now. Will post, after more testing.