4 Tuning the Siebel Server Infrastructure for Performance

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:

"Configuring SISNAPI Connection Pooling for Siebel Application Object Managers"
"Tuning Server Request Broker (SRBroker)"

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
Siebel Security Guide

Configuring SISNAPI Connection Pooling for Siebel Application Object Managers

This topic provides information about how to manage SISNAPI (Siebel Internet Session application programming interface) connections for your Siebel Server.

SISNAPI, a messaging format that runs on top of the TCP/IP protocol, is used for network communication between Siebel Application Object Manager and Siebel Web Server Extension (SWSE), which is installed on the Web server. SISNAPI connections can be configured to use encryption and authentication based on Transport Layer Security (TLS).

Each multithreaded process for a Siebel Application Object Manager component uses a pool of SISNAPI connections managed by the SWSE. The process multiplexes (shares) many client sessions over each connection.

Each client session request opens a new connection and adds it to the pool, until the number of connections defined by the value of the parameter SessPerSisnConn have been created. Subsequent requests are then multiplexed over the existing pooled connections. SISNAPI connections persist until one of the following events occur:

The Web server process terminates.
The Siebel Application Object Manager component terminates.
The value of the parameter SISNAPI Connection Maximum Idle Time (alias ConnIdleTime) is reached. For more information on this parameter, see Siebel System Administration Guide.
Your firewall times out the connection.

Multiplexing traffic over a set of SISNAPI connections helps to reduce the number of open network connections.

The SISNAPI connection pool size per multithreaded process for a Siebel Application Object Manager is determined by the combined settings of MaxTasks, MaxMTServers, and SessPerSisnConn. In general, the maximum number of SISNAPI connections created would approximately equal MaxTasks divided by MaxMTServers, then divided by SessPerSisnConn (resolved to an integer).

SessPerSisnConn determines how many sessions can be multiplexed over a single SISNAPI connection. By default, SessPerSisnConn is set to 20 for Siebel Application Object Manager components. This figure is suitable for most deployments and generally does not need to be changed. You might set this differently, depending on how you have calculated think time. For more information, see "Performance Factors for Siebel Application Object Manager Deployments". For more information about configuring MaxTasks and MaxMTServers, see "Tuning Siebel Application Object Manager Components for CPU and Memory Utilization".

Caution:

If you set SessPerSisnConn to a value of 1, then you must set the parameter ConnIdleTime to a value other than -1 (its default value). Otherwise, this combination of settings might cause the Web server to stop running.

The number of actual SISNAPI connections per multithreaded process for the Siebel Application Object Manager is determined by the following formula:

(MaxTasks divided by MaxMTServers) divided by SessPerSisnConn = SISNAPI_conn_per_process

In this formula, SISNAPI_conn_per_process represents the number of SISNAPI connections per multithreaded process.

Assume, for example, the following parameter values:

MaxTasks = 600
MaxMTServers = 5
SessPerSisnConn = 20

In this case, the formula would be:

(600 divided by 5) divided by 20 = 120 divided by 20 = 6

Or, if MaxTasks = 540 and SessPerSisnConn is set to 18, then the formula would be:

(540 divided by 5) divided by 18 = 108 divided by 18 = 6

In each case, six SISNAPI connections will be created and pooled for each Siebel Application Object Manager multithreaded process, from each SWSE. Each Web server and SWSE can potentially have its own set of six connections, so the maximum total number of connections into a Siebel Application Object Manager process is six times the number of Web servers. In the first example above, 20 sessions would be multiplexed over each connection. In the second example, 18 would be multiplexed over each connection.

Note:

In general, it is recommended that the figures used for the above formula be tailored to produce an end result that is an integer. To achieve this, you might need to modify how you define MaxTasks, MaxMTServers, and SessPerSisnConn.

Some Object Manager components are not Siebel Application Object Manager components. Configuration issues for such components differ from those applicable to Siebel Application Object Manager components. For information about the EAI Object Manager, see Chapter 9, "Tuning Siebel EAI for Performance."

Tuning Server Request Broker (SRBroker)

The Server Request Broker (SRBroker) component routes requests between Siebel Server components, such as from a Siebel Application Object Manager to a batch component. SRBroker also handles requests between batch components. SRBroker is used whether the components run on the same computer or on different computers.

Server requests originating with a Siebel Application Object Manager component always go to the SRBroker component to determine what to do with the request:

If the destination component is running on the same Siebel Server, then SRBroker passes the request to this component. If multiple instances of the destination component are running, then SRBroker passes the request to each component instance in a round-robin fashion.
If the destination component is not running on the same Siebel Server, then SRBroker passes the request to SRBroker running on another computer. If the destination component runs on multiple Siebel Servers, then SRBroker passes the request to each server in round-robin fashion.

The default parameter values for SRBroker work well for most deployments. If necessary, adjust the value of the MaxTasks parameter (the default value is 100). MaxTasks determines the maximum number of SRBroker threads (tasks) that can run on the Siebel Server. As necessary, set MaxTasks to a value equal to the number of batch components running on the Siebel Server, plus the number of Siebel Servers in the enterprise, plus 10 (for overhead).

MaxMTServers and MinMTServers determine the maximum and minimum number of SRBroker multithreaded processes that can run on the Siebel Server. Each multithreaded process can run a maximum of MaxTasks divided by MaxMTServers threads. Default values for MaxMTServers and MinMTServers must be set to 1. Increasing this value will not increase performance, and will not have any benefit.

Caution:

Setting MaxTasks parameter values for SRBroker components in such a way that does not meet the above guidelines might result in request failures.

For more information about the SRBroker and SRProc components, see Siebel System Administration Guide.

About Synchronous and Asynchronous Requests Forwarded by SRBroker to Batch Components

The SRBroker component forwards synchronous and asynchronous requests to batch components like Workflow Process Manager, running on the same server or on a different server. Asynchronous requests can use either of two modes, Asynch mode or DirectDb mode. (Using DirectDb mode is generally recommended.) A target component must be available in order for the request to succeed. Load balancing and appropriate sizing of batch components can help ensure that your server resources are effectively used and that all requests are fulfilled.The Server Request Processor (SRProc) component, running on each applicable server, is also used in handling some requests. For requests made using DirectDb mode, SRProc writes the requests into the S_SRM_REQUEST table. SRProc running on the same or a different server also forwards requests to target batch components.Requests might in some cases cause a target batch component to reach its maximum number of tasks, as set using MaxTasks. In such cases, the requests are handled as follows, depending on the type of request and on the setting of the HonorMaxTasks parameter on the target batch component:

For synchronous requests or asynchronous requests using Asynch mode, if the target batch component has reached the maximum number of tasks, then the component queues the request in memory for processing when tasks become available. Queuing such tasks minimizes the potential of request failure on the batch component due to the MaxTasks value having been reached. However, in some cases, requests might remain in the queue in the process memory, delaying processing.For an asynchronous request made using DirectDb mode (which is generally recommended), the SRProc component on the same or a different server forwards the request from the S_SRM_REQUEST table to the target batch component. If the target batch component has reached the maximum number of tasks, and the parameter HonorMaxTasks is FALSE (the default setting), then the component queues it in memory for processing when tasks become available. Queuing such tasks minimizes the potential of request failure on the batch component due to the MaxTasks value having been reached. However, in some cases, requests might remain in the queue in the process memory, delaying processing.For an asynchronous request made using DirectDb mode, the SRProc component on the same or a different server forwards the request from the S_SRM_REQUEST table to the target batch component. If the target batch component has reached the maximum number of tasks, and the parameter HonorMaxTasks is TRUE, then it is unable to accept the request. However, SRProc on the same or a different server can forward the request from the S_SRM_REQUEST table to a target batch component for processing when tasks become available. Requests that are queued in the database are subject to less risk due to process failure or hangs than requests that are queued in memory.

Note:

Settings for MaxTasks, MaxMTServers, MinMTServers, and HonorMaxTasks are used by the Application Object Manager components for Siebel Mobile applications, as with other Siebel applications. Load balancing is supported for Siebel Mobile applications. To support synchronization for a Siebel Mobile disconnected application that participates in load balancing, you must set HonorMaxTasks to TRUE for the component the application uses for synchronization.

Set MaxTasks and HonorMaxTasks as appropriate for each batch component, according to your usage cases, request volumes, and overall topology. Consider that, if batch components sometimes experience hang issues, then it might be undesirable to queue requests in component memory.For help resolving any component failure or hang issues, create a service request (SR) on My Oracle Support. Alternatively, you can phone Global Customer Support directly to create a service request or get a status update on your current SR. Support phone numbers are listed on My Oracle Support.

Related Books

Siebel Deployment Planning Guide

Siebel System Administration Guide

Siebel Business Process Framework: Workflow Guide

Siebel Mobile Guide: Disconnected

Article 477818.1 (Article ID) on My Oracle Support