By configuring your 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 your configuration. You can
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.
Before you begin
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
Enabling multiple servants on z/OS for more information.
About this task
Use this task if your 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 WebSphere Application Server and the z/OS Workload
Manager to distribute your HTTP session objects in a round-robin manner in
the following conditions:
- HTTP session objects in memory are used, causing dispatching affinities.
- The HTTP sessions in memory last for many hours or days.
- A large number of clients with HTTP session objects must be kept in memory.
- The loss of a session object is disruptive to the client or server.
- There is a large amount of time between requests that create HTTP sessions.
For more background about when to use this task, see
WLM even distribution of HTTP requests.
Procedure
- In the administrative console, set the WLMStatefulSession property
to true.
- Click Servers > Applications servers, and then select
the server for which you want to use the WLM even distribution of HTTP requests
function.
- Under Server Infrastructure, click Administration > Administration
Services, and then, under Additional Properties, click Custom Properties.
- Click WLMStatefulSession and change the value in the
Value field to true if it is currently set to false.
The default value for this property is false for
an application server and true for a deployment manager.
- Click Apply and then click Save and Synchronize to
update your changes.
- 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.
- To set the number of servants, click Servers > Application
servers > server_name > Server instance.
- Set the minimum and maximum number of servants.
- Click Save and synchronize to apply the changes.
- If you have set up your classification mapping
file to specify more than one transaction class on a mapping rule for WebSphere
Application Server managed round robin support, you should remove this section
from your classification mapping file. For example, if you have
a line in your classification mapping file like the following:
TransClassMap *:8080 /Dynacache1Web1/Servlet1 TCLASS1 TCLASS2 TCLASS3
Modify this line of the classification mapping file 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 were only necessary to get WebSphere Application Server managed
round robin support. Following is an example of removing 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 ******************************
- 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.