+

Search Tips   |   Advanced Search

(zos)

Configure an application server to use the WLM even distribution of HTTP requests function

By configuring the application server to use the WLM even distribution of HTTP requests function, HTTP session objects can be evenly distributed by workload management (WLM) to the servants in our configuration. Use this task to distribute HTTP session objects in a round-robin manner among several servants instead of the normal situation where there is a servant affinity, and HTTP session objects reside in one or two servants.

Your application server should be running on a z/OS system that is at Version 1.4 or later. Because you are distributing HTTP requests among multiple servants in this task, you should also have multiple servants enabled to use this function. See the topic about enabling multiple servants on z/OS for more information.

Use this task if the application server is experiencing problems with the default workload distribution strategy. The default workload distribution strategy uses a hot servant for running requests that create HTTP session objects. Consider configuring the product and the z/OS Workload Manager to distribute the HTTP session objects in a round-robin manner in the following conditions:

For more background about when to use this task, see the information about WLM even distribution of HTTP requests.

  1. In the console, set the WLMStatefulSession property to true.

    1. Expand Servers > Server Types and click WebSphere application servers.

    2. Click the name of the server to use the WLM even distribution of HTTP requests function.

    3. Under Server Infrastructure, expand Administration and click Administration services.

    4. Under Additional properties, click Custom properties.

    5. Click WLMStatefulSession and change the value in the Value field to true if it is currently set to false. If the custom property does not exist, click New, add WLMStatefulSession to the Name field, and add true to the Value field.

    6. Click Apply and then click Save to save the changes to the master configuration.

  2. Set the optimal minimum and maximum number of servants for the workload. Set the minimum and maximum number of servants to handle the expected number of HTTP sessions with affinity. The minimum number of servants should be greater than one. If, for example, you expect 15,000 HTTP session objects are established in the server during the day, then you might set the minimum number of servants to some value larger than one. The minimum of servants is dependent upon the size and number of the HTTP session objects. However, the initial arrival rate of client requests establishing the affinity, the frequency of client interaction, the duration of each client interaction (CPU time and thread occupancy time), and the length of time that the HTTP session object is maintained also need to be considered when establishing the minimum value for the number of servants.

    1. To set the number of servants, click Servers > Server Types > WebSphere application servers server_name Server instance.

    2. Set the minimum and maximum number of servants.

    3. Click Save and synchronize to apply the changes.

  3. If we use a classification mapping file instead of a common workload classification document, and specified more than one transaction class on a mapping rule for the managed round robin support that the product provides, you should remove this section from the classification mapping file. You should use a common workload classification document instead of a classification mapping file because support for the classification mapping file is deprecated. However if you use a classification mapping file, and that file contains a line similar to the following:

      TransClassMap *:8080 /Dynacache1Web1/Servlet1 TCLASS1 TCLASS2 TCLASS3

    Modify this line such that it specifies only one transaction class. For example, you might change the preceding line to the following line:

      TransClassMap *:8080 /Dynacache1Web1/Servlet1 TCLASS1

    You also must update the z/OS workload manager policy to remove the extra service classes that are only required fi to use the managed round robin support that the product provides. Following is an example of how to remove the extra service classes:

      Subsystem-Type Xref Notes Options Help -------------------------------------------------------------------------- Modify Rules for the Subsystem Type Row 9 to 16 of 16 Command ===> ____________________________________________ SCROLL ===> CSR Subsystem Type . : CB Fold qualifier names? Y (Y or N) Description . . . Component Broker requests Action codes: A=After C=Copy M=Move I=Insert rule B=Before D=Delete row R=Repeat IS=Insert Sub-rule More ===> --------Qualifier-------- -------Class-------- Action Type Name Start Service Report DEFAULTS: AZAMS1 RBBDEFLT ____ 1 CN AZSR01 ___ AZAMS1 RAZAMS1 ____ 2 TC TCLASS1 ___ AZAMS1 RAZAMS1 _d__ 2 TC TCLASS2 ___ AZAMS2 RAZAMS1 _d__ 2 TC TCLASS3 ___ AZAMS3 RAZAMS1 ____ 1 CN AZSR02 ___ AZAMS2 RAZAMS2 ____ 1 CN AZSR02 ___ AZAMS3 RAZAMS3 ****************************** BOTTOM OF DATA ******************************

  4. Restart the server. The server recognizes the WLMStatefulSession property after it is restarted.


Results

The application server uses the WLM even distribution of HTTP requests function to handle its workload instead of showing affinity to a certain servant.


What to do next

See the topic about detecting and handling problems with runtime components for information on how to handle problems with server clusters and workloads.


Subtopics


Related tasks

  • Enable multiple servants on z/OS
  • Detecting and handling problems with runtime components