Services Isolation

PPM has many asynchronous background services that process data "behind the scenes" while the application is running. Depending on data characteristics of your PPM; deployment, the overhead of these services in terms of CPU and memory demand are difficult to estimate. To reduce the impact of services on user response times, We strongly recommend that you isolate the services on a separate JVM within the PPM server cluster.

Services isolation does not require isolation of services onto separate physical servers. A node that you dedicate to services can reside on the same machine that hosts nodes handling user traffic. Even in a shared host model, there is benefit if higher performance-risk services, which tend to be CPU-bound on the application tier, have a separate node.

PPM server clustering does not differentiate between primary or backup nodes in terms of configuration. The first node to start up attempts to be the "service primary." If a node that is considered to be a "backup" starts first, then it is the primary. The objective is to earmark a subset of nodes in the server cluster as services-capable. All of the nodes are peers, and "ownership" of services is based simply on startup order.

Note: If a node that is running services fails, one of the other nodes enabled to run services assumes the role of primary. If the node that failed is restarted, services will not automatically "fallback" to that node. To return services ownership to the node that failed and is restarted, you must stop, and then restart the node that took over services execution from the original services node.

We recommend that you devote at least one PPM node to process PPM; background services. (For an example, see Solution Configuration 1.)

Dedicating one PPM; node to your services enables you to:

Minimize the effect that running PPM; services has on users
Better monitor the performance of the services

The more you monitor and understand how your services affect performance, the better you can tune them.