Page 1 sur 8

How to Configure Siebel Object Manager (AOM / SOM) in Siebel 7.x and 8.0 [ID 476830.1] Modified 18-AUG-2009 Type BULLETIN Status PUBLISHED

In this Document Purpose Scope and Application How to Configure Siebel Object Manager (AOM / SOM) in Siebel 7.x and 8.0 Max Tasks Max MT Servers and Min MT Servers Number of Sessions per SISNAPI Connection Session Timeout and Anonymous User Pool SISNAPI Connection Maximum Idle Time Siebel Database Connection Pooling or Database Multiplexing Best Practices

Applies to:
Siebel System Software - Version: 7.0.4 [14068] - Release: V7 Information in this document applies to any platform. Area(s):System Administration Release(s):V7 (Enterprise), V7 (Professional), V7 (MidMarket) Database(s):All Supported Databases App Server OS(s):All Supported Platforms Latest release tested against:V8 (Enterprise) Keywords:Object Manager, SOM, Tuning, MaxTasks, MinMTServer, MaxMTServer, performance This document was previously published as Siebel Technical Note 388.

Purpose
This technical note describes the structure and operation of the Siebel Object Manager and describes the most important tuning parameters and guidelines for setting them. The information provided here should be considered general background information. Many variables will affect the tuning of the Siebel eBusiness Application. This document is not a substitute for specific tuning recommendations made by Siebel Expert or Professional Services.

Scope and Application

This document is informational and intended for any user.

How to Configure Siebel Object Manager (AOM / SOM) in Siebel 7.x and 8.0
The Siebel Object Manager (SOM or Siebel OM) is a Siebel server component that is used primarily to execute sessions for several different types of Siebel clients: Version 6.x Windows, Java, and HTML Thin Clients Version 7.x and Version 8.x Web Clients These different clients are all built using a common architecture: a remotely-executed user interface (UI) connects to a session running in the Object Manager (OM), which runs the Siebel objects and business logic and interacts with the database and other Enterprise Server components on their behalf. The Siebel Object Manager is a multithreaded process, which means that one running process can execute multiple, concurrent threads. When an Object Manager is started on a Siebel server, an OM task will

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=476830.1

01/04/2010

Page 2 sur 8

automatically be started (with status 'Handling Requests'). When users start to log in, each user login will spawn a new task. These user tasks will remain active until the user logs out. All these tasks will be counted towards the value of the MaxTasks parameter. Multiple OM processes can be run on each Siebel Server. This multiprocessing and multithreaded programming model provides Siebel software with a very high degree of scalability, as users are constrained only by application server resources in the numbers of processes and threads that can be run to support very high numbers of concurrent users. Processes and threads are programming terms for things running at the operating system level. At the Siebel Server level, more user-friendly terms are used to express the same concepts. The term Multithreaded Server, or MT Server, refers to an OM process, and the term Server Task refers to a user session being executed by a thread of that process. As with any high performance system, proper tuning is required to assure optimal operation. The goal is to tune the SOM to efficiently use the database connections, memory, and CPU time while not succumbing to high levels of context switching. There are many parameters to consider when tuning a Siebel OM. Siebel Expert Services provides a Production Readiness review, to make sure that the Siebel application has been tuned correctly. The following case study will provide concepts and examples to educate the Siebel Administrator in tuning their Siebel eBusiness Application. The first step to consider is the projected number of concurrent users for the Siebel application. In this case study, there are 1000 concurrent users, assuming an average think time of 30 seconds between user operations. The think time is the idle time when the server or the client is not doing anything; it does not include query time. During the think time, the user may be conversing on the telephone, working in another application (such as email) or doing some other task. Using the Server Manager command line utility, srvrmgr, the Siebel Administrator can run the "list statistics" command to calculate the "Average Think Time" for a process. This information is used to calculate the first set of parameters. 1. MaxTasks = concurrent users + anonymous user pool [1000+100] 2. MaxMTServers = MaxTasks / 100 [1100/100 = 11] 3. Number of Sessions per SISNAPI Connection = 20 Observations: For environments where there is lack of machine resource, such as lack of memory, it is recommended a lower MaxTasks / MaxMTServer ratio. It is necessary to make tests to tune it and find a proper value. But the ratio in these scenarios can go from around 25 to 75. For Object Managers that use Product Configurator, the recommended MaxTasks / MaxMTServer ratio is 25. The same 25 ratio is recommended for eCommunications Object Manager.

Max Tasks

Maximum number of tasks represents the maximum number of concurrent user sessions that can run on a server at one time. An MT Server is equivalent to a single process of an Object Manager. Each MT Server is implemented as an operating system process; it has its own memory space and processor identifier (PID). The default value is 20. NOTE: For Siebel Servers running on the Solaris platform: When using the Oracle 8i client, setting a high ratio of tasks per OM process may cause the object manager to end unexpectedly. For additional information and workarounds for this behavior, review "Alert 881: Intermittent "Login Failed" Error Running Siebel Server on Solaris with Oracle 8i Database"

Max MT Servers and Min MT Servers

Maximum MT Servers is the maximum number of MT Servers that can be run for this component on this server. It is also used to calculate how many tasks can be run on each MT Server. Minimum MT Servers determines how many MT Servers start initially when the Siebel Server starts. It also determines the minimum number of MT Servers to run on a Siebel Server, in the event many users log out. The loading of a new MT

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=476830.1

01/04/2010

Page 3 sur 8

Server into memory is CPU-intensive, and users may experience a short delay in logging into the Siebel application. In order to prevent this delay, Siebel Administrators may set the Minimum MT Servers parameter equal to the Maximum MT Servers parameter. However, some Siebel Administrators may configure Minimum MT Servers to be lower than the Maximum MT Servers to tune the Siebel application for the normal usage load, while allowing the potential for spikes in user load. Siebel Systems generally recommends that customers set the Minimum MT Servers parameter equal to the Maximum MT Servers parameter for most deployments. The ratio MaxTasks / MaxMTServers is equal to the Max Number of Tasks running in one instance of a MT Server. When the number of running tasks exceeds the number of tasks that can be supported by the running MT Servers, a new MT Server will be started. Siebel Systems recommends administrators to begin tuning with a ratio of 100:1, assuming an average 30 second think time. If the average user think time is 15 seconds, then the ratio is 50:1 (50% of 100:1). If the average user think time is 60 seconds, then the ratio is 200:1 (200% of 100:1). This will give Siebel Administrators an initial benchmark of performance. Customizations and usage of the Siebel application will dictate whether to increase or decrease these ratios. Incorrectly configured Maximum Tasks and Maximum MT Servers parameters could result in the following behaviors: 1. Users intermittently receive the following message when launching the application: The server you are accessing is either busy or experiencing difficulties. Please close the web browser, start a new one and try logging in again. For further support, please copy and send the full message text to your system administrator.[09:30:19] 2. The following message in the SWSE log files: GenericLog GenericError 1 2003-12-01 09:16:24 (ssmsismgr.cpp 83(276) err=5600029 sys=0) SBL-SSM-00029: Failed to create session, server could be busy. GenericLog GenericLog 0 2003-12-01 09:16:24 [2024] ERROR 2024: [SWSE] Login failed. SBL-SMI-00101: The server is busy, please try again later. 3. The following message in the Object Manager log files: GenericLog GenericError 1 2003-12-01 09:03:41 (smimtpool.cpp 50(895) err=2100114 sys=0) SBL-SMI-00114: The Multithreaded Server has reached the maximum number of concurrent tasks ((null)) GenericLog GenericError 1 2003-12-01 09:03:41 (smimtpool.cpp 50(1960) err=2100101 sys=0) SBL-SMI-00101: The server is busy, please try again later.

Number of Sessions per SISNAPI Connection

SISNAPI (Siebel Internet Session application programming interface) connection (connections between the Siebel Web Server Extension (SWSE) and the SOM multiplexing) can be done by setting the parameter "Number of Sessions per SISNAPI Connection"; the recommended value is 20. This parameter specifies the number of Sessions that can share one SISNAPI Connection between the web server and the application server. This helps to reduce the number of open network connections. Note that while 20 is a good value to use for user sessions, it does not apply to incoming HTTP requests from other systems (for example, EAI HTTP Adaptor Access). In Siebel version 7.0.x, there is an extra consideration regarding the Number of Sessions Per SISNAPI Connection parameter setting. For Siebel version 7.0.x, Siebel Systems recommends that the ratio between the MaxTasks / MaxMTServers and SessPerSISNAPIConn come to an integer in the final setting. For example, if MaxTasks / MaxMTServers = 100 and SessPerSISNAPIConn = 20, then this ratio is 5 (100/20), which is an integer. If the MaxTasks / MaxMTServers = 30, then Siebel Systems recommends to lower the value of the parameter SessPerSISNAPIConn to 15 so the ratio (30/15) is 2 rather than 1.5 (30/20). Siebel Systems generally recommends decreasing the SessPerSISNAPIConn from its default value of 20 rather than increasing the value of this parameter. NOTE: For Siebel version 7.0.x, if you are seeing OM reaching MaxTasks errors (error # 3 above), then Siebel Systems also recommends to set the ratio between the MaxTasks / MaxMTServers and SessPerSISNAPIConn to a value of 2 or greater. For example, if MaxTasks / MaxMTServers = 20, then

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=476830.1

01/04/2010

Page 4 sur 8

decrease the SessPerSISNAPIConn to 10. This will reduce the likelihood of a particular OM process reaching the maximum capacity when many users log into the Siebel application in quick succession. NOTE: Siebel version 7.5.3 onwards every new Web client user who logs in, creates a SISNAPI connection between the Web server and the Siebel server. After this if the there are enough existing open SISNAPI connections between the web server and that particular Siebel server the new connection will be closed and the old ones will be used. This logic was introduced because in previous versions once the SISNAPI connections would time out or get shut down the Web Server would have lesser Connections available to multiplex the user sessions from the Web server to the Siebel Servers.

Session Timeout and Anonymous User Pool

"Session timeout" and "AnonUserPool" are parameters that are defined in the eApps.cfg file. Session timeout parameter is the time, in seconds, from the user's last browser request until the user's connection times out. The default is 900 seconds. Adjust this parameter to automatically terminate a session after duration of inactivity. The AnonUserPool parameter determines the number of anonymous users available to retrieve the login page or error pages. They are not used for the browse feature, which uses a different kind of anonymous user. Siebel Systems recommends setting the AnonUserPool to 10-15% of Maximum Tasks. In this case, the setting would be 100 (1000*10%). For recent Siebel versions, AnonUserPool parameter will no longer appear in configuration file. It will be limited by MaxTasks value of the Object Manager.

SISNAPI Connection Maximum Idle Time

This parameter configures connection timeout between the Web server and the Siebel Server. Below are the scenarios when you might want to change the default value for this parameter: If you are using a load balancer with the Siebel Servers for example, in Siebel versions 7.5.x and below, the load balancer available is Resonate. If there is a firewall placed between the Web server and the Siebel Servers. Valid values are numeric, specifying the period of idle time (in seconds) after which the connection is disconnected by the component in this case, the Object Manager. This parameter should only be set at the component level, and only for application object managers and EAI object managers. It should never be set for batch mode or background mode components, nor should it be set for SRBroker or any other infrastructure related component. Therefore, it should never be set at the enterprise level. As mentioned above, this setting should only be used when a load balancer is in use for Siebel Servers configured to time out SISNAPI connections. By default, most load balancers have an idle connection timeout feature. The parameter ConnIdleTime must be set to a value slightly less than the load balancer timeout. For example, if the Application Object Manager ConnIdleTime is set to 600, set the load balancer connection timeout to 601 seconds or higher. An additional benefit of the ConnIdleTime parameter is to manage connections that pass through a firewall placed between the Web server and the Siebel Server. As firewalls block idle connections, the ConnIdleTime parameter can be configured to disconnect idle connections before they are blocked by the firewall. This setting avoids future connection problems between the Web server and the Siebel Server. The table below shows the default value and recommended value for this parameter per each Siebel version: Siebel Version 7.5.2.x 7.5.3.x 7.7.x 8.0.x Default Value 0 -1 -1 -1 Recommended Value 300 3600 300 3600 > 30 > 30

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=476830.1

01/04/2010

Page 5 sur 8

Siebel Database Connection Pooling or Database Multiplexing

Siebel eBusiness Applications offers Database Connection Pooling or Database Multiplexing. Siebel Administrators with a large number of users can lower resource utilization on their database server by limiting users to a database connection pool. Siebel Systems generally recommends that customers with fewer than 1,000 users forgo the use of this product feature. Enabling database connection pooling can improve scalability by reducing the number of inactive connections and reducing the overhead of database logins. Siebel Administrators are recommended to start with a 2:1 ratio for MaxTasks / MaxSharedDBConns. In other words, 2 user tasks will share the same database connection. Administrators should test the application thoroughly until they find the balance between conserving resource utilization on the application server and avoiding database bottlenecks. It is advised that customers consult with Siebel Expert Services if they plan on using a ratio higher than 3:1. The three parameters that control Siebel Database Connection Pooling and Multiplexing are described below: Min Number of Dedicated database (DB) Connections (alias is MinTrxDbConns) Min Number of Shared DB Connections (alias is MinSharedDbConns) Max Number of Shared DB Connections (alias is MaxSharedDbConns) NOTE: Oracle Net8 (MTS or Multiplexing) cannot be used simultaneously with Siebel 7 DB Connection Pooling / Multiplexing. Setting the above parameters to -1 will disable DB Connection Pooling and Multiplexing. When DB Connection Pooling and Multiplexing are disabled, each user creates a database connection at session creation and releases it at session termination. Siebel OM keeps two sets of DB connections. One set is for simple operations that are shared, and the other is for complex transactional-type operations that are dedicated for the duration of the transaction. This is done to optimize DB access performance by isolating different access paths. This also reduces the expensive overhead of maintaining a DB connection. Dedicated Database Connections Pool These connections are used primarily by specialized Siebel components, such as eBusiness Application Integration (EAI), which need transactions to span multiple Object Manager operations. Typical Siebel Web Client user sessions do not use these connections. The component parameter, MinTrxDbConns, controls the minimum number of dedicated connections within an Object Manager MT Server. There is no explicit limit to the number of dedicated connections, but effectively there cannot be more dedicated connections than sessions. On average, there will be many fewer connections than sessions. When the Object Manager starts, the database connection pools are empty. When a request is made to start a transaction, the Object Manager requests a database connection from the dedicated connection pool. If one is available, it is removed from the pool and given to the session for its exclusive use. When the transaction completes, the session retains the dedicated connection. When the session terminates, the dedicated connection is returned back into the pool, if the pool contains fewer than the MinTrxDbConns. Otherwise, the dedicated connection is closed. For example: MinTrxDbConns = 2 1. User 1 starts a transaction Since the dedicated connection pool is empty, connection 1 is created using User 1's credentials and held by user 1's session. 2. User 2 starts a transaction Again the pool is empty, so connection 2 is created with user 2's credentials. 3. User 1 commits the transaction and terminates the session Since the pool has fewer than 2 dedicated connections, the connection is submitted to the pool.

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=476830.1

01/04/2010

Page 6 sur 8

4. User 3 starts a transaction Connection 1 is taken off the pool for user 3's session. 5. User 4 starts a transaction The pool is again empty, so connection 4 is created with user 3's credentials. 6. User 2 ends the transaction and terminates the session Connection 2 is inserted into the pool. 7. User 4 ends the transaction and terminates the session Connection 4 is inserted into the pool. 8. User 3 ends the transaction and terminates the session Connection 1 is closed because the pool already contains 2 dedicated connections. As illustrated in the example above, new dedicated connections are created on demand, when needed. The dedicated connections are held until the end of the session or server task, at which time they are either placed in the dedicated connection pool or released. Any connections in the pool at the time the MT Server shuts down are released. Shared Database Connections Pool These connections are used by most Object Manager operations. These connections will be shared by more than one Object Manager session (or user) once the number of sessions within the Object Manager process exceeds the max shared connections allowed per process (see below). NOTE: A long-running query on a shared database connection may block other users sharing that database connection. For more information about this topic, refer to the Siebel Bookshelf version 7.5.3 > Performance Tuning Guide > Tuning the Siebel Application Object Manager for Performance > Best Practices for AOM Tuning > Configuring Shared Database Connection Pooling. The component parameter MinSharedDbConns controls the number of shared database connections the Object Manager will try to keep available. The component parameter MaxSharedDbConns controls the maximum number of shared database connections. Unlike the MinTrxDbConns parameter, which is per MT Server, the MinSharedDbConns and the MaxSharedDbConns parameters are defined per component. In other words, MaxSharedDbConns controls the maximum total number of database connections for the component, on a particular Siebel Server. Consider the following settings: MaxTasks = 400 MaxMTServers = 20 MinSharedDbConns = 40 MaxSharedDbConns = 100 MinTrxDbConns = 2 With these settings, the component can support a maximum of 400 sessions or server tasks. Those 400 sessions would be spread over 20 MT Servers, each having 20 sessions, and using a total of 100 database connections. In this scenario, with 400 sessions active, each shared database connection would service 4 sessions. Since the MinTrxDbConns setting would be per MT Server, there would be, at most, 40 unused dedicated connections (2 in the dedicated pool of each MT Server). As with the dedicated connections, when the Object Manager starts up, the shared connection pool is empty. When a session logs into the Object Manager, the shared pool is checked to see if a connection is available. The following points highlight the selection algorithm. 1. If an unshared connection is available, assign it to the session. Note that it is not removed from the pool. 2. If the number of connections in the pool is less than MaxSharedDbConns, create a new connection, insert it into the pool, and assign it to the session. 3. Select the current connection in the pool that is shared by the fewest sessions and assign it to the session. Once the shared connection is assigned to the session, all database operations, other than the specialized operations that would use a dedicated connection, go through the shared connection. When the session terminates, the usage count for the connection is decremented. If the usage count has reached 0 (that is, no

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=476830.1

01/04/2010

Page 7 sur 8

sessions are using this connection), and there are at least MinSharedDbConns connections with a usage count of 0 already in the pool, the connection is removed from the pool and closed. Otherwise, it is left in the pool. The following example may help illustrate this scenario: MinSharedDbConns = 2 MaxSharedDbConns = 5 MaxTasks = 20 MaxMTServers = 1 1. Users 1-5 login Shared connections 1-5 are created and added to the pool. All connections have a usage count of 1. 2. Users 6-10 login Shared connections 1-5 are assigned in turn to the new sessions. All connections have a usage count of 2. 3. User 2 issues a query Multiplexed connection 2 is used for the request 4. User 3 issues a query Multiplexed connection 3 is used for the request 5. Etc. ... 6. Users 2, 3, 9 and 10 logoff Since none of the users are sharing the same connection, connections 2, 3, 4 and 5 have their usage count decremented. All the connections remain in the pool. 7. User 8 logs off Connection 3's usage count is decremented to 0. Since it is the only unused connection in the pool, it remains in the pool. 8. User 4 logs off Connection 4's usage count is decremented to 0. Since it is the 2nd unused connection in the pool, it also remains. 9. User 7 logs off Connection 2's usage count is decremented to 0. Since there are already MinSharedDbConns unused connections in the pool, the connection is removed from the pool and closed. 10. Users 11 and 12 login Connections 3 and 4 are assigned to the new sessions. 11. User 13 logs in Connection 6 is created and added to the pool since there were less than MaxSharedDbConns in the pool. When the MT Server shuts down, any remaining connections in the pool are closed. NOTE: Min Number of Dedicated DB Connections is per MT Server, while the other two (Min Number of Shared DB Connections and Max Number of Shared DB Connections) are per server component. Setting all three parameters to the same value will result in a high number of dedicated connections maintained.

Best Practices

1. Set all the above parameters as recommended. 2. Set "EnableViewCache = TRUE" in the *.cfg file for High Interactive mode clients on the Siebel Server. This will impact faster client response times and better network behavior. It uses the Least Recently Used (LRU) mechanism to flush out the cache. 3. Set "EnableCDA = FALSE" in the *.cfg file of the Siebel Server if users are not using eConfigurator. 4. Set "Timed Statistics" = Off. 5. Set all Event Log Levels to 1. 6. Configure components so that machines run at 65% to 80% capacity, if server consistently runs at

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=476830.1

01/04/2010

Page 8 sur 8

above 80% CPU utilization, or amount of paging is excess, then the number of MaxTasks and MT Servers should be reduced accordingly. 7. Disable all unnecessary component groups to reduce system resources. 8. Depending on the High availability requirement, sizing may have to account for fail over scenario, in other words when one server goes down and the other servers pick up the load. 9. Test a single MT Server process to gauge how much memory it will use. Then calculate the number of MT Servers that can run on each machine. See example below. Siebel Systems recommends becoming familiar with the siebmtshmw.exe process and understanding how it will run under loaded conditions. The easiest way to do this is to run tests on a small scale, for example, MaxTasks = 100 and MaxMTServers = 1. This will provide meaningful data on the behavior of a single siebmtshmw.exe process, such as the amount of memory used, CPU utilization, etc. Once this data is known, accurate parameter values can be extrapolated. For an example, see the scenario below. Company ABC wants to roll out eChannel to their 10,000 customers. They anticipate that at any one time, 1,000 concurrent users will be logged in and using the system. Before testing 1,000 concurrent users, it is important to know how a single process will behave. This process can probably handle 70-80 concurrent users, depending on think time and what they are doing in the Siebel application. Whenever possible, use real end users for this smaller test to get a more realistic simulation. Run the test for 45 minutes to several hours so that there is a fair amount of turnover of tasks. Assume that the data returned from this test shows that this one process used, on average, 150MB of RAM and about 10% of the CPU. If the Siebel server machine has 2GB of memory and 2 CPU's, then approximately 10 MT Servers can be running on this machine at the same time. 2GB of RAM 500MB for the O/S leaves 1500MB for the Siebel processes. 1500MB / 150MB = 10. If this small test reveals that the process used 200MB, then the number of MT Servers that can run on this machine is reduced to about 7. A larger machine can run more processes. A machine with 4GB and 4 CPU's can run 17 MT Servers. 4GB 500MB = 3500MB. 3500MB / 200 = 17.5. It is much easier to exercise one process to find out how it performs than to run a large-scale test to determine the same thing. Each process that runs as part of an Object Manager essentially runs the same way, so once it is determined how one process will behave; the rest can be calculated to determine the number of tasks and number of MT Servers that a machine can support. In conclusion, an evaluation of the application must be considered before tuning these parameters. Siebel Expert Services should be involved in order to have a proper review performed. Tuning of the Siebel Object Manager is essential to ensure good performance. Change Request 12-JPFLPV has been raised to address the documentation enhancement request of adding this information to the future revisions of the Siebel Bookshelf > Performance Tuning Guide.

Related Products

Siebel > Customer Relationship Management > CRM - Enterprise Edition > Siebel System Software Errors ERROR 2024; SBL-SMI-00114; SBL-SMI-00101; SBL-SSM-00029

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=476830.1

01/04/2010