Performance Tuning Guide > Tuning the Siebel Server Infrastructure for Performance >

Tuning Server Request Broker (SRBroker)

The Server Request Broker (SRBroker) component routes requests between Siebel Server components, such as from an AOM to a batch component. SRBroker also handles requests between batch components. SRBroker is used whether the components run on the same machine or on different machines.

Server requests originating with an AOM 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, SRBroker passes the request to this component. If multiple instances of the destination component are running, 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, SRBroker passes the request to SRBroker running on another machine. If the destination component runs on multiple Siebel Servers, 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/MaxMTServers threads. MaxMTServers and MinMTServers should be kept at their default values of 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 may result in request failures. See the discussion of the HonorMaxTasks parameter in the following section for more information about how requests submitted to batch components may be handled. (HonorMaxTasks has no effect when set on the SRBRoker or Server Request Processor (SRProc) components.)

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

About HonorMaxTasks Parameter for Batch Components

By default, the HonorMaxTasks parameter for batch components, such as Workflow Process Manager, is set to FALSE (this setting is recommended). With this setting, if requests are routed by SRBroker to a batch component that has reached the maximum task capacity, the requests will be queued in memory, and processed 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.

You may consider setting HonorMaxTasks to TRUE for batch components in the following scenarios:

• For batch components handling asynchronous requests, consider changing HonorMaxTasks to TRUE if servers running these components have different resource levels and are therefore configured with different MaxTasks values for these components. In this case, larger servers would be forced to handle more requests. (However, if components are not running at maximum task capacity, this effect may be hard to observe.)
• If batch components are suffering from crash or hang issues, it may be undesirable to queue requests in component memory. If HonorMaxTasks is TRUE, success or failure status of each request will be correctly reported. (This optional usage is a temporary measure only. Work with Siebel Technical Services to resolve any component crash or hang issues.)

See also Tuning Workflow Process Manager for Performance.