Guidelines for Siebel Application Object Manager Tuning

Using your hardware resources optimally and configuring your system appropriately can help you to achieve your performance goals. Consider your resources and requirements carefully, and test and monitor system performance on a continual basis.

Review information presented in Siebel System Administration Guide and other sources. All tuning calculations must be done with some understanding of the overall system and the considerations described in "Performance Factors for Siebel Application Object Manager Deployments".

Review the following for more information about Siebel Application Object Manager tuning:

• "Tuning Siebel Application Object Manager Components for CPU and Memory Utilization"

• "Tuning Parameters for Siebel Application Object Manager Caches"

• "Additional Parameters Affecting Siebel Application Object Manager Performance"

• "Memory Consumers in Siebel Application Object Manager"

Tuning Siebel Application Object Manager Components for CPU and Memory Utilization

This topic is part of "Guidelines for Siebel Application Object Manager Tuning". It provides background information and guidelines for tuning your Siebel Application Object Manager 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 Siebel Application Object Manager Deployments", which determine the true capacity of the server.

The art of tuning Siebel Application Object Manager components is to come up with the right parameter settings that allow the server computers to host the largest number of users (scalability) with minimal impact on user response time (performance).

About MaxTasks, MaxMTServers, and MinMTServers

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

For background information about multithreaded processes, threads, and related concepts, see "Siebel Application Object Manager Infrastructure".

• MaxTasks (Maximum Tasks). Specifies the total number of tasks (threads) that can run concurrently on this Siebel Application Object Manager, 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 Siebel Application Object Manager. 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 Siebel Application Object Manager when the parent process is started. The parent process can 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 Siebel Application Object Manager 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 Siebel Application Object Manager load-balancing behavior, up to the maximum number of tasks and maximum number of multithreaded processes. For more information, see "Effect of Siebel Application Object Manager Parameter Settings".

Note: MaxTasks, MaxMTServers, and MinMTServers are generic parameters that apply to many different Siebel Server components. However, the specific behavior described in this chapter applies to Siebel Application Object Manager components. For more information, see Siebel System Administration Guide.

These parameters relate to one another in the following ways:

• MaxMTServers and MinMTServers are typically set to the same value. Doing this avoids 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 divided by 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 Siebel Application Object Manager Deployments".

Effect of Siebel Application Object Manager Parameter Settings

The following information illustrates how a Siebel Application Object Manager behaves given particular example settings for the MaxTasks, MaxMTServers, and MinMTServers parameters. More realistic examples can be found in "Formulas for Calculating Siebel Application Object Manager Parameter Values".

For example, if MaxTasks = 500, and MaxMTServers = 5, then MaxTasks divided by MaxMTServers = 100. This means that, at most, 100 threads (tasks) can run in a multithreaded process on this Siebel Application Object Manager.

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 Siebel Application Object Manager. This is a form of load balancing internal to the Siebel Application Object Manager component.

• If the number of concurrent threads reaches 400, and a new request is received, the a fifth multithreaded process starts for this Siebel Application Object Manager. The Siebel Application Object Manager now distributes threads among five multithreaded processes.

• If the Siebel Application Object Manager reaches 500 concurrent threads, then no more client session requests can be handled, because the existing multithreaded processes can start no more threads, and the Siebel Application Object Manager can start no more multithreaded processes. The Siebel Application Object Manager can be said to be "maxed out."

If Siebel Application Object Manager 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 might also time out and stop running; this can happen only when MaxMTServers is greater than MinMTServers.

Guidelines for Configuring Siebel Application Object Manager Parameters

The following information provides formulas and guidelines for setting the MaxTasks, MaxMTServers, and MinMTServers parameters for your Siebel Application Object Manager components.

Note: All elements in the two formulas shown in "Formulas for Calculating Siebel Application Object Manager Parameter Values" vary according to your deployment. The number of concurrent users a Siebel Application Object Manager can support depends on factors such as the number of processors, session timeout settings, and the average think time.

Typically, the Siebel Application Object Manager is the only component using significant resources on the Siebel Server computer. If you run multiple server components, or run non-Siebel modules, then a Siebel Application Object Manager on this computer might 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 computer running Siebel Application Object Manager. In the formulas outlined below, this is the target number of users plus the number of anonymous users, where applicable.

• Determine how many Siebel Server computers are needed to support your concurrent users. This is typically done by Oracle Advanced Customer Services or by platform vendors. Contact your Oracle sales representative to request assistance from Oracle Advanced Customer Services.

  
  

  Note: Because each customer application implementation is unique, customers are encouraged to engage Oracle Advanced Customer Services for a detailed sizing review to best assess the hardware needs to support their deployment. Oracle Advanced Customer Services has experience from thousands of implementations and works closely with Oracle's Performance and Scalability team to provide sizing guidance.

  
  

• Plug your values into the formulas in this topic, 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 divided by 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 Siebel Application Object Manager Parameter Values

Use the following formulas for calculating parameter values for your Siebel Application Object Manager components:

• MaxTasks = target_number_of_users plus anon_users

• MaxMTServers = (target_number_of_users plus anon_users) divided by 100

• MinMTServers = MaxMTServers

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

The following descriptions apply to the variables and figures used in the formulas:

• target_number_of_users is the maximum number of concurrent user sessions that your Siebel Application Object Manager will support (for users who are logged in to the application).

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

• anon_users is the number of sessions on the Siebel Application Object Manager that are dedicated to anonymous users (threads that support users who do not log in).

  • For employee applications like Siebel Call Center, anonymous users are not supported, so this is not a factor.

  • For customer applications like Siebel eService, anonymous users might be approximately 25% of the target number of users. However, the actual figure depends on the business requirements for a specific deployment, and could be much higher, for example.

• In the MaxMTServers formula, the figure of 100 is the approximate maximum number of concurrent threads that each multithreaded process on the Siebel Application Object Manager 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 Siebel Application Object Manager 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 Siebel Application Object Manager Deployments".

  
  

Example Settings for Siebel Application Object Manager 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 and anon_users, as previously described. 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_users is not a factor. Your parameter values would be like the following:

MaxTasks = 500
MaxMTServers = 500 divided by 100 = 5
MinMTServers = MaxMTServers = 5

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_users might be about 25% of target_number_of_users (or 125). Your preliminary parameter values would be like the following:

MaxTasks = (500 plus 125) = 625
MaxMTServers = (500 plus 125) divided by 100 = 6.25 = 7 (round up)
MinMTServers = MaxMTServers = 7

Adjust the value of MaxTasks. The variable X = the remainder of (625 divided by 7) = 2. Increment MaxTasks by (MaxMTServers minus X): 625 plus (7 minus 2) = 625 plus 5 = 630. Therefore, the final calculations for parameter values would be like the following:

MaxTasks = 630
MaxMTServers = MinMTServers =7

Note: The settings of MaxTasks and MaxMTServers also help determine the setting of the parameter SessPerSisnConn, which sets the number of sessions per SISNAPI connections. For more information, see "Configuring SISNAPI Connection Pooling for Siebel Application Object Managers".

Tuning Parameters for Siebel Application Object Manager Caches

This topic is part of "Guidelines for Siebel Application Object Manager Tuning".

The Siebel Application Object Manager uses several caches, which affect memory usage for the Siebel Application Object Manager. Tuning Siebel Application Object Manager caches affects Siebel Application Object Manager performance and memory usage. The following are some of the major caches used by Siebel Application Object Manager that can be configured:

• SQL cursor cache

• SQL data caches

SQL Cursor Cache

The SQL cursor cache is configured using the DSMaxCachedCursors parameter. This cache can be enabled on multithreaded components (such as Siebel Application Object Manager) with database connection pooling. The value represents the number of SQL cursors per database connection. For a Siebel Application Object Manager for which the Siebel Server computer is more likely to reach its memory capacity before it reaches its CPU capacity (for example, for Siebel Call Center), you can set DSMaxCachedCursors to a low value, even to 0. (Such an application is sometimes referred to as memory-bound.)

For a Siebel Application Object Manager for which the Siebel Server computer is more likely to reach its CPU capacity before it reaches its memory capacity, the default value of 16 for the DSMaxCachedCursors parameter might be appropriate. (Such an application is sometimes referred to as CPU-bound.)

In general, the value must reflect the CPU and memory resource availability on the Siebel Server computer running a particular Siebel Application Object Manager component. The trade-off in setting this parameter is that allocating memory to caching SQL cursors means that they would need to be created less often, but at a cost in memory.

The memory requirement per cursor depends on factors such as the size of the query, type of database connection, row size, and number or rows returned by the query. The utility of these cached cursors depends on the uniqueness of the queries that they represent. In general, most Siebel application queries are unique and would not benefit from reusing a cached cursor.

Generally, when more users share a database connection, through connection pooling, you would increase the number of cursors cached, provided that the required memory is available. For more information about database connection pooling, see "Configuring Database Connection Pooling for Siebel Application Object Managers".

SQL Data Caches

The SQL data caches are configured using the DSMaxCachedDatasetsPerProcess and DSMaxCachedDataSets parameters. Two types of data caches are guided by these parameters:

• Global data cache, which is useful in most cases. This cache is governed by DSMaxCachedDatasetsPerProcess. The default value is 16.

• Per-connection data cache (which can be enabled with, or without, database connection pooling). This cache is governed by DSMaxCachedDataSets. The default value is 16.

For a CPU-bound Siebel Application Object Manager, the default values for DSMaxCachedDatasetsPerProcess and DSMaxCachedDataSets might be appropriate.

For a memory-bound Siebel Application Object Manager (for example, for Siebel Call Center), you can set DSMaxCachedDatasetsPerProcess and DSMaxCachedDataSets to a low value, even to 0.

In general, the values must reflect the CPU and memory resource availability on the Siebel Server computer running a particular Siebel Application Object Manager component. The trade-off in setting these parameters is that allocating memory to caching SQL data sets means that they would need to be created less often, but at a cost in memory. See also the discussion of the SQL cursor cache.

Additional Parameters Affecting Siebel Application Object Manager Performance

This topic is part of "Guidelines for Siebel Application Object Manager Tuning". It provides guidelines for setting additional parameters that affect Siebel Application Object Manager performance.

• MemProtection. Setting the MemProtection parameter to FALSE for your Siebel Application Object Manager component might improve performance.

  When this parameter is TRUE (the default), each transaction issues a large number of serialized mprotect statements, the total effect of which can degrade performance on your Siebel Server computers. Setting MemProtection to FALSE can improve performance and also improve scalability.

  The MemProtection parameter is hidden. Click Hidden in the Component Parameters view tab to display it. Alternatively, you can set it using the command-line version of the Siebel Server Manager, as shown:

  change param MemProtection=False for comp component_alias_name server siebel_server_name
  

  where:

  • component_alias_name is the alias name of the Siebel Application Object Manager component you are configuring, such as SCCObjMgr_deu for the German version of Call Center Object Manager.

  • siebel_server_name is the name of the Siebel Server for which you are configuring the component.

• DSMaxFetchArraySize. This is a named subsystem parameter that controls the maximum number of records that can be returned by a business component in ForwardBackward mode. It does not restrict the number of records returned for ForwardOnly cursors. By default, DSMaxFetchArraySize has a value of 0. When this parameter is set to 0, the Siebel Application Object Manager initializes the parameter to 10,000. This means that a maximum of 10,000 records can be returned by a business component in ForwardBackward mode.

• DSPreFetchSize and DSMaxCursorSize. Set these parameters only for Siebel implementations on IBM DB2 for z/OS. For more information about setting these parameters, see Implementing Siebel Business Applications on DB2 for z/OS. For all other databases, these parameters must be set to -1.

Memory Consumers in Siebel Application Object Manager

This topic is part of "Guidelines for Siebel Application Object Manager Tuning".

In addition to the caches described earlier, this topic discusses major memory consumers in Siebel Application Object Manager components. For more information about some of these topics, see Chapter 12, "Tuning Customer Configurations for Performance."

Note: Specific performance and scalability testing is required to determine the size of Siebel Application Object Manager memory required.

• Database client libraries. Database client libraries have their own caches, caching metadata, connections, cursors, and data. Some of these caches can be reduced in size by using Siebel database connection pooling, described in "Configuring Database Connection Pooling for Siebel Application Object Managers".

• Scripts. A script defined on a business component, applet, or business service is loaded into Siebel Application Object Manager memory when the script is first invoked.

  For Siebel eScript, garbage collection is performed according to settings that are optimized for each release in order to use server memory and other resources appropriately.

• Heavy configurations. Performance is affected when an application is heavily configured, because the memory for the Siebel Application Object Manager increases proportionally in this case.

• Session timeouts. Higher session timeout values mean more active sessions on the server at a time, therefore more memory being used. Lower session timeout values can mean more frequent logins.

• Navigation pattern. Numerous scenarios that can be used to navigate in the application can make using global caches ineffective.

• Users per Siebel Application Object Manager. More users per Siebel Application Object Manager means more sharing of global resources between the users. While the amount of memory used per user on this Siebel Application Object Manager is less, more memory is used overall.

• Number of applets on views. More applets configured on views means more business components will be needed at a time, hence higher overall memory usage.

• PDQ size. The list of items in the PDQ (predefined queries) list are maintained on the server for the current business object. The higher the number of items in this list, the more memory it consumes. The size of PDQ strings also determines memory usage.