Siebel Field Service Guide > Scheduling and Dispatch > Scheduling Administration >

Setting Up Server Processes, Performance, and Key-Based Routing

Every Siebel server can run one or more service regions. Large service regions can run on a dedicated server.

Each service region can run on only one application server. This allows the information for one service region to be cached within memory instead of being continually read from the database, reducing the load placed on the database during schedule optimization.

The ABS and Optimizer interact with the database only at these times:

• Data loading. The ABS and Optimizer read large amounts of information from the database on start up, or when the service region is reloaded. For more information, see Loading and Reloading Service Region Data. For this reason, it is best to avoid reloading during a busy time.
• Saving schedules. The Optimizer can save its result sets to the database at specified time intervals, but unless this is a very large data set, it should not noticeably affect database performance. For more information, see the parameter, Optimizer - Save Interval in Table 30.

A scheduling request must be routed to the correct application server. To accomplish this, Siebel Scheduling takes advantage of the key-based routing available to Siebel servers. There are two server key mappings, one for the ABS and one for the Optimizer. For more information, see Server Key Mappings View.

When the user clicks the Book Appt button, the request is sent to the enterprise server. The enterprise server then looks at a map of the service regions and routes the request to the appropriate Siebel server that stores that service region.

Multi-Processor Support

If the underlying operating system can support multiple processors on one computer, Siebel Scheduling can take advantage of those processors by running different service regions for the ABS and Optimizer on different processors. This is accomplished by setting different process numbers in a server key map. A server with a single processor can run multiple processes, but this may reduce performance.

NOTE:  The number of processes running on a server computer bears no relation to the number of processors in that computer.

Since the ABS and Optimizer are different modules, they are already running as separate processes, even though the process number is the same. One module for one service region can only run in one process at a time.

For example, consider a four-processor computer, with only two of the processors in use. If one service region runs with both the ABS and Optimizer, the key map would look like the following example.

NOTE:  It is not possible to run one module for a service region as two processes.

If two service regions run on a four-processor computer, it is possible to use all four processors, as in the following example.

If there are more than two service regions on a four-processor machine, it is possible to run them as different processes. For example, if the West Coast Region is very large and the Central and East Coast regions are smaller, the following scheme might be the best use of the processors on a server.

The West Coast region, which requires more computation, uses two processors. The East Coast and Central regions run in the same processes and on the same two processors.

Each server component is multi-threaded and can load schedules for multiple service regions. These schedules are shared by multiple threads.

Each request to the Optimization Engine runs on a new thread. A request identifies the schedule for one service region that it requires and locks it. Requests for schedules for other service regions can continue while requests for the same schedule are queued.