The Siebel Object manager (OM) is a Siebel server component which is used to primarily execute sessions for the remotely executed UI client/Web client.
The Siebel Object manager is a multithreaded process, which means one process can execute multiple concurrent threads. When an Siebel OM is started on a Siebel server, an OM task will be automatically started (with status "Handling Requests"). When users start to log in, each user login will create a new task. These user tasks will remain active until the user logs off. All these tasks will be counted towards the MaxTasks parameter.
Multiple OM processes can run on the Siebel server.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.
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.
To enable object manager think time -
change param TimedStats=True for comp <OM>
change param DumpStats=True for comp <OM>
Using the Server Manager command line utility,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.
MaxTasks = concurrent users + anonymous user pool [1000+100]
MaxMTServers = MaxTasks / 100 [1100/100 = 11]
Number of Sessions per SISNAPI Connection = 20
For Object Managers that use Product Configurator, the recommended MaxTasks / MaxMTServer ratio is 25.
The same 25 ratio is recommended for eCommunications Object Manager.
The Siebel Object manager is a multithreaded process, which means one process can execute multiple concurrent threads. When an Siebel OM is started on a Siebel server, an OM task will be automatically started (with status "Handling Requests"). When users start to log in, each user login will create a new task. These user tasks will remain active until the user logs off. All these tasks will be counted towards the MaxTasks parameter.
Multiple OM processes can run on the Siebel server.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.
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.
To enable object manager think time -
change param TimedStats=True for comp <OM>
change param DumpStats=True for comp <OM>
Using the Server Manager command line utility,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.
MaxTasks = concurrent users + anonymous user pool [1000+100]
MaxMTServers = MaxTasks / 100 [1100/100 = 11]
Number of Sessions per SISNAPI Connection = 20
For Object Managers that use Product Configurator, the recommended MaxTasks / MaxMTServer ratio is 25.
The same 25 ratio is recommended for eCommunications Object Manager.
MaxTasks
It represents the maximum number of concurrent sessions that can be run on a server at one time.
each MTServer is implemented as an OS PID and has its own memory.an MTServer is a single process of an Object manager.
Max MT Servers and Min MT Servers
Max MT Servers determine the maximum number of multithreaded processes that can be run by the object manager.It is also used to calculate the number of tasks that can be run on each MT server. Min MT Servers determine how many multi threaded processes are initially started when the siebel server starts. starting a new MT server is memory intensive and the user might face some performance impact. The Siebel administrator can set Max MT Servers = Min MT Servers to prevent this.
Number of sessions per SISNAPI connection
This specifies the number of connections that can share one SISNAPI connection from the web server to the Application server.
This is done by setting the parameter "Number of Sessions per SISNAPI Connection"; the recommended value is 20.
This reduces the number of open connections. This does not apply for incoming HTTP requests coming from other external systems like EAI.
SISNAPI connection Maximum Idle Time
This parameter configures the timeout between the web server and the Siebel server.
You should be using/changing this parameter only when you are using Siebel server load balancing or if there is a firewall b/w the web server and the siebel server.
This parameter should be set only for the Application OM or the EAI OM but not for the Batch or Background components or even the SRBroker component.
Siebel Database Connection Pooling or Database Multiplexing
It is best to use this feature when we have more than 1000 users and for scalability.
It reduces the number of inactive connections and the overhead of creating a new connection for login.It is best to start with a ratio of 2:1 for MaxTasks / MaxSharedDBConns.
This will ensure 2 users will share one database connection.
Below are the parameters that control this:
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)
set MaxSharedDbConns and MinSharedDbConns to a positive value but not greater than maxTasks.
- MaxSharedDbConns controls the maximum number of pooled database connections for each MT process.
- MinSharedDbConns controls the minimum number of pooled database connections the Application object manager maintains for each MT process.
- to disable this feature set the value for both MinSharedDbConns = MinSharedDbConns = -1
Below is an Example:
Assume a system with the below parameters set:
MinSharedDbConns = 3
MaxSharedDbConns = 6
MaxTasks = 20
MaxMTServers = 1
Users 1-6 login – Shared connections 1-6 are created and added to the pool. All connections have a usage count of 1.
Users 7-12 login – Shared connections 1-6 are assigned in turn to the new sessions. All connections have a usage count of 2.
User 2 issues a query – Multiplexed connection 2 is used for the request
User 3 issues a query – Multiplexed connection 3 is used for the request
this goes on for each user. Below is a simple representation of the same.
Connection 1> users 1 and 7
Connection 2> users 2 and 8
Connection 3> users 3 and 9
Connection 4> users 4 and 10
Connection 5> users 5 and 11
Connection 6> users 6 and 12
Users 2, 3, 11 and 12 logoff – Since none of the users are sharing the same connection, connections 2, 3, 11 and 12 have their usage count decremented. All the connections remain in the pool.
Connection 1> users 1 and 7
Connection 2> user 8
Connection 3> user 9
Connection 4> users 4 and 10
Connection 5> users 5
Connection 6> users 6
User 9 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.
Connection 1> users 1 and 7
Connection 2> user 8
Connection 3>
Connection 4> users 4 and 10
Connection 5> users 5
Connection 6> users 6
User 5 logs off – Connection 5's usage count is decremented to 0. Since it is the 2nd unused connection in the pool, it also remains.
Connection 1> users 1 and 7
Connection 2> user 8
Connection 3>
Connection 4> users 4 and 10
Connection 5>
Connection 6> users 6
User 6 logs off – Connection 6's usage count is decremented to 0. Since it is the 3rd unused connection in the pool, it also remains.
Connection 1> users 1 and 7
Connection 2> user 8
Connection 3>
Connection 4> users 4 and 10
Connection 5>
Connection 6>
User 8 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.
Connection 1> users 1 and 7
Connection 3>
Connection 4> users 4 and 10
Connection 5>
Connection 6>
Users 13, 14 and 15 login – Connections 3, 5 and 4 are assigned to the new sessions.
Connection 1> users 1 and 7
Connection 3> User 13
Connection 4> users 4 and 10
Connection 5> User 14
Connection 6> User 15
User 16 logs in – Connection 7 is created and added to the pool since there were less than MaxSharedDbConns in the pool.
Connection 1> users 1 and 7
Connection 3> User 13
Connection 4> users 4 and 10
Connection 5> User 14
Connection 6> User 15
Connection 7> User 16
When the MT Server shuts down, any remaining connections in the pool are closed.
