| Siebel CRM Performance Tuning Guide Siebel Innovation Pack 2015, Rev. A E54321_01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Performance Tuning Guide Siebel Innovation Pack 2015, Rev. A E54321_01 |
|
Previous |
Next |
View PDF |
This chapter describes the structure and operation of Siebel Application Object Manager components and the tuning that might be required for optimal operation. It contains the following topics:
"Performance Factors for Siebel Application Object Manager Deployments"
"Topology Considerations for Siebel Application Object Manager Deployments"
"Configuring Database Connection Pooling for Siebel Application Object Managers"
"Using Thread Pooling for Siebel Application Object Managers"
For more information about the Siebel Server and Siebel Application Object Manager infrastructure, and about the Siebel Web Client, see the following documents on the Siebel Bookshelf:
Siebel Deployment Planning Guide
Siebel System Administration Guide
Siebel Installation Guide for the operating system you are using
The term Siebel Application Object Manager refers to any of several Siebel Server components that support users accessing Siebel applications through the Siebel Web Client and a Web server.
A different Siebel Application Object Manager component is provided for each base application among the Siebel Business Applications or Siebel Industry Applications. For example:
Call Center Object Manager (SSCObjMgr_enu) is the Siebel Application Object Manager for Siebel Call Center in a U.S. English environment.
Sales Object Manager (SSEObjMgr_enu) is the Siebel Application Object Manager for Siebel Sales in a U.S. English environment.
eService Object Manager (eServiceObjMgr_enu) is the Siebel Application Object Manager for Siebel eService in a U.S. English environment.
|
Note: Separate Siebel Application Object Managers are provided for each installed language in which you can run your Siebel applications. For example, Call Center Object Manager for French is SCCObjMgr_fra. |
When configured appropriately, Siebel Application Object Manager components on your Siebel Servers can use memory and CPU resources efficiently, and can communicate efficiently with the Siebel database, the Siebel Web Server Extension (SWSE), and other components in the Siebel Enterprise.
The multiprocess, multithreaded model for Siebel Application Object Manager components provides scalability to support deployments with a wide range of concurrent Siebel application users.
The overall performance of the Siebel Application Object Manager contributes significantly to the response time as experienced by your end users.
A Siebel Application Object Manager component is implemented as a multithreaded process on the Siebel Server. At runtime, a parent process starts one or more multithreaded processes, according to the Siebel Application Object Manager configuration.
Each Siebel Application Object Manager process can host multiple user sessions (as tasks), which in turn are implemented as threads within the process. These threads might be dedicated to particular user sessions, or they might serve as a pool that can be shared by multiple user sessions. (For each process, a few threads also start that are dedicated to performing core functions for the process.)
As more users log into the system, additional processes can be instantiated to host these users.
In this chapter, the term thread is often used interchangeably with task, except when you are using thread pooling. For details, see "Using Thread Pooling for Siebel Application Object Managers".
The terms multithreaded server or MT server are alternative terms for multithreaded process (a process that supports multiple threads). For example, the names of the Siebel Application Object Manager parameters MaxMTServers and MinMTServers refer to multithreaded processes.
Siebel Application Object Manager components, which run in interactive mode, handle processing for Siebel Web Client sessions, in which the application user interface (UI) resides. The Siebel Application Object Manager task manages Siebel business objects and data objects and performs business logic for the client session.
Generally, each Siebel Application Object Manager task starts in response to a request from a Siebel Web Client running in a Web browser, and ends when the client disconnects.
Each Siebel Application Object Manager task uses Siebel Server infrastructure capabilities to communicate with the Siebel database, the Web server (through the SWSE), and other Siebel Enterprise Server components.
The following are the major types of communication that the Siebel Application Object Manager has with other modules:
Communication with the Siebel database uses database connections. Database connections can also be managed and tuned for optimal performance. You can optionally configure connection pooling for database connections.
For information about configuring database connection pooling, see "Configuring Database Connection Pooling for Siebel Application Object Managers".
Communication between the Siebel Connection Broker (SCBroker) and the Siebel Application Object Manager processes on the same Siebel Server uses mechanisms internal to the operating system. SCBroker receives each Siebel Internet Session Network Application Programming Interface (SISNAPI) connection request from the SWSE and forwards the connection request to a Siebel Application Object Manager multithreaded process. Once the request has been forwarded, subsequent requests for the same user session flow directly from SWSE to this Siebel Application Object Manager process. The request is forwarded using either a least-loaded or a round-robin algorithm, according to the setting of the SCBroker parameter ConnForwardAlgorithm.
For information about configuring SCBroker, see Siebel Deployment Planning Guide and Siebel System Administration Guide. See also the Siebel Installation Guide for the operating system you are using.
Communication with the SWSE uses SISNAPI, a messaging format that runs on top of the TCP/IP protocol. SISNAPI connections can be configured to use encryption and authentication based on Transport Layer Security (TLS). For information about tuning SISNAPI communications, see "Configuring SISNAPI Connection Pooling for Siebel Application Object Managers".
Communication with other Siebel Enterprise Server components (including other Siebel Servers) also uses SISNAPI, going through Server Request Broker (SRBroker). For information about tuning SRBroker, see "Tuning Server Request Broker (SRBroker)".
Tuning activities directly or indirectly applicable to Siebel Application Object Manager components might involve any or all of the following:
Configuring your system initially using Siebel Configuration Wizards. These wizards are described in the Siebel Installation Guide for the operating system you are using.
Using the Siebel Server Manager (GUI or command-line version) to tune parameters for the Enterprise Server, the Siebel Server, or the Siebel Application Object Manager component. These parameters are stored in the siebns.dat file in a directory on the Siebel Gateway Name Server.
Selectively enabling component groups and components on each Siebel Server. Only enable the component groups and components that you need.
Tuning parameters in the eapps.cfg file on the Siebel Web Server Extension. This file is located in the bin subdirectory of the SWSE installation directory, on the Web server computer. You configure the SWSE initially using configuration wizards, as described in the Siebel Installation Guide for the operating system you are using.
Some other chapters in this book discuss Siebel Application Object Manager tuning that relates to using other modules, such as Siebel Communications Server or Siebel Configurator.
In planning to deploy Siebel Application Object Managers, or in troubleshooting performance for existing Siebel Application Object Manager deployments, you must consider several factors that determine or influence performance.
Factors that are central to the task of configuring the Siebel Application Object Manager are also called performance drivers. Performance drivers for Siebel Application Object Manager 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 topics provide information and guidelines to help you achieve and maintain optimal performance and scalability.
These factors are critical in initially configuring your Siebel Application Object Managers, particularly when specifying values for the component parameters MaxTasks, MaxMTServers, and MinMTServers, which are discussed in "Tuning Siebel Application Object Manager Components for CPU and Memory Utilization".
The number of concurrent users is the total number of user sessions supported at any one time. It also includes sessions supporting anonymous browser users. It is useful to distinguish between concurrently connected users and concurrently active users: both sets of users consume memory, but only active users consume CPU (processor) resources.
For planning and tuning purposes, you must consider concurrent users (and total users) at multiple levels:
The entire deployment (enterprise)
Each Siebel Server
Each Siebel Application Object Manager component on each server
Each multithreaded process for each Siebel Application Object Manager component
The maximum number of concurrent users per Siebel Server (assuming, for example, that a particular Siebel Server computer is dedicated to running Siebel Application Object Manager components) depends 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 Siebel Application Object Manager is limited by the value of the MaxTasks parameter. The effective maximum is also limited by the number of multithreaded processes for this Siebel Application Object Manager and by your hardware resources.
Depending on the average think time and other factors, each multithreaded process (that is, process within the Siebel Application Object Manager) typically supports a maximum of about 100 concurrent users. Configure enough multithreaded processes (using the MaxMTServers parameter) to support the maximum number of concurrent users required for your peak loads.
|
Note: Some complex or specialized Object Manager components support fewer concurrent users. For example, Object Managers for Siebel eCommunications (part of Siebel Industry Applications) and Siebel Configurator typically support about 25 concurrent users. For more information about the Object Manager for Siebel Configurator (Siebel Product Configuration Object Manager), see Chapter 8, "Tuning Siebel Configurator for Performance." |
Think time is the average elapsed time between operations performed by users in a Siebel application. Think time includes the time required by users to conduct customer interactions, enter data into the application, and work in other applications.
The assumed think time has a direct relationship to the number of concurrent tasks that a multithreaded process can support. However, factors such as a high degree of customization or heavy use of scripting will reduce the number of tasks that each process can support.
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 (operations) that are represented by the clicks. Also use the list statistics command in Siebel Server Manager to help you calculate average think time.
Consider the average time between each operation (such as clicking New) and each overall transaction (such as performing all steps for creating a new contact). Mouse clicks do not equate to operations if they do not send a request to the Siebel application infrastructure. Calculate the overall average think time based on all of these factors.
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 Siebel Application Object Manager 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 divided by 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 can support more than 100 concurrent tasks; with shorter think times, fewer tasks. For example, if the think time is 15 seconds between user operations, then about 50 tasks per process could be supported (15 times 3.3 = approximately 50, or 50 divided by 15 = approximately 3.3).
Which Siebel applications and other modules that you are using, how you have configured your Siebel applications, how you have deployed your applications, and other such factors also affect Siebel Application Object Manager performance and how many concurrent users that 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? Employee applications use Siebel Open UI or high interactivity, while some customer applications use Siebel Open UI and some 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 that you do using Siebel Tools? For more information, see Chapter 12, "Tuning Customer Configurations for Performance."
The number of concurrent tasks that you can support varies based on the level of customization or the use of process automation for the application the Siebel Application Object Manager supports. Recommendations in this guide generally assume that operations performed are fairly standard or typical. Depending on your deployment and the modules used, some operations initiated by a single user action can be relatively complex and demand more resources than most other operations.
Will you use specialized functionality such as offered by Siebel Configurator (for product configuration) or Siebel CTI (computer telephony integration for call center agents)? How will you deploy such functionality? What percentage of your user base will use such functionality? These are only examples of such specialized functionality.
Hardware resources for each Siebel Server computer, particularly the CPU (processors) and memory, are a factor in how many concurrent users can be supported for each Siebel Application Object Manager component. For example, a four-processor computer has twice the resources of a two-processor computer and can potentially support twice as many concurrent users. Key hardware resources for Siebel Application Object Manager performance include:
CPU (processors). The number of processor cores in the CPU for the server computer, and the rating of these processors.
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 Siebel Application Object Manager tuning. They do significantly affect performance for the Siebel database and the Siebel File System, which can severely impact the overall user response time.
The total number of processor cores (alternatively, the total number of computers with a given number of processors) that you can devote to supporting Siebel Application Object Manager components will determine the total number of concurrent users.
Your Siebel applications can be deployed using a variety of topologies, or system layouts. Although Siebel Application Object Managers are only a part of the overall deployment, they play a direct and central role in supporting Siebel application users.
You must determine on how many computers you will run Siebel Server, and on how many of these you will run Siebel Application Object Manager components. In some cases, you might choose to run multiple components on the same Siebel Server. Among all of the other considerations, the resources of each computer will determine the number of computers that you require.
|
Note: Siebel Application Object Manager components are typically the major resource consumers for your Siebel Server computers. The tuning considerations discussed in this chapter generally assume that you are not running additional components on a Siebel Application Object Manager computer that will significantly contend for available resources. |
For more information about topology considerations, see Siebel Deployment Planning Guide.
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"
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).
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".
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".
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.
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 browser 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 browser users required, then adjust settings further as necessary.
Use the following formulas for calculating parameter values for your Siebel Application Object Manager components:
MaxTasks = target_number_of_users plus anon_browser_users
MaxMTServers = (target_number_of_users plus anon_browser_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 into 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_browser_users is the number of sessions on the Siebel Application Object Manager that are dedicated to anonymous browser users (threads that support users who do not log in).
For employee applications like Siebel Call Center, anonymous browser users are not supported, so this is not a factor.
For customer applications like Siebel eService, anonymous browser 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". |
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_browser_users, as previously described. Example settings follow for Siebel Call Center and Siebel eService.
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. Your parameter values would be like the following:
MaxTasks = 500 MaxMTServers = 500 divided by 100 = 5 MinMTServers = MaxMTServers = 5
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). 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 ofMaxTasks 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". |
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
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".
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.
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.
EnableCDA. This parameter must be set to FALSE for the Siebel Application Object Manager component.
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.
This topic describes database connection configuration options for Siebel Application Object Managers, particularly database connection pooling. It contains the following information:
"About Database Connections for Siebel Application Object Managers"
"Configuring Pooling for Specialized Database Connections"
|
Note: Each customer must determine whether their RDBMS has a sufficient total number of database connections for their needs. The total number of available connections is subject to limitations deriving from RDBMS and operating system platforms and other factors. Before you configure connection pooling, verify how many database connections are available for use by the Siebel Application Object Manager. RDBMS performance and usage of database connections by non-Siebel components are outside the scope of this guide. In general, if the available memory resources for database connections for Siebel Business Applications are sufficient without your using database connection pooling, then it is recommended not to use this feature. |
This topic is part of "Configuring Database Connection Pooling for Siebel Application Object Managers". It provides an overview of database connections for Siebel Application Object Manager components, including nonpooled connections and pooled connections. Subsequent topics provide guidelines and instructions for configuring different types of database connection pooling.
If you do not pool database connections, then the number of database connections corresponds to the number of Siebel Application Object Manager sessions; that is, database connections are not pooled. No special Siebel Application Object Manager configuration is required for using nonpooled database connections. When no pooling is configured, database connections are closed when the user session terminates.
Nonpooled default database connections. With nonpooled database connections, during session login, a database connection is established, using the user's database credentials. (When an external authentication system is used, such as LDAP, the user's database credentials might not be the same as the user's Siebel credentials.)
This database connection becomes bound to the session, and is the default database connection used for read, write, update, and delete operations.
In this book, such connections are called default database connections. These connections can alternatively be pooled, as described later in this topic.
Nonpooled specialized database connections. If, during a session, specialized functionality is invoked that uses the external transaction management capabilities of the Siebel Application Object Manager, then a second database connection is opened for this specialized use.
This database connection is also bound to the session, and is used for all externally controlled transactions performed by the session. Siebel EAI components are an example of specialized code that does external transaction management.
In this book, such connections are called specialized database connections. These connections can alternatively be pooled, as described later in this topic.
Optionally, you can configure your Siebel Application Object Manager components to support pooling for the same two types of database connections described previously for nonpooled database connections:
Pooled default database connections. These database connections can be pooled to support sharing (multiplexing), persistence, or both features.
Shared connections support multiple user sessions at the same time, by multiplexing (sharing) database operations for multiple SQL statements over the same database connection. Using shared connections can support more users with a given number of connections.
Persistent connections are pooled, but are not necessarily shared. Using persistent connections can enhance performance by avoiding the cost of creating database connections. All shared connections are also persistent connections.
For more information, see "Database Connection Pooling Usage Guidelines" and "Configuring Pooling for Default Database Connections".
Pooled specialized database connections. These database connections are dedicated to a single session at a time, and serve a specialized purpose. Pooling such connections provides persistence, but such connections are never shared. By persistently pooling these connections, you enhance performance by avoiding the cost of creating connections.
|
Note: If you configure pooling for default database connections, but not for specialized database connections, then each specialized database connection is closed when the transaction that required it completes. |
For more information, see "Database Connection Pooling Usage Guidelines" and "Configuring Pooling for Specialized Database Connections".
This topic is part of "Configuring Database Connection Pooling for Siebel Application Object Managers".
Observe the following guidelines to help you determine if you must use database connection pooling, or to guide your deployment of connection pooling.
For more information about configuring the Siebel Application Object Manager parameters for database connection pooling mentioned in this topic, see "Configuring Pooling for Default Database Connections" and "Configuring Pooling for Specialized Database Connections".
Consider implementing database connection pooling if, and only if, one or more of the following is true for your deployment:
The RDBMS cannot support the number of dedicated user connections that you would require if using nonpooled database connections. Pooling default database connections for shared use can reduce the number of connections you require.
Memory resources are scarce on the Siebel Server computer on which the Siebel Application Object Manager is running. Pooling default database connections for shared use can reduce Siebel Application Object Manager memory requirements per concurrent user.
Your deployment uses external authentication such as LDAP (that is, authentication other than database authentication), and creating new connections is slow on the database server. Pooling database connections can speed up login or other operations by providing persistent pooling, whether or not connections are also shared.
You use a Siebel Server component that requires frequent logins for special-purpose processing. Pooling database connections to provide persistent connection pooling (not sharing) can provide a significant benefit for such components.
For Siebel Configurator, if you are using the component Siebel Product Configuration Object Manager (alias eProdCfgObjMgr_jpn in a Japanese locale), then it is highly recommended to configure persistent connection pooling. For more information about Siebel Configurator, see Chapter 8, "Tuning Siebel Configurator for Performance."
|
Note: Separate Application Object Manager components are provided for each installed and deployed language in which you can run your Siebel applications. For example, Call Center Object Manager for French is SCCObjMgr_fra. |
For some other components, such as EAI Object Manager (when run in sessionless mode), it might also be helpful to configure persistent connection pooling.
|
Note: If session caching is configured for a component (by setting the parameterModelCacheMax), then persistent connection pooling might provide little benefit. For example, session caching is typically configured for Workflow Process Manager. For more information about session caching for Siebel Workflow, see "Caching Sessions". |
If you decide to use database connection pooling, then observe the following guidelines:
Start with a low ratio of MaxTasks divided by MaxSharedDbConns, such as 2:1.
|
Note: If you plan to use a ratio higher than 3:1, then it is recommended that you consult Oracle Advanced Customer Services. Contact your Oracle sales representative to request assistance from Oracle Advanced Customer Services. |
If you have short (aggressive) average think times in your user scenarios, then use a smaller ratio of MaxTasks divided by MaxSharedDbConns. Longer think times can support larger ratios.
For a 30-second think time, do not use a ratio higher than 10:1. For a 15-second think time, do not use a ratio higher than 5:1. Other factors discussed in this topic will also determine practical limits. For more information about think time, see "Performance Factors for Siebel Application Object Manager Deployments".
Minimize long-running queries. Long-running queries can affect overall performance and must be minimized or avoided. If the current connection pool is blocked by a long-running query from one user session, then other user sessions will use a different pool. However, a long-running query can continue to run on the RDBMS even if the user who initiated it has stopped the browser.
When you are using database connection pooling, it is critical to optimize database access in your environment. If long-running queries occur, then monitor the overall database response time. To achieve a satisfactory response time, use a small ratio of MaxTasks divided by MaxSharedDbConns.
You can minimize or avoid long-running queries by providing the Cancel Query option for users, by adjusting indexes to include fields that can be sorted or queried by end users, by configuring the application user interface so that nonindexed fields are not exposed, and by training users to avoid operations that would perform long-running queries. For more information about how indexing can affect Siebel application performance, see "Managing Database Indexes in Sorting and Searching". For more information about configuring the Cancel Query option, see Siebel Applications Administration Guide.
Consider the cost of creating database connections. This cost differs based on your authentication method.
If your deployment uses database authentication, a database connection is created for each login, for authentication purposes. Afterwards, this connection is released to the shared connection pool, if the total number of connections is less than the maximum. Or, if the pool is full, then the connection is closed (terminated). Therefore, even when the pool is full and connections are available, new connections are still created temporarily for each new session login. These connections must be accounted for in determining the allocation of database connections.
With external authentication, however, you can use persistent connection pooling to reduce the cost of creating database connections. With persistent connection pooling, database connections, once created, are persistent, though such connections might or might not be shared. For pooled default database connections where connections are persistent but not shared, set MaxSharedDbConns to equal MaxTasks minus 1. For more information about authentication options, see Siebel Security Guide.
In order to configure connection pooling for specialized database connections, you must also configure pooling for default database connections, as follows:
If you do not configure connection pooling for shared database connections (MaxSharedDbConns equals -1 or 0), then each specialized database connection, once created, is dedicated to the user session. The value of MinTrxDbConns is ignored.
If you configure connection pooling for shared database connections (MaxSharedDbConns has a value greater than 0, and less than MaxTasks), then specialized database connections are not dedicated to user sessions. Such connections are handled according to the setting of MinTrxDbConns:
If MinTrxDbConns equals -1 or 0, then, after the transaction that required it has ended, each specialized database connection is closed (deleted).
If MinTrxDbConns has a value greater than 0, then, after the transaction that required it has ended, each specialized database connection can return to the connection pool.
Siebel Business Applications do not support MTS or Oracle multiplexing features.
This topic is part of "Configuring Database Connection Pooling for Siebel Application Object Managers".
Default database connections can be used by most Siebel Application Object Manager operations.
The following information describes how to enable or disable pooling for default database connections using the parameters MaxSharedDbConns (DB Multiplex - Max Number of Shared DB Connections) and MinSharedDbConns (DB Multiplex - Min Number of Shared DB Connections).
To enable connection pooling, set MaxSharedDbConns and MinSharedDbConns to positive integer values (at least 1) that are no higher than MaxTasks minus 1. A connection will be shared by more than one user session once the number of sessions within the multithreaded process exceeds the maximum number of shared connections allowed per process.
MaxSharedDbConns controls the maximum number of pooled database connections for each multithreaded process.
MinSharedDbConns controls the minimum number of pooled database connections that the Siebel Application Object Manager tries to keep available for each multithreaded process.
The setting of MinSharedDbConns must be equal to or less than the setting of MaxSharedDbConns. Depending on your Siebel Application Object Manager usage patterns, set these to the same value or set MinSharedDbConns to a lower value (if you determine this to be helpful in conserving database connection resources).
To configure persistent and shared database connection pooling, set MaxSharedDbConns, using the appropriate ratio of MaxTasks divided by MaxSharedDbConns. Depending on the ratio, a greater or lesser degree of sharing will be in effect. Start with a 2:1 (or smaller) ratio for MaxTasks divided by MaxSharedDbConns. With this example ratio, two user tasks will share the same database connection.
To configure persistent but nonshared database connection pooling, set MaxSharedDbConns = MaxTasks minus 1.
To disable connection pooling, set MaxSharedDbConns and MinSharedDbConns to -1 (this is the default value).
MaxSharedDbConns and MinSharedDbConns are defined per Siebel Application Object Manager component, on an enterprise basis (these parameters are included in named subsystems of type InfraDatasources). The database connections these parameters control are not shared across multithreaded processes. The actual maximum number of database connections for each multithreaded process is determined by the ratio MaxSharedDbConns divided by MaxMTServers.
|
Note: MaxSharedDbConns and MinSharedDbConns work differently than MinTrxDbConns, which specifies the number of shared specialized database connections available for each multithreaded process. For details, see "Configuring Pooling for Specialized Database Connections". |
Assume, for example, the following parameter settings:
MaxTasks = 500 MaxMTServers = 5 MinMTServers = 5 MaxSharedDbConns = 250 MinSharedDbConns = 250
With these settings, the Siebel Application Object Manager component can support a maximum of 500 tasks (threads). Those 500 tasks would be spread over five multithreaded processes, each having 100 tasks. Each multithreaded process would have a maximum of 50 shared database connections, each of which would serve up to two tasks.
When a user logs into the Siebel Application Object Manager, a database connection is established to authenticate the user, then discarded (closed) once the database or external authentication system authenticates the user. After successful authentication, the Siebel Application Object Manager's connection manager checks the connection pool for SQL statements. If this connection pool is empty, then the connection manager adds a connection.
Each time a user initializes an SQL statement, the connection manager checks the connection pool for available connections. The connection manager reserves a connection for the SQL statement in one of the following ways:
If a connection is available to handle the SQL statement, the connection manager assigns this connection to execute the SQL statement.
The connection manager reserves this connection until execution of the SQL statement terminates. On termination of the SQL statement, the connection manager releases the connection. At the end of a user session (due to a user logging out or a session timeout), the connection manager checks the connection used by the user session. If this connection is not referenced by other user sessions and the number of connections available in the pool of database connections exceeds the value specified by MinSharedDbConns, the connection manager closes this connection and releases it from the pool of database connections.
If no connection is available in the connection pool, then the connection manager creates a new connection and assigns it to execute the SQL statement.
The connection manager continues to add connections to the connection pool until the number of connections in the connection pool equals MaxSharedDBConns.
This topic is part of "Configuring Database Connection Pooling for Siebel Application Object Managers".
Specialized database connections, which are not shared, are used primarily by specialized Siebel components such as Siebel EAI that need transactions to span multiple Siebel Application Object Manager operations. These connections are used for operations that use BEGIN TRANSACTION and END TRANSACTION.
The following information describes how to enable or disable specialized connection pooling using the parameter MinTrxDbConns (DB Multiplex - Min Number of Dedicated DB Connections).
MinTrxDbConns controls the minimum number of specialized database connections for each multithreaded process. The connections are not created until they are needed. The minimum value is thus the minimum size of the pool of specialized connections once all of the connections in the pool have been created.
To enable specialized connection pooling, set MinTrxDbConns to a positive integer value (at least 1). You must also configure pooling for default database connections.
To disable specialized connection pooling, set MinTrxDbConns to minus 1 (this is the default value).
There is no explicit limit to the maximum number of specialized connections. However, effectively, there cannot be more specialized connections than sessions. On average, there will be many fewer connections than sessions.
MinTrxDbConns is defined per Siebel Application Object Manager component, on an enterprise basis (this parameter is included in named subsystems of type InfraDatasources). The database connections that this parameter controls are not shared across multithreaded processes. The actual minimum number of specialized database connections for each multithreaded process is what you specify as the value for MinTrxDbConns.
|
Note: MinTrxDbConns works differently than MaxSharedDbConns and MinSharedDbConns. MaxSharedDbConns and MinSharedDbConns specify the number of shared database connections available for all Siebel Application Object Manager processes, while MinTrxDbConns specifies the number of specialized database connections per Siebel Application Object Manager process. For more information, see "Configuring Pooling for Default Database Connections". |
Assume, for example, the following parameter setting, in addition to those described in "Example Configuration for Pooling Default Connections":
MinTrxDbConns = 5
With this setting, each multithreaded process would have a minimum of five specialized database connections. If all five multithreaded processes are running on this Siebel Application Object Manager, then there would be a minimum of 25 specialized connections for this Siebel Application Object Manager.
When the Siebel Application Object Manager starts up, the specialized connection pool is empty. When a request is made to start a transaction, the Siebel Application Object Manager requests a database connection from the specialized connection pool. If one is available, then it is removed from the pool and given to the session for that session's exclusive use.
When the transaction completes (such as by being committed or canceled), the session returns the specialized connection to the pool. If the pool already contains more than the number of connections specified by MinTrxDbConns, then the specialized connection is closed; otherwise, it is retained in the pool.
Assume, for example, that MinTrxDbConns is set to 2. Specialized connections will be handled as follows:
User 1 starts Transaction 1. The specialized connection pool is empty, so a new connection is created. Once Transaction 1 completes, this connection is returned to the pool.
User 2 starts Transaction 2. If Transaction 1 is still running, then a new specialized connection is created. If Transaction 1 completed, then Transaction 2 uses the first database connection.
When two specialized connections have been created, they will remain in the pool until the Siebel Application Object Manager terminates.
Optionally, you can configure your Siebel Application Object Manager components to use thread pooling. Enabling Siebel Application Object Manager thread pooling as described in this topic both pools and multiplexes (shares) multiple tasks across threads.
Using Siebel Application Object Manager thread pooling can improve performance and scalability on multiple-processor computers that are under heavy load; for example, computers using eight or more processors that are running at more than 75% capacity.
|
Note: Siebel Application Object Manager thread pooling is not recommended for smaller server computers or for computers that run under a relatively lower capacity. |
The pool size per multithreaded process for a Siebel Application Object Manager is determined by the combined settings of the parameters UseThreadPool, ThreadAffinity, MinPoolThreads, and MaxPoolThreads.
Siebel Application Object Manager thread pooling reduces some of the system resource usage devoted to creating and closing session threads, as users log in and log out or are timed out. As when you are not using thread pooling, session threads are created as needed as session requests demand. However, instead of being closed when a session terminates, they are released to a pool, where they become available for use by a subsequent session.
When ThreadAffinity is FALSE (the default), threads are multiplexed, as can be done with certain types of database connections or SISNAPI connections. At any given time, each thread can be dedicated to one or more user session (task).
|
Note: Using thread pooling introduces its own overhead, such as in task context-switching. For this reason, it is strongly recommended not to try to pool threads without also multiplexing them. That is, do not set bothUseThreadPool and ThreadAffinity to TRUE. |
To use thread pooling, you set the following parameters on the Siebel Application Object Manager:
UseThreadPool equals TRUE (default is FALSE)
ThreadAffinity equals FALSE (default is FALSE)
MinPoolThreads equals min_number_threads_in_pool (default is 0), where min_number_threads_in_pool represents the minimum number of threads in the Siebel Application Object Manager thread pool.
MaxPoolThreads equals MinPoolThreads (default is 0)
|
Note: You must specify a value forMaxPoolThreads that is equal to or greater than the value of MinPoolThreads. |
To determine an appropriate value for MinPoolThreads and MaxPoolThreads, start slowly, monitor system performance, then introduce more multiplexing, as appropriate for your deployment. For example, start with a formula like this (based on two tasks per thread):
MinPoolThreads = MaxPoolThreads = (MaxTasks/MaxMTServers) divided by 2
Subsequently, you can increase this to five tasks per thread, using this formula:
MinPoolThreads = MaxPoolThreads = (MaxTasks/MaxMTServers) divided by 5
For example, if MaxTasks equals 525, and MaxMTServers equals 5, this would be:
MinPoolThreads = MaxPoolThreads = (525 divided by 5) divided by 5 = 105 divided by 5 = 21
Or, if MaxTasks equals 725, and MaxMTServers equals 5, this would be:
MinPoolThreads = MaxPoolThreads = (725 divided by 5) divided by 5 = 145 divided by 5 = 29
|
Note: Adjust values for think time, as necessary. If you cut your think time value in half, then double the number of threads in the pool. |
