Siebel Performance Tuning Guide > Tuning Siebel Workflow for Performance > Tuning Workflow Processes >
Monitoring Memory Overhead for Workflow Processes
Overhead and performance and scalability characteristics varies depending on whether you are running workflows locally in the AOM or in Workflow Process Manager (WfProcMgr), and also on where you run WfProcMgr. The performance and scalability characteristics also depend on whether you are using asynchronous mode for workflow process requests.
For more information, see Siebel Deployment Planning Guide and Siebel Business Process Framework: Workflow Guide.
Running Workflows Locally in AOM
A workflow instance—that is, one run of a workflow definition—can run within an AOM. 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-200 KB) to the user session memory (sometimes referred to as the model) plus memory taken up by other objects (such as business components) contained in the tasks within that workflow.
In general, this option provides the best performance, but is suitable only where scalability is not an important factor.
Running Workflows in Workflow Process Manager
The workflow itself runs within a separate component, 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.
You can optionally run WfProcMgr on the same Siebel Server (colocating) as the AOM where the workflow is invoked, or run it on dedicated Siebel Server machines. Compared to running workflows locally, running workflows in WfProcMgr may reduce performance, but improve scalability. Running WfProcMgr on dedicated Siebel Servers typically provides the best scalability, while colocating WfProcMgr and AOM may provide better performance.
About Asynchronous Mode for Workflow Process Requests
For all Workflow Processes deployment options described previously, workflow process requests can be handled synchronously or using asynchronous mode. Using asynchronous mode comes with the following pros and cons:
- All user threads are not loaded.
- More scalable as long as:
- 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.
- On error, you must look at the log files because there is no automatic notification.
- The SRBroker could have a timeout or retry feature.
- Slightly more latency. Additional cost (minimal) of one request per response.