Address space management for work requests
The product propagates the performance context of work requests by using workload management (WLM) enclaves. Each transaction has its own enclave and is managed according to its service class.
The controller of a server, which workload management views as a queue manager, uses the enclave associated with a client request to manage the priority of the work. If the work has a high priority, workload management can direct the work to a high-priority servant in the server. If the work has a low priority, workload management can direct the work to a low-priority servant. The effect is to partition the work according to priority within the same server.
Enclaves can originate in several ways:
- The product uses its own set of rules to create an enclave for a client request from the network.
- Some subsystems, such as the IBM HTTP Sever, create enclaves and pass them to the application server, which, in turn, passes the enclaves on.
- The product treats batch jobs as if they were remote clients.
To communicate the performance context to workload management, you must classify the workloads in the system according to the following work qualifiers.
and corresponding product entities. The following table
Work qualifier abbreviation Work qualifier Corresponding product entity CN Collection name Cluster name UI User ID User ID under which work is running
For more information about classification rules and workload qualifiers, refer to the topic Classifying z/OS workload and the z/OS publication z/OS MVS™ Planning: Workload Management.
In addition to client workloads, you must consider the performance of the product run-time servers and the business application servers. In general, server controllers act as work routers, so they must have high priority. Because workload management starts and stops servants dynamically, servants also need high priority to be initialized quickly. After the servants are initialized, they run work according to the priority of the client enclave, so the servant priority that you assign has no significance after initialization.
In summary, use the following table to set the performance goals for each class:
rules. The following table describes workload management
If we are classifying the ... ... assign it to: Explanation Location service daemon SYSSTC or a high velocity, high importance STC The system treats it as a started task, and it must route work requests quickly. Controller SYSSTC or a high velocity, high importance STC A controller must route work quickly, but you must balance the priority of the business application server with other work in the system. Servant A lower velocity and importance STC than the controller The servant should be assigned a lower goal than the controller because the servant is less important than the controller.
Avoid trouble: This goal only applies during servant startup. After a server starts processing requests, it is managed according to the goals of the work being processed in the servant.gotcha
Application environment Use the CB classification rules, the percentage response time goal, for example 80% of transactions complete in .25 seconds.
Client applications Assuming a long-running application, a velocity goal should be used that is relative to other work on the system.
Classifying z/OS workload