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.
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™ 2
Platform, Enterprise Edition (J2EE) 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 provide service policy alerting for persistent service policy violations
on a transaction class basis. See 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. See Configuring the autonomic request flow manager
for
instructions on enabling the admission control for CPU overload protection.
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.
Using 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.
- RTT of 2 times the service time:
- A tight percentile goal or PCT of 75% completing within the response
time specified (RTT)
- A loose percentile goal or PCT of 50% completing within the response
time specified (RTT)
- RTT of 3 times the service time: PCTs from 88% to 65%
- RTT of 4 times the service time: PCTs from 94% to 76%
- RTT of 5 times the service time: PCTs from 97% to 83%
- RTT of 6 times service time: PCTs from 99% to 88%
- RTT of 7 times the service time: PCTs from 99% to 92%
- RTT of 8 times the service time: PCTs from 99% to 94%
- 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.
- 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 Version 6.1
- 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, 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
will be issued unless the 85% (90% minus 5%) threshold
is not met.
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.
- 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.
- To create a work class for your service policy,
from the administrative console click Applications > Enterprise
Applications > application_name > Service Policies.
Select an existing service policy and for the request type, click 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 JavaServer Pages (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, you must create
the following two policies:
- Create a default SIP policy with the following values:
- Goal Type = Average Response Time
- Goal Value = 75 milliseconds
- Importance = High
- Create an INVITE policy with the following values:
- Goal Type = Average Response Time
- Goal Value = 75 milliseconds
- Importance = Low
- 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).
- The system automatically picks up any changes you make
to your service policy configuration. You do not need to restart any
servers when you update your service policies and work classes.