Siebel Performance Tuning Guide > Tuning the Siebel Server Infrastructure >

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 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 these 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.

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 Topic

Tuning Workflow Process Manager for Performance

Related Books

Siebel Deployment Planning Guide

Siebel System Administration Guide

Siebel Business Process Framework: Workflow Guide

Article 477818.1 (Article ID) on My Oracle Support