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™ 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.
You can measure
the average response time for an application by following this procedure:
- 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 .
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
- From the administrative console click . 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, 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.
- Optional: If you 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
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 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.
Table 1. Percentile response time exampleDescription |
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.
- 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.
- To create a work class for your service policy, from the
administrative console click . 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 JavaServer Pages (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, 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.