Setting the PROCESS_WARM parameter

The PROCESS_WARM parameter sets the desired number of prestarted but unassigned Teamcenter servers. A warm Teamcenter server is one that has been started and established its database connection, and then is held in readiness for a user for logon. If there are no warm Teamcenter servers, a new logon attempt displays a message that a server is not available, and to try later. It takes a certain amount of processing to start up a new Teamcenter server process to the point it can be added to the warm pool. A major part of this processing can be consumed simply by loading the shared libraries into the process. Different machines consume different amounts of processing resources do to this. Other factors can also come into play. On Solaris, for example, loading the shared libraries over NFS paths can consume more processing resources than loading them from local disks. The PROCESS_WARM parameter is the most difficult to optimize, because it requires an estimate of the burst rate of logons that may occur. If the PROCESS_WARM value is set too low, users in the rear of a burst of logon requests may encounter the tcserver is not available, try again later message, and a later logon will be successful. To minimize this situation, the PROCESS_WARM value can be increased. As defined at the start, PROCESS_WARM is a desired number of Teamcenter servers to be warm, but not assigned. This configuration value comes into play if the sum of assigned servers + PROCESS_WARM is greater than the PROCESS_TARGET for that time of day. In this case, the pool manager responds to a logon (which moves a server state from warm to assigned) by starting one or more servers (not to exceed the rate dictated by PROCESS_CREATION_DELAY) to make up the PROCESS_WARM deficit. A burst of logon requests begins in a state with the warm pool fully populated, extends until the warm pool is again fully populated, and contains one or more logon intervals faster than the rate dictated by the PROCESS_CREATION_DELAY. A new Teamcenter server takes a minimum of [warmCPUSec] seconds to become available, and then servers are added to the pool at a maximum rate of one per the setting in the PROCESS_CREATION_DELAY parameter. The following graphic illustrates an assignment burst that starts at time T1, and continues until it exhausts the number of available warm servers sometime later during the time new servers are being added to the pool. The number of Teamcenter servers added as warm per second after the delay [warmCPUSec] is (1000 mSec/Sec) / PROCESS_CREATION_DELAY. Keep in mind the following: If the burst interval is less than [warmCPUSec], a burst of logons greater than PROCESS_WARM encounters an empty warm pool. If the burst interval is greater than [warmCPUSec], a burst of logons greater than PROCESS_WARM + (1000 * ([burst_interval] – [warmCPUSec])) / PROCESS_CREATION_DELAY encounters an empty warm pool. Typically, you do not need to perform this level of detailed analysis on pool logon demands. Note that: Large PROCESS_CREATION_DELAY values should prompt you to configure larger PROCESS_WARM pools. Note Large PROCESS_CREATION_DELAY values should be configured for low numbers of server CPUs or long values of [warmCPUSec]. If you chose a low fraction of the machine to be used to start up new servers to compute optimum PROCESS_CREATION_DELAY, you may want to configure a larger PROCESS_WARM value to compensate for the longer startup delays. Excessive occurrences of low or exhausted warm margins should prompt either an upward adjustment of the PROCESS_WARM value, the PROCESS_TARGET minimum for that time of day, or both.