Defining service classes and performance goals
A service class is a named group of work within a
workload with the following similar performance characteristics:
- Performance goals
- Resource requirements
- Business importance to the installation
Workload management manages a service class period as a single entity when allocating resources to meet performance goals. A service class can be associated with only one workload. You can define up to 100 service classes.
You can assign the following kinds of performance goals to service classes: average response time, response time with percentile, velocity, and discretionary. You assign an importance level to the performance goal. Importance indicates how vital it is to the installation that the performance goal be met relative to other goals.
Because some work has variable resource requirements, workload management provides performance periods where you specify a series of varying goals and importances. You can define up to eight performance periods for each service class. You can also assign a service class to a resource group if its CPU service must be either protected or limited.
This information explains the parts of a service class, how to define performance goals, and how to use performance periods.
| Defining service classes and performance goals |
|---|
|
- Name (required)
- Eight characters describing the service class. Service class names must be unique within a service definition.
- Description (optional)
- An area of 32 characters describing the service class. The descriptive text is available to performance monitors for reporting.
- Workload (required)
- The name of the workload associated with the service class. You can associate only one workload per service class in a service definition. The workload must have been previously defined.
- Resource Group (optional)
- The resource group name associated with this service class. You can assign only one resource group per service class in a service policy. You can override the resource group assigned to a service class in each service policy. For more information about resource groups, see Defining resource groups.
- Performance Period
- A performance goal, importance, and duration for a service class. You set up multiple performance periods for work that has changing performance requirements as work consumes more and more resources. You can specify up to eight performance periods.
- Duration
- Specifies the length of the period in service units. For a definition of service units, see Defining service coefficients and options. If the work included in this service class period does not complete when the number of service units have been used, the work moves into the next performance period. You do not specify a duration on the last defined period.
- Response Time
- The expected amount of time required to complete the work submitted
under the service class, in milliseconds, seconds, minutes and hours.
Specify either an average response time, or response time with a percentile.
Percentile is the percentage of work in that period that should complete
within the response time. Percentile must be a whole number. You must
specify a system response time goal, not “end-to-end”. That is, workload
management does not control all aspects of system performance, so
response time scope is confined to the time workload management has control
of the work. This time includes the time the work is using or waiting
for CPU, storage, or I/O service. Note: Workload management does not delay work, or limit it, to achieve the response time goal when extra processing capacity exists.
- Velocity
- A measure of how fast work should run when ready, without being delayed for WLM-managed resources. Velocity is a percentage from 1 to 99. See Velocity formula for a description of the calculations needed to determine velocity.
- Discretionary
- Workload management defined goal. Associate this goal with work for which you do not have a specific performance goal. Work with a discretionary goal is run when excess resources are available.
- Importance
- The relative importance of the service class goal. Importance is a reflection of how important it is that the service class goal be achieved, Workload management uses importance only when work is not meeting its goal. Importance indicates the order in which work should receive resources when work is not achieving its goal. Importance is required for all goal types except discretionary. Importance applies on a performance period level and you can change importance from period to period. Importance is in five levels: 1 to 5, 1 being the highest importance.
- CPU Protection
- By specifying YES in the “CPU Critical” field when defining a service class, you ensure that work of lower importance will always have a lower dispatch priority. See Defining special protection options for critical work for more information.
- I/O Priority Group
- By specifying HIGH in the “I/O Priority Group” field when defining a service class, you ensure that work in this service class will always have a higher I/O priority than work in service classes assigned to I/O priority group NORMAL. SeeDefining special protection options for critical work for more information.
- Honor Priority
-
By specifying NO in the Honor Priority field, you explicitly prevent the overflow of specialty-engine-intensive work to standard processors. See Defining special protection options for critical work.
The values are:
- DEFAULT
- Current values of the IFAHONORPRIORITY and IIPHONORPRIORITY parameters in parmlib member IEAOPTxx are used when there is insufficient capacity on specialty engines (System z® Integrated Information Processors, or zIIPs, or System z Application Assist Processors, or zAAPs) for the workload demand in the service class. This is the default.
- NO
- Independent of the current value of the IFAHONORPRIORITY and IIPHONORPRIORITY parameters in parmlib member IEAOPTxx, work in this service class is not allowed to overflow to standard processors when there is insufficient capacity on specialty engines (System z Integrated Information Processors, or zIIPs, or System z Application Assist Processors, or zAAPs) for the workload demand in the service class. The only exception is if it is necessary to resolve contention for resources with standard processor work.
The Honor Priority option is insignificant for discretionary service classes since work that is classified to these service classes never gets help from standard processors.