You can use the administrative console to provide the job
control language (JCL) PROC name for the servant and the JCL Parm
for the servant and thereby set up a dynamic application environment.
Even if you set up a dynamic application environment, you must set
the WLM goals for your environment.
Proper WLM goals can significantly affect your application throughput.
The WebSphere® Application Server address spaces
should be given a fairly high priority. When setting the WLM goals
for your z/OS® system, you might want to:
- Classify location service daemons and controllers as SYSSTC or
high velocity.
- Use STC classification rules to classify velocity goals for application
servers.
Early in the life of the servant, or if you have set the
ManageNonEnclaveWork parameter in IEAOPTxxWLM to
yes:
- Java garbage collection runs under this classification. Java garbage
collection is a CPU and storage intensive process. If you set the
velocity goal too high garbage collection can consume more of your
system resources than desired. If your Java heap is correctly tuned,
garbage collection for each servant should run no more than 5% of
the time. Also, providing proper priority to garbage collection processing
is necessary since other work in the servant is stopped during much
of the time that garbage collection is running.
- JavaServer Page file compiles run under this classification.
If your system is configured to do these compiles at runtime, setting
the velocity goal too low can cause longer delays waiting for JavaServer
Page file compiles to complete.
If the ManageNonEnclaveWork parameter
in IEAOPTxxWLM is set to no, or is not specified,
most Java garbage collection and JavaServer Page compiles, that are
assigned to a servant for processing, are handled according to the
service class criteria established for that servant.
Application
work is classified under the work manager.
- Set achievable percentage response time goals.
For example,
a goal that 80% of the work will complete in .25 seconds is a typical
goal. Velocity goals for application work are not meaningful and should
be avoided.
- Make your goals multi-period.
This strategy might be useful
if you have distinctly short and long running transactions in the
same service class. On the other hand, it is usually better to filter
this work into a different service class if you can. Being in a different
service class will place the work in a different servant which allows
WLM much more latitude in managing the goals.
- Define unique WLM report classes for servant regions and for applications
running in your application environment. Defining unique WLM report
classes enables the resource measurement facility (RMF) to report
performance information with more granularity.
- Use the wlm_maximumSRCount=x and wlm_minimumSRCount=y variables to control the maximum and minimum number
of servants, if the WLM configuration is set to no limit.
To specify
values for these variables, in the administrative console, click Servers > Server Types > WebSphere application servers, and select
the appropriate application server.
Avoid trouble: If you specify a value for the
wlm_maximumSRCount variable, the value must be greater
than or equal to the number of service classes defined for this application
environment. If the value is less than the number of defined service
classes, timeouts might be caused because there is an insufficient
number of servants available.
gotcha
- Periodically review the results reported in the RMF Postprocessor
workload activity report:
- Transactions per second (not always the same as client tran rate)
- Average response times (and distribution of response times)
- CPU time used
- Percent response time associated with various delays
- Watch out for work that defaults to SYSOTHER. As stated in the
z/OS Information Center topic Subsystem-Specific Performance
Hints, work in subsystems that use enclaves can suffer performance
degradation if left unclassified in the service definition. If you
do not add classification rules for this work in your service definition,
it is automatically assigned to the SYSOTHER service class, which
has a discretionary goal.
- Watch for error message: BBOO0037E Function
IWMSRCRR failed with RC=8,REASON=00000868 occurring in a
control region.
Restriction: In considering workload management
(WLM) processing on your z/OS system with active WebSphere Application
Server address spaces, this message results when the number of servers
attempting to register to WLM has surpassed the maximum of 256. Specifically,
the 257th server (and subsequent servers) that attempt to register
with WLM will fail with this message. The 256 maximum is a fixed system
restriction and cannot be changed.