This topic describes how to use transaction classes to classify client workload for workload management. The workload is different WebSphere transactions targeted to separate servant regions, each with goals defined by appropriate service classes. Each transaction is dispatched in its own WLM enclave in a servant region process, and is managed according to the goals of its service class.
Before you begin
This topic describes steps to classify transaction workload as a way of managing the workload service objectives. You also need to define the service objectives (goals) for the service classes used. In addition, you must define the service objectives of the WebSphere Application Server for z/OS servers and your business application servers.
For more information
about defining service objectives (goals) for each service class, see the z/OS
MVS Planning: Workload Management book, SA22-7602, for example at
http://publibz.boulder.ibm.com/epubs/pdf/iea2w131.pdf
,
or the z/OS WLM Web page at
http://www.ibm.com/servers/eserver/zseries/zos/wlm/
.
Why and when to perform this task
You can classify your WebSphere work using the WLM CB-type classification criteria:
Note: To get started, you do not need to define special classification rules and work qualifiers, but you may want to do this for your production system.
To classify work using server and userid criteria, you use a combination of the WLM Workload Classification rules in the WLM ISPF dialog panels. For more information about defining WLM Classification rules, see Workload management (WLM) and its related article that includes an example of classification rules.
To classify work using transaction classes, you define and use transaction class mappings, as described in this task. The steps to classify work using transaction classes are:
Steps for this task
Note: This file must be in ASCII format.
TransClassMap host:port uritemplate tclass
Note: In the host or port fields, you can use wildcard characters only for the entire field as shown in the following example.
This syntax is the same syntax as for WebSphere Application Server for z/OS Version 4.0.1. For more information about this syntax, see Transaction class mapping file entries.
TransClassMap wsc4.washington.ibm.com:9080 /MyIVT/index.* TCLMYIVT TransClassMap wsc4.washington.ibm.com:9080 /MyIVT/ivtejb TCLMYEJB TransClassMap wsc4.washington.ibm.com:* /SuperSnoop* TCLSNOOP TransClassMap wsc4.washington.ibm.com:* /ssb/* TCLSSB TransClassMap *:* /admin* TCLADMIN
This sets the following variable in the server's was.env file:
protocol_http_transport_class_mapping_file=/wasconfig/t5was/MyTrMapFile.txt
Example
The following table shows classification rules for CB-type work in which the default service class is WSMED and has a reporting class of RWSDEFLT. Work run in the WSPROD WebSphere server is classified as WSMED with a reporting class of RWSPROD, unless it has a transaction class of TCLASS1, TCLASS2, or TCLASS2 assigned through the transaction class mapping file below.
Qualifier Qualifier Start Service Report # type name position Class Class - --------- -------- -------- -------- -------- Default: WSMED RWSDEFLT 1 CN WSPROD 1 WSMED RWSPROD 2 . TC . TCLASS1 WSFAST RWSPRD1 2 . TC . TCLASS2 WSMED RWSPRD2 2 . TC . TCLASS5 WSSLOW RWSPRD5 1 CN WSTEST 1 WSSLOW RTSTEST 2 . UI . USER1 WSMED RTSTSTU2 2 . TC . TCLASS5 WSSLOW RTSTST5
The following table shows how work can be assigned a transaction class based on its host name, port number, or URI. For example, a web request of http://ibm.com:80/Webap1/myservlet handled by the WSPROD server would be assigned a transaction class of TCLASS1, a service class of WSFAST, and a reporting class of RWSPRD1 by the classification rules shown above.
TransClassMap www.ibm.com:80 /Webap1/myservlet TCLASS1 TransClassMap www.ibm.com:* /Webap1/myservlet TCLASS2 TransClassMap *:443 * TCLASS3 TransClassMap *:* /Webap1/myservlet TCLASS4 TransClassMap www.ibm.com:* /Webap5/* TCLASS5 TransClassMap * * TCLASS6