The Workload Manager features can be used to ensure more consistent 
response times for users.  For example, you might need to meet a specific 
Service Level Agreement (SLA) with users, minimize performance 
complaints, or facilitate capacity planning.  The grouping of processes 
into workgroups gives the system manager the ability to partition the 
system into groups with similar needs.  Altering the scheduling 
characteristics of those workgroups provides the control over CPU
access, which in turn helps determine response time.
  | 
  |   | 
  | 
  | CAUTION: It is critical to understand that CPU access is just one component of
response time.  The Workload Manager can help handle this aspect, 
but cannot handle problems with disk access speeds, memory constraints, 
network latency and availability, or the other components of response time. | 
  | 
  |   | 
  | 
In controlling CPU access, you can either control the workgroup needing 
the consistent response times, or identify the other workgroup(s) whose
behavior leads to inconsistent response times and control those workgroups.
To control a single workgroup | 
  | 
In handling a single workgroup, you can change the base and limit priorities, 
change the rate of priority decay (by adjusting the quantum), or assign CPU 
minimum and/or maximum percentages.  Which control is most effective
depends on the characteristics of the processes you want to control.  It may be
the case that placing the workgroup at priorities 160-170 gives consistent
1-second response time to those users.   Alternatively, you may need to set
a minimum CPU percentage of 20% to the workgroup in order to ensure
1-second response time.
To control other workgroups | 
  | 
If processes in one workgroup (workgroup_1) are experiencing 
inconsistent response times, it may be due to the influences of another 
workgroup (workgroup_2).  For example, workgroup_2 
may be set to a higher priority and contain processes 
that perform long transactions, leading to increased response times for 
the processes in workgroup_1.  To handle the situation, you can:
Move the processes in workgroup_2 that perform long transactions 
to a lower-priority workgroup.
Move the entire workgroup (workgroup_2) to a lower priority.
set a CPU maximum for workgroup_2, restricting the amount of CPU 
it can consume.
If it is a single process that is disrupting the response times of others, 
move it to a lower-priority workgroup.