Performance Tuning Guide > Tuning Siebel Workflow for Performance > Tuning Workflow Processes >

Monitoring Memory Overhead


Overhead varies depending on whether you are running workflows locally or in Workflow Process Manager.

Running Workflows Locally

A workflow instance—that is, one run of a workflow definition—can run within a UI object manager (UI/OM). In this case, the workflow runs locally, within the current thread that the logged-in user is using. This means that if N users are connected and they all need to run a workflow definition, the definition would run in that user thread.

In this mode, Workflow adds a fixed overhead (100-200K) to the user memory (usually referred to as the model) plus memory taken up by other objects (such as business components) contained in the tasks within that workflow.

Running Workflows in Workflow Process Manager

The workflow itself runs within a separate Application Object Manager (AOM), which uses a fixed set of resources (parameters MaxMTServers, MaxTasks) to schedule the workflow.

The Workflow Process Manager (component alias: WFProcMgr) is a multithreaded process that runs multiple workflows and is more scalable because it uses a pool of threads and models.

Generally, the mode of the workflow used depends on what the application is trying to achieve. It is generally recommended that you try to schedule a workflow task in the WFProcMgr, especially if the results of a run are not immediately needed.

Asynchronous Mode

Use of the asynchronous mode comes with the following pros and cons:

Pros
 
Cons
  • All user threads are not loaded.
  • On error, you must look at the log files because there is no automatic notification.
  • More scalable as long as:
  • The SRB could have a timeout or retry feature.
 
  • There are maximum N simultaneously connected users.
  • There are maximum X simultaneous running workflows.
  • If X is smaller than N, then a WFProcMgr with X tasks can handle a much larger pool (N) of users.
  • Slightly more latency. Additional cost (minimal) of one request per response.

 Performance Tuning Guide 
 Published: 24 October 2003