Define a service policy

We 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.

We 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

For more information, read about administrative roles and privileges

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 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. We 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, 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 we 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 the application when there is little or no load. Set the goal value to approximately double the observed average response time. For example, if the application average response time is 1 second, set the goal value to 2 seconds.

We can measure the average response time for an application by following this procedure:

1. Disable the autonomic request flow manager (ARFM) queueing by setting the arfmManageCpu cell custom property to false.

2. Enable the visualization data service. For more information, read about configuring the visualization data service.

3. Allow the application to run under normal load for a specific time period (for example, one week, or one month).

4. View the average response time for the application in the console under Runtime operations > Applications.

Avoid trouble: If the goal value is set too low, additional application servers will not be started. The system determines that starting more application servers does not help to achieve the service policy goal. Set the service policy goal value to double the best average response time.gotcha

1. From the console click Operational policies > Service policy. We can select an existing service policy to edit, or click New to create a service policy. To edit an existing service policy, click the service policy name.

2. Create a name, description, and a goal type for the new service policy. The goal type can be either discretionary, average response time, or percentile response time:

   • A discretionary goal is the default, and indicates work that does not have significant value. As a result, work of this type can see a degradation in performance when resources are constrained.

   • Average response time goals are indicative of work with a higher priority than discretionary. The average response time goal is assigned a specific time goal.

   • Percentile response time goals are another measure for work with a higher priority than discretionary. The percentile response goals are defined with specific criteria on the following panel. The percentile response time target is the percentage of requests whose response time is T or less that should be P or more; a target has particular values for T and P.

3. Optional: If we select a goal type of average response time, or percentile response time, you are prompted to define the specifics and select an importance.

   For average response time goals, type a goal value, associate an importance with the service policy, and select Monitor for persistent policy violations to set up the creation of a runtime task when a policy violation occurs.

   When you associate an importance with the service policy, the options for importance vary from lowest to highest. Some planning is essential to select the correct importance value, because negative results can occur if all work is rated as highest. This rating can create a bottleneck within the environment. To define a policy violation, specify the Goal delta value and the Time period value:

   • In the Goal delta value field, type an integer to indicate the maximum allowable amount of time that exceeds the configured goal value. Acceptable values are 0 to 3000 milliseconds, 0 to 300 seconds, and 0 to 2147483647 minutes.

   • In the Time period value field, type an integer to indicate the milliseconds, seconds, or minutes after which the goal value is in violation. This value can be 0 to 1 day, inclusive.

   For percentile response time, set the goal percentile to the percentage of requests that must meet the goal value defined in the next field. Next, type a goal value, associate an importance with the service policy, and select Monitor for persistent policy violations to set up the creation of a runtime task when a policy violation occurs.

   For the goal value, type the maximum allowable time for the service policy. The environment tries to stay beneath the defined goals, and continually adjusts to achieve the most balanced result. When you associate an importance with the service policy, the options for importance vary from lowest to highest. Some planning is essential to select the correct importance value; if all work is rated as highest, negative results can occur . To define a policy violation, specify the Goal delta percentage and the Time period value:

   • In the Goal delta value field, type an integer that indicates the percentage of request beneath the goal value for which to monitor. Acceptable values are 0 to 100, inclusive.

   • In the Time period value field, type an integer to indicate the milliseconds, seconds, or minutes after which the goal value is in violation.

   A runtime task is generated when certain criteria are violated. For example, in the following percentile response time example, with a percentile goal of 90% and a goal delta of 5%, the service policy is breached when less than 85% of requests meet the service time goal of 1 second (for 5 consecutive seconds), that is, when more than 15% of requests exceed the service time goal of 1 second (for 5 consecutive seconds). The system will still prioritize traffic in such a way as to attempt to meet the 90% goal, however no notification of a breach is issued unless the 85% (90% minus 5%) threshold is not met.

   Description	Value
   Goal percentile	90%
   Goal value	1
   Importance	1
   Monitor for persistent service policy violations	true
   Goal Delta Percentage:	5%
   Time Period Value	5 seconds

   For the goal value, type the maximum allowed time for the service policy. The environment continually adjusts all automatically adjustable controls, aiming to reach, and maintain the best possible balance of relative performance results. When you associate an importance with the service policy, the options for importance vary from lowest to highest. Some planning is essential to select the correct importance value; if all work is rated as highest, negative results can occur . This rating can create a bottleneck within the environment.

4. Associate transaction class members to the service policy, or create a transaction class. If the transaction class that you are seeking does not exist, create a transaction class.

5. To create a work class for the service policy, from the console click Applications > Application types > WebSphere enterprise applications > application_name > Service policies. Select an existing service policy and for the request type, click New.

   To create a service policy for HTTP, specify a name for the work class, select a module, and select the members to add. Optionally, to use a custom URI, type its name, and click Add pattern in the Custom URI pattern field. For example, a custom URI is necessary to do JSP work.

   To create a service policy for SOAP, specify a name for the work class, select a module, and select the web service operations to add.

   To create a service policy for IIOP, specify a name for the work class, select a module, and select the EJB methods to add. Optionally, to use a custom EJB, type the information in the Custom EJB name and Custom EJB method fields, and click Add pattern.

   To create a service policy for JMS, type a name for the work class, select a module, select a defined bus, and select the EJB methods. Optionally, to use a custom bus, type the information in the Custom bus name and Custom bus destination fields, and click Add pattern.

   To create a service policy for SIP, create the following two policies:

   1. Create a default SIP policy with the following values:

      • Goal Type = Average Response Time

      • Goal Value = 75 milliseconds

      • Importance = High

   2. Create an INVITE policy with the following values:

      • Goal Type = Average Response Time

      • Goal Value = 75 milliseconds

      • Importance = Low

   3. Set the service policy SIP rules:

      • If request.method = INVITE, then classify to transaction class Default _TC_INVITE (INVITE).

      • If no rules apply, then classify to transaction class Default _TC_def_sip (def_sip).

6. The system automatically picks up any changes made to the service policy configuration. You do not need to restart any servers when you update the service policies and work classes.

Results

You have defined a business goal and applied that goal to application URIs using the service policy and routing rules. Your system can now categorize and prioritize work.

Subtopics

• (dist)(zos) servicepolicy.py script
  We can use the servicepolicy.py script to perform operations on service policies from the command line, such as creating service policies, removing service policies, and editing transaction classes.

• (dist)(zos) Intelligent Management: routing and service policies
  Two types of policies are applied to a request: routing and service. We can create routing policies for HTTP and SOAP requests, and we can create service policies for HTTP, IIOP, SOAP, JMS, and SIP requests. Additionally, work classes can contain classification rules for both policy types with the exception of JMS. Classification rules are not supported for JMS work classes.

• Configure service policies without response time goals
  Configure service policies without response time goals when multiple service policies are configured and the response time goals cannot be accurately determined for any of the service policies, or when there might be occasional long-running or stuck requests.

Related concepts

Overview of work classes

Work class types

Related tasks

Configure the autonomic request flow manager

Intelligent Management: routing and service policies

Intelligent Management: administrative roles and privileges

Related information:

Intelligent Management: service policy custom properties

Intelligent Management: rules for ODR routing policy administrative tasks

Intelligent Management: rules for ODR service policy administrative tasks

Configure the visualization data service