This action might not be possible to undo. Are you sure you want to continue?
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
Siebel System Software - Version: 7.0.4  - 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.
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
Max Tasks Maximum number of tasks represents the maximum number of concurrent user sessions that can run on a server at one time. All these tasks will be counted towards the value of the MaxTasks parameter.Page 2 sur 8 automatically be started (with status 'Handling Requests'). The same 25 ratio is recommended for eCommunications Object Manager. memory. As with any high performance system. and the term Server Task refers to a user session being executed by a thread of that process. But the ratio in these scenarios can go from around 25 to 75. The term Multithreaded Server. Using the Server Manager command line utility.com/CSP/main/article?cmd=show&type=NOT&id=476830. An MT Server is equivalent to a single process of an Object Manager. more user-friendly terms are used to express the same concepts. to make sure that the Siebel application has been tuned correctly. each user login will spawn a new task. During the think time. assuming an average think time of 30 seconds between user operations. Minimum MT Servers determines how many MT Servers start initially when the Siebel Server starts. in the event many users log out. refers to an OM process. These user tasks will remain active until the user logs out. For Object Managers that use Product Configurator. Multiple OM processes can be run on each Siebel Server. When users start to log in. The default value is 20. The loading of a new MT https://support. such as lack of memory. 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 does not include query time. there are 1000 concurrent users. The first step to consider is the projected number of concurrent users for the Siebel application. 1.oracle. the Siebel Administrator can run the "list statistics" command to calculate the "Average Think Time" for a process. working in another application (such as email) or doing some other task. and CPU time while not succumbing to high levels of context switching. MaxTasks = concurrent users + anonymous user pool [1000+100] 2. It also determines the minimum number of MT Servers to run on a Siebel Server. NOTE: For Siebel Servers running on the Solaris platform: When using the Oracle 8i client. For additional information and workarounds for this behavior. Each MT Server is implemented as an operating system process. The think time is the idle time when the server or the client is not doing anything. srvrmgr. The following case study will provide concepts and examples to educate the Siebel Administrator in tuning their Siebel eBusiness Application. The goal is to tune the SOM to efficiently use the database connections. the recommended MaxTasks / MaxMTServer ratio is 25. Processes and threads are programming terms for things running at the operating system level. 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. Siebel Expert Services provides a Production Readiness review. This multiprocessing and multithreaded programming model provides Siebel software with a very high degree of scalability. setting a high ratio of tasks per OM process may cause the object manager to end unexpectedly. Number of Sessions per SISNAPI Connection = 20 Observations: For environments where there is lack of machine resource. It is necessary to make tests to tune it and find a proper value. proper tuning is required to assure optimal operation. it has its own memory space and processor identifier (PID). It is also used to calculate how many tasks can be run on each MT Server. There are many parameters to consider when tuning a Siebel OM.1 01/04/2010 . MaxMTServers = MaxTasks / 100 [1100/100 = 11] 3. the user may be conversing on the telephone. or MT Server. This information is used to calculate the first set of parameters. In this case study. At the Siebel Server level. it is recommended a lower MaxTasks / MaxMTServer ratio.
x. This helps to reduce the number of open network connections.com/CSP/main/article?cmd=show&type=NOT&id=476830. then the ratio is 50:1 (50% of 100:1). server could be busy. For example. Please close the web browser.x. This parameter specifies the number of Sessions that can share one SISNAPI Connection between the web server and the application server. This will give Siebel Administrators an initial benchmark of performance. The following message in the Object Manager log files: GenericLog GenericError 1 2003-12-01 09:03:41 (smimtpool. Siebel Systems generally recommends decreasing the SessPerSISNAPIConn from its default value of 20 rather than increasing the value of this parameter. In order to prevent this delay. The ratio MaxTasks / MaxMTServers is equal to the Max Number of Tasks running in one instance of a MT Server.x. NOTE: For Siebel version 7. Siebel Administrators may set the Minimum MT Servers parameter equal to the Maximum MT Servers parameter.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.1 01/04/2010 . if you are seeing OM reaching MaxTasks errors (error # 3 above). the recommended value is 20. start a new one and try logging in again. For further support.0. then the ratio is 200:1 (200% of 100:1). a new MT Server will be started. while allowing the potential for spikes in user load. then this ratio is 5 (100/20). Incorrectly configured Maximum Tasks and Maximum MT Servers parameters could result in the following behaviors: 1. please try again later. In Siebel version 7. Siebel Systems recommends that the ratio between the MaxTasks / MaxMTServers and SessPerSISNAPIConn come to an integer in the final setting. EAI HTTP Adaptor Access). Users intermittently receive the following message when launching the application: The server you are accessing is either busy or experiencing difficulties.oracle. Siebel Systems recommends administrators to begin tuning with a ratio of 100:1. When the number of running tasks exceeds the number of tasks that can be supported by the running MT Servers. If the average user think time is 15 seconds. Note that while 20 is a good value to use for user sessions. If the MaxTasks / MaxMTServers = 30. then https://support. 3. if MaxTasks / MaxMTServers = 100 and SessPerSISNAPIConn = 20.cpp 50(1960) err=2100101 sys=0) SBL-SMI-00101: The server is busy. then Siebel Systems also recommends to set the ratio between the MaxTasks / MaxMTServers and SessPerSISNAPIConn to a value of 2 or greater.0. if MaxTasks / MaxMTServers = 20. which is an integer. then Siebel Systems recommends to lower the value of the parameter SessPerSISNAPIConn to 15 so the ratio (30/15) is 2 rather than 1. 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". If the average user think time is 60 seconds. The following message in the SWSE log files: GenericLog GenericError 1 2003-12-01 09:16:24 (ssmsismgr. Customizations and usage of the Siebel application will dictate whether to increase or decrease these ratios.[09:30:19] 2. and users may experience a short delay in logging into the Siebel application. For example.5 (30/20). For Siebel version 7.Page 3 sur 8 Server into memory is CPU-intensive. please try again later. there is an extra consideration regarding the Number of Sessions Per SISNAPI Connection parameter setting. SBL-SMI-00101: The server is busy.0. please copy and send the full message text to your system administrator. it does not apply to incoming HTTP requests from other systems (for example. GenericLog GenericLog 0 2003-12-01 09:16:24  ERROR 2024: [SWSE] Login failed. assuming an average 30 second think time. However. Siebel Systems generally recommends that customers set the Minimum MT Servers parameter equal to the Maximum MT Servers parameter for most deployments.cpp 83(276) err=5600029 sys=0) SBL-SSM-00029: Failed to create session. 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.
The default is 900 seconds. It should never be set for batch mode or background mode components.3 onwards every new Web client user who logs in. the ConnIdleTime parameter can be configured to disconnect idle connections before they are blocked by the firewall. specifying the period of idle time (in seconds) after which the connection is disconnected by the component in this case. For example. in seconds. As mentioned above. This parameter should only be set at the component level.x 7. As firewalls block idle connections.5. and only for application object managers and EAI object managers. Session timeout parameter is the time. The parameter ConnIdleTime must be set to a value slightly less than the load balancer timeout. 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. this setting should only be used when a load balancer is in use for Siebel Servers configured to time out SISNAPI connections.7.5. Session Timeout and Anonymous User Pool "Session timeout" and "AnonUserPool" are parameters that are defined in the eApps. The AnonUserPool parameter determines the number of anonymous users available to retrieve the login page or error pages.0. AnonUserPool parameter will no longer appear in configuration file. the Object Manager. 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. Therefore. the load balancer available is Resonate. in Siebel versions 7. Adjust this parameter to automatically terminate a session after duration of inactivity. 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.3. They are not used for the browse feature. Valid values are numeric. which uses a different kind of anonymous user.x 8.cfg file. most load balancers have an idle connection timeout feature. NOTE: Siebel version 7. 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.Page 4 sur 8 decrease the SessPerSISNAPIConn to 10.5. In this case. if the Application Object Manager ConnIdleTime is set to 600. nor should it be set for SRBroker or any other infrastructure related component. SISNAPI Connection Maximum Idle Time This parameter configures connection timeout between the Web server and the Siebel Server.2. Siebel Systems recommends setting the AnonUserPool to 10-15% of Maximum Tasks. For recent Siebel versions. 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.5. set the load balancer connection timeout to 601 seconds or higher. the setting would be 100 (1000*10%).x and below. creates a SISNAPI connection between the Web server and the Siebel server. It will be limited by MaxTasks value of the Object Manager. from the user's last browser request until the user's connection times out. The table below shows the default value and recommended value for this parameter per each Siebel version: Siebel Version 7.x Default Value 0 -1 -1 -1 Recommended Value 300 – 3600 300 – 3600 > 30 > 30 https://support.1 01/04/2010 . This setting avoids future connection problems between the Web server and the Siebel Server.oracle.com/CSP/main/article?cmd=show&type=NOT&id=476830. By default. it should never be set at the enterprise level. If there is a firewall placed between the Web server and the Siebel Servers.x 7.
When the Object Manager starts. if the pool contains fewer than the MinTrxDbConns. Enabling database connection pooling can improve scalability by reducing the number of inactive connections and reducing the overhead of database logins. which need transactions to span multiple Object Manager operations. controls the minimum number of dedicated connections within an Object Manager MT Server. On average. When the session terminates. In other words. the dedicated connection is returned back into the pool. When a request is made to start a transaction. there will be many fewer connections than sessions. MinTrxDbConns.000 users forgo the use of this product feature. 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. 3. When DB Connection Pooling and Multiplexing are disabled. connection 1 is created using User 1's credentials and held by user 1's session. When the transaction completes. Siebel Administrators are recommended to start with a 2:1 ratio for MaxTasks / MaxSharedDBConns. This is done to optimize DB access performance by isolating different access paths. This also reduces the expensive overhead of maintaining a DB connection. One set is for simple operations that are shared. 2. so connection 2 is created with user 2's credentials. Siebel OM keeps two sets of DB connections. If one is available. such as eBusiness Application Integration (EAI). and the other is for complex transactional-type operations that are dedicated for the duration of the transaction. the Object Manager requests a database connection from the dedicated connection pool. For example: MinTrxDbConns = 2 1. User 1 starts a transaction – Since the dedicated connection pool is empty. Otherwise. The component parameter. Typical Siebel Web Client user sessions do not use these connections.oracle. each user creates a database connection at session creation and releases it at session termination. https://support. There is no explicit limit to the number of dedicated connections. Siebel Systems generally recommends that customers with fewer than 1. but effectively there cannot be more dedicated connections than sessions. the connection is submitted to the pool. It is advised that customers consult with Siebel Expert Services if they plan on using a ratio higher than 3:1. Siebel Administrators with a large number of users can lower resource utilization on their database server by limiting users to a database connection pool. the session retains the dedicated connection. User 1 commits the transaction and terminates the session – Since the pool has fewer than 2 dedicated connections. 2 user tasks will share the same database connection.com/CSP/main/article?cmd=show&type=NOT&id=476830.Page 5 sur 8 Siebel Database Connection Pooling or Database Multiplexing Siebel eBusiness Applications offers Database Connection Pooling or Database Multiplexing.1 01/04/2010 . Administrators should test the application thoroughly until they find the balance between conserving resource utilization on the application server and avoiding database bottlenecks. Setting the above parameters to -1 will disable DB Connection Pooling and Multiplexing. it is removed from the pool and given to the session for its exclusive use. Dedicated Database Connections Pool These connections are used primarily by specialized Siebel components. User 2 starts a transaction – Again the pool is empty. the dedicated connection is closed. the database connection pools are empty.
there would be. so connection 4 is created with user 3's credentials.3 > Performance Tuning Guide > Tuning the Siebel Application Object Manager for Performance > Best Practices for AOM Tuning > Configuring Shared Database Connection Pooling.Page 6 sur 8 4. User 4 starts a transaction – The pool is again empty. at which time they are either placed in the dedicated connection pool or released. User 2 ends the transaction and terminates the session – Connection 2 is inserted into the pool. Consider the following settings: MaxTasks = 400 MaxMTServers = 20 MinSharedDbConns = 40 MaxSharedDbConns = 100 MinTrxDbConns = 2 With these settings. In this scenario. Once the shared connection is assigned to the session. when needed. the component can support a maximum of 400 sessions or server tasks. when the Object Manager starts up. Select the current connection in the pool that is shared by the fewest sessions and assign it to the session. 2. Those 400 sessions would be spread over 20 MT Servers. The component parameter MaxSharedDbConns controls the maximum number of shared database connections. Unlike the MinTrxDbConns parameter. refer to the Siebel Bookshelf version 7. User 4 ends the transaction and terminates the session – Connection 4 is inserted into the pool. The following points highlight the selection algorithm. As with the dedicated connections. 3. 8. with 400 sessions active. If the usage count has reached 0 (that is. new dedicated connections are created on demand. The component parameter MinSharedDbConns controls the number of shared database connections the Object Manager will try to keep available. 7. Shared Database Connections Pool These connections are used by most Object Manager operations. create a new connection. the shared connection pool is empty. 40 unused dedicated connections (2 in the dedicated pool of each MT Server). 5. and assign it to the session.1 01/04/2010 . NOTE: A long-running query on a shared database connection may block other users sharing that database connection. the MinSharedDbConns and the MaxSharedDbConns parameters are defined per component. each shared database connection would service 4 sessions. other than the specialized operations that would use a dedicated connection. For more information about this topic.com/CSP/main/article?cmd=show&type=NOT&id=476830. The dedicated connections are held until the end of the session or server task. Since the MinTrxDbConns setting would be per MT Server. 6. If the number of connections in the pool is less than MaxSharedDbConns. and using a total of 100 database connections. As illustrated in the example above. If an unshared connection is available. which is per MT Server. all database operations. User 3 starts a transaction – Connection 1 is taken off the pool for user 3's session. assign it to the session. When the session terminates. each having 20 sessions. the usage count for the connection is decremented.5. User 3 ends the transaction and terminates the session – Connection 1 is closed because the pool already contains 2 dedicated connections. In other words. the shared pool is checked to see if a connection is available. 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). insert it into the pool. go through the shared connection. MaxSharedDbConns controls the maximum total number of database connections for the component. When a session logs into the Object Manager. Note that it is not removed from the pool. at most.oracle. 1. no https://support. on a particular Siebel Server. Any connections in the pool at the time the MT Server shuts down are released.
cfg file for High Interactive mode clients on the Siebel Server. This will impact faster client response times and better network behavior. Users 1-5 login – Shared connections 1-5 are created and added to the pool. All connections have a usage count of 2. User 2 issues a query – Multiplexed connection 2 is used for the request 4. 10. User 4 logs off – Connection 4's usage count is decremented to 0. All connections have a usage count of 1. Set "EnableCDA = FALSE" in the *. User 7 logs off – Connection 2's usage count is decremented to 0. it remains in the pool. the connection is removed from the pool and closed.Page 7 sur 8 sessions are using this connection).1 01/04/2010 . Since it is the only unused connection in the pool. It uses the Least Recently Used (LRU) mechanism to flush out the cache. Users 11 and 12 login – Connections 3 and 4 are assigned to the new sessions. NOTE: Min Number of Dedicated DB Connections is per MT Server. 2. Set "Timed Statistics" = Off. Set "EnableViewCache = TRUE" in the *. 7. it also remains. Configure components so that machines run at 65% to 80% capacity. 3. Set all the above parameters as recommended. Otherwise. if server consistently runs at https://support. 9. Etc. 4 and 5 have their usage count decremented. When the MT Server shuts down. it is left in the pool.com/CSP/main/article?cmd=show&type=NOT&id=476830. User 13 logs in – Connection 6 is created and added to the pool since there were less than MaxSharedDbConns in the pool.oracle. 8. . 3. 2. All the connections remain in the pool.cfg file of the Siebel Server if users are not using eConfigurator. Users 2. Set all Event Log Levels to 1. Since it is the 2nd unused connection in the pool. 4. 11. while the other two (Min Number of Shared DB Connections and Max Number of Shared DB Connections) are per server component. 3. 6. 3. 5.. 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. User 3 issues a query – Multiplexed connection 3 is used for the request 5. Since there are already MinSharedDbConns unused connections in the pool. Users 6-10 login – Shared connections 1-5 are assigned in turn to the new sessions. User 8 logs off – Connection 3's usage count is decremented to 0. Best Practices 1. The following example may help illustrate this scenario: MinSharedDbConns = 2 MaxSharedDbConns = 5 MaxTasks = 20 MaxMTServers = 1 1.. 9 and 10 logoff – Since none of the users are sharing the same connection. any remaining connections in the pool are closed. 6. Setting all three parameters to the same value will result in a high number of dedicated connections maintained. connections 2.
1 01/04/2010 . etc. 1500MB / 150MB = 10. an evaluation of the application must be considered before tuning these parameters. then the number of MaxTasks and MT Servers should be reduced accordingly. the rest can be calculated to determine the number of tasks and number of MT Servers that a machine can support. Before testing 1. then the number of MT Servers that can run on this machine is reduced to about 7. 9. Depending on the High availability requirement.000 concurrent users will be logged in and using the system. See example below. Related Products Siebel > Customer Relationship Management > CRM . 4GB – 500MB = 3500MB. or amount of paging is excess.exe process and understanding how it will run under loaded conditions. 150MB of RAM and about 10% of the CPU. Tuning of the Siebel Object Manager is essential to ensure good performance. Whenever possible. Once this data is known. such as the amount of memory used. For an example. 2GB of RAM – 500MB for the O/S leaves 1500MB for the Siebel processes.com/CSP/main/article?cmd=show&type=NOT&id=476830. 3500MB / 200 = 17. Then calculate the number of MT Servers that can run on each machine. for example.oracle.Enterprise Edition > Siebel System Software Errors ERROR 2024. so once it is determined how one process will behave. then approximately 10 MT Servers can be running on this machine at the same time. In conclusion. Assume that the data returned from this test shows that this one process used. 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. 1. A machine with 4GB and 4 CPU's can run 17 MT Servers. Test a single MT Server process to gauge how much memory it will use. SBL-SMI-00101. on average. depending on think time and what they are doing in the Siebel application. Each process that runs as part of an Object Manager essentially runs the same way. They anticipate that at any one time. 8. it is important to know how a single process will behave. This process can probably handle 70-80 concurrent users. CPU utilization.000 customers. 7. Siebel Expert Services should be involved in order to have a proper review performed. A larger machine can run more processes. This will provide meaningful data on the behavior of a single siebmtshmw.Page 8 sur 8 above 80% CPU utilization. Siebel Systems recommends becoming familiar with the siebmtshmw. Company ABC wants to roll out eChannel to their 10. If this small test reveals that the process used 200MB. in other words when one server goes down and the other servers pick up the load. use real end users for this smaller test to get a more realistic simulation. If the Siebel server machine has 2GB of memory and 2 CPU's.5.000 concurrent users. Run the test for 45 minutes to several hours so that there is a fair amount of turnover of tasks. The easiest way to do this is to run tests on a small scale.exe process. sizing may have to account for fail over scenario. see the scenario below. SBL-SMI-00114. MaxTasks = 100 and MaxMTServers = 1. accurate parameter values can be extrapolated. Disable all unnecessary component groups to reduce system resources. 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. SBL-SSM-00029 https://support.
This action might not be possible to undo. Are you sure you want to continue?