Bookshelf Home | Contents | Index | Search | PDF

Performance Tuning Guide > Tuning the Siebel Application Object Manager for Performance > Best Practices for AOM Tuning >

Tuning AOM Components for CPU and Memory Utilization

---

This section provides background information and guidelines for tuning your AOM components, particularly for setting values for the parameters MaxTasks, MaxMTServers, and MinMTServers.

Settings for these parameters determine how well the system performs under specific user load and operations. Parameter settings provide a means of controlling the server capacity through the Siebel Server infrastructure, and directly impact the overall capacity for each server.

How you set the MaxTasks, MaxMTServers, and MinMTServers parameters is a direct function of the factors described in Performance Factors for AOM Deployments, which determine the true capacity of the server.

NOTE:  The art of tuning AOM components is to come up with the right parameter settings that allow the server machines to host the largest number of users (scalability) with minimal impact on user response time (performance).

About MaxTasks, MaxMTServers, and MinMTServers

The AOM parameters MaxTasks, MaxMTServers, and MinMTServers are described below. You configure these parameters using Siebel Server Manager, which is described in detail in Siebel Server Administration Guide.

For background information about multithreaded processes, threads, and related concepts, see AOM Infrastructure.

• MaxTasks (Maximum Tasks). Specifies the total number of tasks (threads) that can run concurrently on this AOM, for this Siebel Server. Beyond this number, no more tasks can be started to handle additional requests.
• MaxMTServers (Maximum MT Servers). Specifies the maximum number of multithreaded processes that can run concurrently on this AOM. Beyond this number, no more multithreaded processes can be started to handle additional requests.
• MinMTServers (Minimum MT Servers). Specifies the default minimum number of multithreaded processes that will start on this AOM when the parent process is started. The parent process may be started either explicitly (using Siebel Server Manager) or automatically (if the Siebel Server is started when the component state was last set to Running). Setting MinMTServers to 0 effectively disables the AOM component.

As more users log in, new tasks start to handle these sessions, and new multithreaded processes are started to support the additional tasks. The tasks and processes are added according to the AOM load-balancing behavior, up to the maximum number of tasks and maximum number of multithreaded processes. For details, see Effect of AOM Parameter Settings, below.

NOTE:  MaxTasks, MaxMTServers, and MinMTServers are generic parameters that apply to many different Siebel Server components. However, much of the behavior described in this chapter is unique to AOM components. For more information, refer to Siebel Server Administration Guide.

These parameters relate to one another in the following ways:

• MaxMTServers and MinMTServers are typically set to the same value. This is to avoid any performance penalty for a user whose login causes a new multithreaded process to start. (MaxMTServers must be equal to or greater than MinMTServers.)

  Starting all multithreaded processes up front when the parent process is started is generally acceptable. The memory overhead for running a multithreaded process itself, apart from the overhead of its threads, is minimal.

• The ratio MaxTasks/MaxMTServers determines the maximum number of threads (tasks) that can run concurrently on a given multithreaded process. For more information, see the discussion of think time under Performance Factors for AOM Deployments.

Effect of AOM Parameter Settings

This section illustrates how an AOM behaves given particular example settings for the MaxTasks, MaxMTServers, and MinMTServers parameters. More realistic examples may be found in Formulas for Calculating AOM Parameter Values.

For example, if MaxTasks = 500, and MaxMTServers = 5, then the ratio MaxTasks/MaxMTServers = 100. This means that, at most, 100 threads (tasks) can run in a multithreaded process on this AOM.

Typically, MinMTServers would be set the same as MaxMTServers. However, in this example, assume MinMTServers = 4. In this case, four multithreaded processes start by default, which can handle a total of 400 concurrent threads.

As users start the application on the server, the number of concurrent threads rises, and the following occurs:

• As the number of concurrent threads rises, but remains below 400, these threads are distributed among the four multithreaded processes that started by default for this AOM. This is a form of load balancing internal to the AOM component. (It is based on operating-system scheduling, and is unrelated to load balancing done by Resonate Central Dispatch or done at the Web server level.)
• If the number of concurrent threads reaches 400, and a new request is received, a fifth multithreaded process starts for this AOM. The AOM now distributes threads among five multithreaded processes for this AOM.
• If the AOM reaches 500 concurrent threads, no more client session requests can be handled, because the existing multithreaded processes can start no more threads, and the AOM can start no more multithreaded processes. The AOM can be said to be "maxed out."

If AOM loads fall back, as users log out or session timeouts are enforced, then threads are freed up. In some cases, a multithreaded process whose threads have completed may also time out and stop running (this can happen only when MaxMTServers is greater than MinMTServers).

Guidelines for Configuring AOM Parameters

This section provides formulas and guidelines for setting the MaxTasks, MaxMTServers, and MinMTServers parameters for your AOM components.

NOTE:  All elements in the two formulas shown in Formulas for Calculating AOM Parameter Values vary according to your deployment. The number of concurrent users an AOM can support will depend on factors such as the number of processors, session timeout settings, and the average think time.

Typically, the AOM is the only component using significant resources on the Siebel Server machine. If you run multiple server components, or run non-Siebel modules, then an AOM on this machine may support fewer concurrent threads.

Follow these general steps to determine how to set these parameter values:

• Determine the total number of concurrent users, based on the average think time and other factors discussed earlier.
• Determine the number of concurrent users that must be supported on a given Siebel Server machine running AOM. In the formulas outlined below, this is the target number of users plus the number of anonymous browser users. Also determine the number of anonymous users.
• Determine how many Siebel Server machines are needed to support your concurrent users. This is typically done by Siebel Expert Services or by platform vendors.
• Plug your values into the formulas below, then adjust the values to meet any additional criteria. In particular:
  • If your calculated value for MaxMTServers is not an integer, then round up the value to the nearest integer.
  • After you adjust the value of MaxMTServers, if your calculated ratio for MaxTasks/MaxMTServers is not an integer, then round up the value of MaxTasks until this ratio is an integer.
• Test your initial parameter settings, such as to gauge the actual number of anonymous users required, then adjust settings further as necessary.

Formulas for Calculating AOM Parameter Values

Use the formulas below for calculating parameter values for your AOM components:

• MaxTasks = target_number_of_users + anon_browser_users + anon_users
• MaxMTServers = (target_number_of_users + anon_browser_users)/100
• MinMTServers = MaxMTServers

As necessary, after making your initial calculations, round up MaxMTServers to the nearest integer, calculate the remainder (X) of MaxTasks/MaxMTServers, then increment MaxTasks by adding (MaxMTServers - X). You do this to make sure that the ratio of MaxTasks/MaxMTServers is an integer.

NOTE:  The figure of 100 in the MaxMTServers formula represents the ratio of concurrent tasks per multithreaded process. The value of 100 is a rule of thumb only. For details, see below.

Variables in the above formulas are described below:

• target_number_of_users = The maximum number of concurrent user sessions your AOM will support (for users who are logged into the application).

  The maximum number of concurrent users is limited by the value of the MaxTasks parameter for the AOM, by the number of multithreaded processes you are running (determined by MaxMTServers and MinMTServers), and, effectively, by your hardware resources.

• anon_browser_users = The number of sessions on the AOM dedicated to anonymous browser users (threads that support users who do not log in).
  • For high interactivity applications (typically, employee applications like Siebel Call Center), anonymous browser users (anon_browser_users) are not supported, so this is not a factor.
  • For standard interactivity applications (typically, customer applications like Siebel eService), anonymous browser users (anon_browsers) may be approximately 25% of the target number of users.
• anon_users = The number of sessions on the AOM dedicated to the anonymous user (threads that are used for login purposes).
  • For applications where users log in and out infrequently (typical of high interactivity applications), anonymous users (anon_users) may be approximately 5% of the target number of users. Assume a higher figure if the peak number of simultaneous login requests is high, such as may occur during shift changes in a call center operation.
  • For applications where users log in and out frequently (typical of standard interactivity applications), anonymous users (anon_users) may be approximately 20%, or as high as 90%, of the target number of users. Assume a higher figure if the peak number of simultaneous login requests is very high, such as may occur in certain online customer applications.

    NOTE:  Requirements for the size of the anonymous user pool may vary significantly and must be based on the usage characteristics of each implementation. The pool should be closely monitored to make sure it has sufficient resources during peak load periods.

• 100 = The approximate maximum number of concurrent threads each multithreaded process on the AOM can support. The number 100 is a rule of thumb. Use the number that is appropriate for your deployment.

  NOTE:  A ratio of 100 for threads per multithreaded process works for most AOM usage scenarios. However, if your deployment involves a shorter think time than 30 seconds, or a heavier than average load per thread, each multithreaded process will support fewer concurrent threads. Conversely, a longer think time or a lighter average load will support more concurrent threads. For more information about how the ratio of threads per multithreaded process relates to think time, see Performance Factors for AOM Deployments.

Example Settings for AOM Parameters

Along with other factors such as think time, the calculation of MaxTasks, MaxMTServers, and MinMTServers depends on your assumptions for target_number_of_users, anon_browser_users, and anon_users, which are described above. Example settings follow for Siebel Call Center and Siebel eService.

Example Settings for Siebel Call Center

For Siebel Call Center, assume (for example) a think time of 30 seconds, and assume that target_number_of_users = 500. For this application, anon_browser_users is not a factor. Depending on your implementation, anon_users might be about 5% of target_number_of_users (or 25). Your preliminary parameter values would be:

MaxTasks = (500 + 25) = 525

MaxMTServers = (500 + 25)/100 = 525/100 = 5.25 = 6 (round up)

MinMTServers = MaxMTServers = 6

Adjust the value of MaxTasks. The variable X = the remainder of (525/6) = 3. Increment MaxTasks by (MaxMTServers - X): 525 + (6 - 3) = 525 + 3 = 528. Therefore, the final calculations for parameter values would be:

MaxTasks = 528

MaxMTServers = MinMTServers =6

Example Settings for Siebel eService

For Siebel eService, assume (for example) a think time of 30 seconds, and assume that target_number_of_users = 500. Depending on your implementation, anon_browser_users might be about 25% of target_number_of_users (or 125), and anon_users might be about 20% of target_number_of_users (or 100). Your preliminary parameter values would be:

MaxTasks = (500 + 125 + 100) = 725

MaxMTServers = (500 + 125)/100 = 6.25 = 7 (round up)

MinMTServers = MaxMTServers = 7

Adjust the value of MaxTasks. The variable X = the remainder of (725/7) = 4. Increment MaxTasks by (MaxMTServers - X): 725 + (7 - 4) = 725 + 3 = 728. Therefore, the final calculations for parameter values would be:

MaxTasks = 728

MaxMTServers = MinMTServers =7

Anonymous User Pool on Siebel Web Server Extension

Calculations for anonymous browser users and anonymous users are part of the formulas for setting MaxTasks, MaxMTServers, and MinMTServers. The significance of these figures relates specifically to settings on the Siebel Web Server Extension (SWSE) that define anonymous user pools for one or more applications.

The size of the anonymous user pool should be based on the number of customers performing anonymous browsing without logging in as a registered user, and on how many users log in concurrently and how long each login takes.

After performing your initial MaxTasks sizing, review the SWSE stats page to gauge the actual size of the anonymous user pool at one time, and adjust your MaxTasks setting as needed.

The AnonUserPool parameter, located in the eapps.cfg file in the SWSE installation, determines the maximum size of the anonymous user pool for all affected applications served by the Web server:

• If AnonUserPool is defined in the [defaults] section of the eapps.cfg file (its default location), it affects all Siebel applications that connect through that Web server.
• If AnonUserPool is defined in a section of the eapps.cfg file that is specific to a particular application, it affects only that application.

Previous examples assumed anon_users = 25 for Siebel Call Center, and anon_browser_users = 125 and anon_users = 100 for Siebel eService.

• If a single Web server routes requests to both of these applications, and to no others, then you could define AnonUserPool in the [Default] section, and set it to 250 (25 for Siebel Call Center and 225 for Siebel eService).

  Or, you could define AnonUserPool in separate sections for each application, and provide separate values for each application (25 for Siebel Call Center and 225 for Siebel eService).

• If two Web servers route requests to one Siebel Server, then you might cut the AnonUserPool values in half, as configured in the eapps.cfg file for each SWSE installation, to maintain the correct total figures.

NOTE:  The anonymous user pool also includes guest users, which are users who are logged in on a guest basis. Guest users apply to standard interactivity applications only. Anonymous browser users and guest users are subject to different timeout settings, using the parameters AnonSessionTimeout and GuestSessionTimeout, located in the eapps.cfg file in the SWSE installation. Your sizing calculations for anonymous browser users should consider guest users and all applicable timeout values affecting anonymous browser and guest user sessions.

For more information about the stats page and about the eapps.cfg file parameters AnonUserPool, AnonSessionTimeout, and GuestSessionTimeout, refer to Siebel Server Installation Guide for the operating system you are using and Security Guide for Siebel eBusiness Applications.

Bookshelf Home | Contents | Index | Search | PDF