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

Siebel Configurator Deployment Topology Options

Siebel Configurator offers the flexibility of different deployment topology options.

This topic is part of Siebel Configurator Deployment Planning.

Siebel Configurator deployment topology options are as follows:

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

  Figure 7. Run Siebel Configurator on base application server computer

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

  Figure 8. Run Siebel Configurator on dedicated application server computer

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

  Figure 9. Run multiple Siebel Configurator instances on multiple dedicated application server computers

In many cases, the option of deploying Siebel Configurator on a different application server computer might 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 Application Object Manager on each server. The implications of this approach across the whole enterprise are as follows:

• The number of Application Object Managers on each server was 25, so each server caches 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 Application Object Manager process the user who is configuring is connected to. For this reason, caching must be done across all of the Application Object Managers.

There are other problems with this scenario. For instance, what happens when two users are connected to the same Application Object Manager 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 computer, then the computer 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 Application Object Manager process these users might be connected to, you would have to cache two factories and two workers for each Application Object Manager, which would be a less-than-satisfactory solution.