Define a service policy

 

+

Search Tips   |   Advanced Search

 

Use service policies and 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

To create, modify, or remove service policies and transaction classes, have administrator or configurator administrative privileges.

To modify rules through the rule builder, have administrator privileges.

 

About this task

Each work request belongs to exactly one transaction class.

Each transaction class belongs to exactly one service policy.

Work classes are used to map incoming requests to transaction classes.

Each work class is attached to a J2EE application and a basic request feature:

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 provide service policy alerting for persistent service policy violations on a transaction class basis.

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.

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.

Use the service time, or response time of a single request or small number of requests on a non-loaded or lightly loaded system, that is, how long a single request takes on a non-loaded system, then constructing service policies where the response times are less than that will never result in additional instances being started (either average or percentile response time goals). The system will determine that starting additional instances will not improve the capability of meeting the goal. For percentile goals, ARFM and APC are very sensitive to the relationship between the parameters in question: the Response Time Target (RTT), or the Goal Value, and Percentile Threshold (PCT), or the Goal Percentage.

Following are some sample ranges starting with the response time, increasing to the RTT of 2, 3, 4 times (and so on) of the single request service time. Low and high end PCTs are then provided. These can vary to some degree from application to application, but these ranges are given as a starting point for fine-tuning your service policies for you specific needs For percentile goals, the ARFM and the APC are aware of the relationship between the parameters, RTT, or the goal value, and PCT, or the goal percentage.

 

Procedure

  1. From the administrative console click Operational policies > Service Policy. You 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 your new service policy. The goal type can be either discretionary, average response time, percentile response time, or completion 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.

    • Completion time goals specify the maximum amount of time (minutes) that is acceptable for a job to complete and still maintain the level of service that the service policy implies. Completion time is queue time plus execution time of a grid job. Completion time combined with the importance associated with service policies ensure that important jobs are dispatched first. All jobs are dispatched immediately if there is capacity. This completion time goal type is used only when there are more jobs than what can be processed immediately. The attempt is to get the job completed by completion time, and not just get dispatched. The application placement controller (APC) assesses the historical date for a job and dispatches the job based on that data. For example, if completion time is set to 30 minutes, and from historical date the APC knows that the job takes 30 minutes to complete, then this job will be dispatched right away. The class of a job is important when predicting the performance characteristics of batch jobs. The APC design is such that the system assumes that a job in class A will have, generally, the same performance characteristics as other jobs in class A. Queue time is deprecated in WebSphere® Virtual Enterprise V6.1

  3. Optional: If you select a goal type of average response time, percentile response time or completion 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, note that the options for importance vary from lowest to highest. Some planning is essential to select the right 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 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 that is 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 below the defined goals, and continually adjusts to achieve the most balanced result. When you associate an importance with the service policy, note that the options for importance vary from lowest to highest. Some planning is essential to select the right importance value, because negative results can occur if all work is rated as highest. To define a policy violation, specify the Goal delta percentage and the Time period value:

    • In the Goal delta value field, type an integer type an integer that indicates the percentage of request below 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, the service policy states if 90% of the requests coming in for this service policy are serviced in 1 second, then this policy is being satisfied. Otherwise, the service policy is being breached. The Goal Delta Percentage is 5%, so if the service policy is violated by 5% (<85%), then this criteria is met. If it is violated more than 5%, the service policy is being breached. The Time Period Value is 5 seconds, which means that the service policy must only service less than 85% of the requests intended for it for a period of 5 seconds, and if it goes over 85%, then there is a breach. .
    Table 1. Percentile response time example
    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 completion time, type a goal value and associate an importance with the service policy. For the goal value, type the maximum allowable 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, note that the options for importance vary from lowest to highest. Some planning is essential to select the right importance value, because negative results can occur if all work is rated as highest. This rating can create a bottleneck within the environment.

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

  5. To create a work class for your service policy, from the administrative console click...

    Applications | Enterprise Applications | application_name | Service Policies | service_policy | New

    To create a new 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 new 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 new 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 new 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, first create 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).

 

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.

 

Related concepts

Overview of work classes
Work class types

 

Related reference

Service policy custom properties
Routing and service policies
Administrative roles and privileges
Configure the autonomic request flow manager
SIP rules for ODR service policy administrative tasks
SIP rules for ODR routing policy administrative tasks