Running HATS applications on a z Systems platform

On a z Systems platform platform, setting the Workload Profile parameter to LONGWAIT is important for application processing that involves sending or receiving information across a network. The LONGWAIT setting allows each servant region to have a pool of 40 threads to handle concurrent HATS requests. The default pool size is 4 threads. This parameter setting is important when sizing the number of servant regions.

Find this parameter by navigating to Servers>Application Servers>servername>ORB Service>Advanced Settings>Workload Profile, where servername represents the name of your server.

On a z Systems platform platform, HATS applications run in the WebSphere Application Server servant regions. If you specify LONGWAIT for the Workload Profile parameter, each servant region has a pool of 40 threads, . By default, there is only one servant region to handle all concurrent HATS requests. You can increase the number of servant regions to handle your application workload by setting the following parameters. In the parameter locations listed below, servername represents the name of your server.

Multiple Instances Enabled

Select this check box to allow multiple servant regions to be initialized.

Find this parameter by navigating to Servers>Application Servers>servername>Server Instance>Multiple Instances Enabled.

Minimum Number of Instances

This parameter specifies the number of servant regions to be kept running once servant regions are initialized during WebSphere Application Server start up. Use this parameter when the response time for the workload requires that several servant regions are needed to be ready to process work. The default for J2EE servers is 1. The maximum value is 20.

Find this parameter by navigating to Servers>Application Servers>servername>Server Instance>Minimum Number of Instances.

Maximum Number of Instances

This parameter specifies the total number of servant regions allowed by workload management to run concurrently in the server's application environment. Set this value to limit the number of servant regions created by workload management for a server. The default is zero, which means there is no limit.

Find this parameter by navigating to Servers>Application Servers>servername>Server Instance>Maximum Number of Instances.

The Java heap parameters influence performance and the behavior of garbage collection. Larger heap sizes take longer to fill and longer to garbage collect. With large heap sizes, applications run longer before a garbage collection occurs, and it takes a longer time to perform the garbage collection. You should monitor garbage collection and adjust your heap sizes so that no more than 15% of the total execution time is spent in garbage collection. A good way to see what is going on with garbage collection is to use the JVM's verbose garbage collection option which is enabled by adding -verbosegc to the JVM arguments. Verbosegc provides an output file that gives the date and time of each garbage collection cycle. From the output file, you can calculate how much of the total execution time is spent in garbage collection.

On a z Systems platform platform, there is a JVM in both the controller and the servant region. Usually, the JVM in the controller does not need to be tuned. This information applies to the JVM in the servant region.

There are two JVM parameters that specify how much memory is allocated for the JVM heap. The settings of these two parameters will affect the performance of your HATS applications. In the parameter locations listed below, servername represents the name of your server.

Initial Heap Size

This parameter specifies how much memory is allocated for the heap when the JVM starts. Properly tuning this parameter reduces the overhead of garbage collection, improving server response time and throughput. For most HATS applications, the default setting for this option is too low, resulting in a high number of minor garbage collections. This setting will be workload specific, but it should be at least 512 MB. If the heap size changes frequently, you might improve performance if you specify the same value for the initial and maximum heap parameters.

Find this parameter by navigating to Servers>Application Servers>servername>Process Definitions>JVM>Initial Heap Size.

Maximum Heap Size

This parameter specifies the maximum heap size the Java interpreter will use for dynamically allocated objects and arrays. Properly tuning this parameter also reduces the overhead of garbage collection, improving server response time and throughput. For most HATS applications, the default setting for this option is too low, resulting in a high number of minor garbage collections. This setting will be workload specific, but it should be at least 768 MB.

Find this parameter by navigating to Servers>Application Servers>servername>Process Definitions>JVM>Max Heap Size.

The JVM memory management function, or garbage collection, provides one of the biggest opportunities for improving JVM performance.

Garbage collection should normally consume from 2% to 5% of the total execution of a properly functioning application. It takes monitoring to understand the effects of garbage collection.

If you have pause time problems which are denoted by erratic application response times which are caused by normal garbage collection, you should set -Xgcpolicy=optavgpause.

In the Manage WebSphere Variables section of the WebSphere administrative console, navigate to Servers>Application Servers>servername>Custom Properties and add the variables listed below:

1. protocol_http_tcp_no_delay =1 (for non-secure connections)
2. protocol_https_tcp_no_delay =1 (for secure connections)
3. protocol_http_max_persist request=1
4. protocol_http_timeout_input=0
5. protocol_http_timeout_output=0
6. protocol_http_timeout_persistentSession=0
7. wlm_stateful_session_placement_on=1