Have You Enabled WLM in your WebSphere Liberty Server?
Do you have a WebSphere Liberty Server running on z/OS? If so, is it WLM enabled?
What is WLM you ask? WLM is the Workload Manager, it is a component of z/OS that is used for categorizing, prioritizing, and routing work. In this blog post we will have a short summary of WLM and how to enable WebSphere Liberty to take advantage of it and, why you would want to do this.
What is WLM?
WLM allows the System Programmer to define classifications and goals that help meet service level agreements, for example, allocating available resources for a given workload so it has the best opportunity to complete 98 percent of its requests within a second.
The process of defining the performance goals is done using a service class. The service class groups work with similar performance goals, business importance and resource requirements. The service class can additionally be broken down by time periods. This allows the performance goals of the service class to change over time. A service class can have different types of goals. It can have a goal of average response time. Which means the work in the service class will receive enough resources to meet an average response time of say 0.5 seconds. Additional goals are average response time with percentage. This is the same as average response time with the additional constraint of the percentage of work that should meet the response time goal. Velocity, which the defines the maximum amount of time work should be queued and discretionary, which defines work that will be done when resources are available. More information on service classes can be found here.
WLM also provides reporting classes. These allow the further breakdown of service classes into subsets to get specific information about the resources used by a subset of a specific workload dispatched using a specific service class. More information about reporting classes can be found here.
Assignment of service and reporting classes is done with Subsystem type (always ‘CB’ for WebSphere servers), Collection Name and Transaction Class. A Collection Name is an 8-character string and a type “CN” that is used to map service and reporting classes to a workload. A Transaction Class is an 8-character string and a type of “TC’ that is used to map service and reporting classes to a workload. Collection Names and Transaction Classes can be stand alone or nested under each other giving some additional flexibility when configuring WLM. We will go into this a bit deeper when discussing how WebSphere Liberty is configured to use WLM.
There are several other dimensions by which WLM can be configured but these are the only ones WebSphere Liberty servers use. Additional information on WLM can be found here.
Enabling the WebSphere Liberty workload to use WLM provides the ability to ensure that in a constrained environment the most important work receives the needed resources. It also provides detailed reporting of the resources consumed for different requests coming into the WebSphere Liberty Server. When a server is not enabled WLM has no visibility to the begin/end of requests being processed by the server and therefore has no ability to manage or report on that activity. The server will just be managed as a single process.
Configuring WebSphere Liberty to Use WLM
WebSphere Liberty by default comes with WLM disabled. Enabling WLM will take a few steps.
First you need to enable the feature by adding the following to the featureManager section of the server.xml:
Next you will need to notify WLM on how you would like work classified. This is done using the wlmClassification XML tag:
<httpClassification transactionClass=”CLASS001” resource=”/daytrader/*” />
In the above XML http requests from the context root daytrader will be assigned to the WLM transaction class CLASS001. Any request to the server that is not under the daytrader context root will not be visible to WLM. If you want to make sure all work that runs in the server is captured by WLM you can add a default classification that will capture the orphans.
<httpClassification transactionClass=”CLASS001” resource=”/daytrader/*” />
<httpClassification transactionClass=”WLPDFLT” />
In the above XML all http requests that are not found under the context root of daytrader will be assigned the WLM transaction class of WLPDFLT thereby ensuring all http requests coming to the server will be managed and reported on by WLM.
You can use WLM classification for http and MDB requests. MDB requests use the jmsActivationSpec id as the resource to be classified. Here is an example:
<mdbClassification transactionClass="CLASMDB1" jmsActivationSpec="Banking/personal/deposit"/>
More information on configuring http and MDB requests to use WLM can be found here.
As mentioned in the WLM section the service and reporting classes can be assigned via a collection name as well. The collection name by default is mapped to the directory name under which the server.xml for the server is found. This can present an issue since the directory name can be longer than 8 characters which for the sake of clarity and simplicity is the maximum recommended length a Collection Name should have. This can be handled in a few different ways. You can set the directory name length to a maximum of 8 characters. You could use a wildcard at the end of the Collection Name in WLM (this can cause multiple servers to map to the same collection name depending on server naming conventions) or you can specify the Collection Name for the server in the server.xml like so:
<zosWorkloadManager collectionName=”MYSERVER” />
The collectionName for the server should be keep to a max of 8 characters.
In WLM you can nest Transaction Classes under Collection Names. This provides a way to restrict transaction classes to a particular server or set of servers. You can also nest Collection Names under Transaction Classes this allows you to specify the same Transaction Class for a particular request type with the exception of those requests going to a high-priority server which can have a better response time goal.
Accessing WLM requires authorization. This can be done by starting an Angel and authorizing the server to the Angel and WLM. The entity allowing the server userid access to WLM is bbg.authmod.bbgzsafm.zoswlm. For more information on configuring the Liberty Angel process go here.
You can also access WLM without configuring an Angel by giving the server userid access to the Facility class BPX.WLMSERVER. Note that using this method will not perform as well as using the Angel as each request to the server will need to verify access to WLM where this happens only once using the Angel method.
How Is it Going?
Once you have configured your server to use WLM you might want to know how everything is going. You can find this information in the Resource Measurement Facility (RMF) Workload Activity report. This will show on a service or reporting class basis how WLM is doing at meeting your defined goals.
Here is an example of a report for a given interval:
Some highlights from the above example. You can see the percent CPU utilization for general purpose processors for the interval under the heading TRANS-APPL%-----CP-, value 46.42. The next value under IIPCP/AAPCP, 46.18, represents the percent CPU Utilization that could have been run on a specialty processor during the interval. The value under IIP/AAP 70.04 represents the percent CPU utilization for work run on specialty processors for the interval.
For more information on the fields in the Workload Activity Report go here.
If you want to be able to make sure the applications you have running on your WebSphere Liberty server on z/OS receive the resources required and, want the ability to see where goals are being met (or missed) enable WLM in your Liberty server. The knowledge you gain will serve you well.
A more in depth look at WLM and WebSphere (both Traditional and Liberty) can be found in this white paper.