|
Problem(Abstract) |
If the goals set within Workload Mananger (WLM) on z/OS®
are too aggressive, poor performance may result. This technote describes
the current Best Practice for classifying WebSphere® Application Server
work in WLM. |
|
|
|
Cause |
If WLM is confronted with a goal that is impossible to
meet then WLM will bypass the goal in favor of the rest of the z/OS
system. If WLM attempts to meet an impossible goal the entire system could
suffer in an attempt to satisfy one portion of the total work. |
|
|
Resolving the
problem |
The following describes the different types of work when
running WebSphere Application Server on z/OS:
1) The address spaces need enough resource to start and process normal
operating system functions. Start up is important and an aggressive
Velocity goal or SYSSTC setting is recommended. Typically,
the address spaces are given a minimum of importance=2 and velocity=60
(relative to the rest of your velocity goals this should be high).
2) For Garbage Collection and JSP™ compiles at run time the address spaces
should be placed into an aggressive STC classification. Typically, the
address spaces are given a minimum importance=2 and velocity= 60 (relative
to the rest of your velocity goals this should be high).
3) The Post Installer shell script and any other USS® utility running from
a submitted job will use BPXBATCH. For automatically running the post
installer, classify BPXBATCH using the OMVS classification rules within
your WLM policy. If BPXBATCH work defaults to discretionary, shell scripts
executed from a z/OS job will most likely run slow.
4) J2EE application work is run under the CB workload and should be given
a Response Time with Percentile goal. Percentage response time goal is
recommended. You should make your goals achievable.
Example: Goals that have 80% of the work that will complete in .25 seconds
is a typical goal.
The recommendation for Response Time with Percentile goal should not
be more aggressive than 90% of the work in .25 seconds. If you choose
99% of the work, then WLM will determine that an impossible goal is set
and sacrifice it for the rest of the system. The same holds true if you
choose .1 second . The same sacrifice may be chosen on an already
constrained system.
Provide a high velocity default service class for CB transactions (the
default is SYSOTHER). SYSOTHER will most likely be running at
Discretionary, which will provide a poor performing result for WebSphere
Application Server application work. Classify your work based on server
name, server instance name, User ID and transaction class.
Velocity goals for application work are not meaningful and should be
avoided.
5) If WebSphere Application Server depends on another sub-system like
DB2®, CICS®, WebSphere MQ® or any other loosely coupled server, it is
important to make the goals for all subsystems realistic. If the goals for
IMS® work are 50% of the work in 3 minutes and the goal for WebSphere
Application Server is 75% of the work in 3 seconds, WebSphere Application
Server will wait for processing from IMS and WLM will not make the goal
for WebSphere Application Server.
Finally, the WLM system programmer must work closely with the WebSphere
Application Server programmer. Communication is vital to having an
adequately performing system.
The following are links to these topics in the WebSphere Application
Server for z/OS Information Center. These links will provide additional
information for configuring WLM to accommodate WebSphere Application
Server on z/OS:
http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rprf_tunezwlm.html
and
http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topic=/com.ibm.websphere.wbifz.doc/info/wbifz/ae/tins_postinstallapp.html |
|
|
|
|
|
|