Defining a service policy
You can define service policies and, for most kinds of work requests, work classes to categorize and prioritize work requests. A service policy consists of a user-defined performance goal and an importance level, in some cases.
Before you begin
You must have administrative privileges to perform the following tasks:
- To create, modify, or remove service policies and transaction classes
- To modify rules through the rule builder
About this task
Service policies are related to work requests through transaction classes. Each work request belongs to exactly one transaction class, and each transaction class belongs to exactly one service policy. For most kinds of work requests, work classes are used to map incoming requests to transaction classes. Each work class is attached to a Java™ Platform, Enterprise Edition (Java EE) application and a basic request feature; URI prefix for HTTP, method name for IIOP, and bus destination for Java Message Service (JMS). Each work class specifies how the relevant requests are classified into transaction classes. For generic server clusters and for SIP, work classes are not used; instead, the rules for classifying requests to transaction classes are configured on the ODRs. You can use the service policy custom properties to generate service policy alerts for persistent service policy violations on a transaction class basis. For more information read about service policy custom properties.
For SIP over UDP traffic, you must enable the admission control for CPU overload protection to prevent retransmissions from occurring because of CPU overload. When using admission control for CPU overload protection for SIP, the discretionary type of goal must NOT be used. Only the average response time or percentile response time goals should be used. The response time threshold specified in the goal should be well under the value of the client's T1 timer (which defaults to 500 milliseconds). The rejection average response time threshold (the value derived from the goal's response time threshold and the rejection policy configured on the ARFM control panel, should be less than the client's T1 timer. For information about enabling the admission control for CPU overload protection, read about configuring the autonomic request flow manager.
Restriction: When dialog/session orientation is enabled for HTTP or SIP, a service policy cannot apply to messages that are part of pre-existing dialogs or sessions, and messages that are NOT part of pre-existing dialogs or sessions.
When you create service policies, consider the following specifications for configuring the goal value: set the goal value when the goal type is either average response time or percentile response time. To set an appropriate goal value, measure the average response time of your application when there is little or no load. Set the goal value to approximately double the observed average response time. For example, if your application average response time is 1 second, set the goal value to 2 seconds.
- Disable the autonomic request flow manager (ARFM) queueing by setting the arfmManageCpu cell custom property to false.
- Enable the visualization data service. For more information, read about configuring the visualization data service.
- Allow your application to run under normal load for a specific time period (for example, one week, or one month).
- View the average response time for your application in the administrative console under .