Siebel Deployment Planning Guide > Application-Level Deployment Planning > Siebel Configurator Deployment Planning >

Siebel Configurator Deployment Topology Options

This topic is part of Siebel Configurator Deployment Planning.

As mentioned earlier, Siebel Configurator offers the flexibility of different deployment topology options. These options are as follows:

• Deploy Configurator to run on the same machine as the base application server, as shown in Figure 7.

  Figure 7. Run Configurator on base application server

• Deploy Configurator to run on a different machine than the base application server, as shown in Figure 8.

  Figure 8. Run Configurator on dedicated application server

• Deploy multiple instances of Configurator on multiple dedicated application server machines, as shown in Figure 9.

  Figure 9. Run multiple Configurator instances on multiple dedicated application servers

In many cases, the option of deploying Configurator on a different application server machine may result in a much better use of resources due to pooling effects. Considering the example examined and sized from the preceding topic, the result was a sizing of one factory and one worker to be cached for each AOM on each server. The implications of this across the whole enterprise are as follows:

• The number of AOMs on each server was 25, so each server will cache 25 factories and 25 workers.
• Across the whole enterprise of eight application servers, this translates to 25 times 8, which equals 200 factories and 200 workers to be cached.
• In memory terms:
  • 200 times 5, which equals 1000 MB for caching factories, and
  • 200 times 25, which equals 5000 MB for caching workers

    This results in a total memory usage of 6000 MB across the enterprise.

Because the requirement is to support 100 concurrent users, many of these factories and at least 100 of these workers are idling at any time. The large amount of cache in this case is because there is no way to know in advance which AOM process the user who is configuring is connected to. For this reason, caching must be done across all AOMs.

There are other problems with this scenario. For instance, what happens when two users are connected to the same AOM process and both want to configure? In this case, the second user has to create a worker, causing performance issues for that user. Also, if there are multiple users configuring on the same machine, the server might run out of memory.

Consider another scenario. Assume that the enterprise has customizable products that these users might be configuring, with 50 concurrent users configuring each customizable product. However, because there is no way to know in advance which AOM process these users might be connected to, you would have to cache two factories and two workers for each AOM, which would be a less-than-satisfactory solution.