Bookshelf Home | Contents | Index | Search | PDF

Performance Tuning Guide > Tuning the Siebel Application Object Manager for Performance >

Performance Factors for AOM Deployments

---

In planning to deploy AOMs, or in troubleshooting performance for existing AOM deployments, you must consider several factors that determine or influence performance.

Factors that are central to the task of configuring the AOM are also called performance drivers. Performance drivers for AOM include concurrent users and average think time. Other important factors such as hardware resources will set limits on overall capacity or capacity per server.

Subsequent sections provide information and guidelines to help you achieve and maintain optimal performance and scalability.

These factors are critical in initially configuring your AOMs, particularly when specifying values for the AOM component parameters MaxTasks, MaxMTServers, and MinMTServers, which are discussed in Tuning AOM Components for CPU and Memory Utilization.

Concurrent Users

The number of concurrent users is the total number of user sessions supported at any one time. It also includes sessions supporting user logins (anonymous user sessions) or anonymous browser users. For planning and tuning purposes, you must consider concurrent users (and total users) at multiple levels:

• The entire deployment (enterprise)
• Each Siebel Server
• Each AOM component on each server
• Each multithreaded process for each AOM component

The maximum number of concurrent users per Siebel Server—assuming, for example, the application server machine is dedicated to running AOM components—will depend on the average think time, on your hardware resources, and on the nature of your Siebel applications deployment.

In terms of configuration, the maximum number of concurrent users for the AOM is limited by the value of the MaxTasks parameter. The effective maximum is limited by the number of multithreaded processes and by your hardware resources.

Depending on the average think time and other factors, each multithreaded process (process within the AOM) typically supports a maximum of about 100 concurrent users. Configure enough multithreaded processes (using the MaxMTServers parameter) to support your maximum number of concurrent users (peak loads).

Average Think Time

The average think time is the time between operations assumed for your application users. For example, after a user has executed a query, the think time is how long the user reviews a record before taking some other action that sends a request to the AOM.

The assumed think time has a direct relationship to the number of concurrent tasks that a multithreaded process can support. The ratio of 100 (100 tasks per process), based on a 30-second think time, is assumed in the formula for setting the MaxMTServers parameter. This formula is presented in Tuning AOM Components for CPU and Memory Utilization.

The ratio of 100 is based on having approximately three users running operations at the exact same time (100/30 = approximately 3.3). It is generally observed that each multithreaded process can handle about three operations at the same time with minimal performance degradation.

With longer think times, one multithreaded process may support more than 100 concurrent tasks; with shorter think times, fewer.

For example, if the think time is 15 seconds between user operations, then about 50 tasks per process could be supported (15 * 3.3 = approximately 50, or 50/15 = approximately 3.3.

NOTE:  The ratio of concurrent tasks per multithreaded process varies based on the level of customization or the use of process automation for the application the AOM supports.

You need to determine the average think time based on the usage patterns typical of your user base. After the application has been configured, perform a clickstream analysis for your key processes, and try to capture the time between the user actions that are represented by the clicks. Consider the average time between each transaction, and calculate the overall average think time based on these factors.

Nature of Siebel Application Deployment

Which Siebel applications and other modules you are using, how you have configured your Siebel applications, how you have deployed your applications, and other such factors also affect AOM performance and how many concurrent users you can support. Some of these factors include:

• Will you support employee applications (such as Siebel Call Center), customer applications (such as Siebel eService), partner applications (such as Siebel PRM), or some combination of these? Typically, employee applications use high interactivity and customer applications use standard interactivity.
• Will you deploy your Siebel software in a global environment using multiple languages?
• What degree and what kind of application configuration changes have you made, such as those you do using Siebel Tools?
• Will you use specialized functionality such as offered by Siebel eConfigurator (for product configuration) or Siebel CTI (telephony integration for call center agents)? How will you deploy such functionality? What percentage of your user base will use such functionality?

Hardware Resources

Hardware resources for each Siebel Server machine, particularly CPU and memory, are a factor in how many concurrent users can be supported for each AOM component. For example, a four-way machine has twice the resources of a two-way machine and can potentially support twice as many concurrent users. Key hardware resources for AOM performance include:

• CPU. The CPU rating and the number of CPUs per server machine.
• Memory. The amount of RAM, and whether it can accommodate users without excessive paging.

Disk I/O and network capacity are other important hardware factors, but they do not affect AOM tuning. They do significantly affect performance for the Siebel Database and the Siebel File System.

The total number of machines you can devote to supporting AOM components will determine the total number of concurrent users.

Bookshelf Home | Contents | Index | Search | PDF