Strategi Performance Tuning

Product: Strategi
Modified Date:

The purpose of this document is to provide the necessary background required to improve the performance of various components of Strategi. For some installations, the default Strategi settings are sufficient to provide the expected levels of performance. On the other hand, there are situations where heavily loaded iSeries 400 installations and/or complex client connection methods are used. In these cases, a more detailed analysis is required to pinpoint the cause of performance degradation.

The most popular categories of performance tuning have been organized into sections allowing for a focused approach to resolving performance-related issues. Please note that references to Strategi objects assume that Strategi has been installed using the default library 'STRATEGI and default IFS path name '/STRATEGI'. Adjust any listed modifications appropriately to apply to your environment.

NOTE: all information and procedures discussed in this document should be analyzed carefully to ensure that changes to existing OS/400 job functions do not adversely affect other production jobs or services. The primary audience for this document is the iSeries 400 system operator(s) responsible for work management and performance tuning on the Strategi host system.

TCP/IP Tuning
Subsystem Management
Interactive Subsystem Configuration
Strategi Applet Performance
Strategi Webserving
Strategi High Speed Messaging (HSM)
Tracking File and History Cleanup Commands
References and Related Materials

TCP/IP Tuning

Since Strategi is a highly network-dependent application, any problems caused by faulty network hardware or improper TCP/IP configurations will directly affect all Strategi users. Assuming that all network hardware is operating properly, verifying that TCP/IP is properly configured on the Strategi host system is a good first step in improving overall performance-related issues.

Optimize TCP/IP MTU
In a TCP/IP network, a 'packet' is known as the smallest unit of data in a conversation between client and host. The maximum transmission unit (MTU) is the maximum amount of data transmitted in a TCP/IP packet. Some systems default MTU values to 576 bytes although Ethernet and token ring networks typically have respective MTU values of 1500 and 2000. This default setting will result in at least 900 bytes of unused (i.e. wasted) space per network transmission. To verify the MTU setting for the TCP/IP address that Strategi uses is optimally configured, the following sequence may be used from OS/400 command line:

==> CFGTCP -> option 1 -> option 5 (next to Strategi TCP/IP address)

It is common for TCP/IP interfaces to be created with MTU values of '*LIND' which causes the MTU to be set to the value specified on the line description used by the TCP/IP interface. If this is the case, the maximum frame size specified on the line description is the MTU of the interface.

The goal is to maximize the amount of data in each packet without exceeding the lowest MTU rating along the data path. It is recommended, that confirmation of MTU settings for other devices on the LAN/WAN be done before changes are made. Changing MTU values higher than the value completely supported by the LAN/WAN will cause packet fragmentation and performance degradation. For Internet-connected systems, standards have been created to require all Internet routers to support a MTU of at least 1500 bytes.

Optimize TCP/IP Buffer Sizes
TCP/IP buffers are used to store data sent and received during a connection between client and host. OS/400 default send/receive buffer sizes are set to 8 KB each. The recommended buffer size is 32 KB each and are changed using the CHGTCPA (Change TCP/IP Attributes) screen. Caution should be taken when increasing buffer sizes. Sizes greater than 32 KB will offer a slight increase in speed but a increased rate of buffer overruns which can increase data retransmissions. Any retransmission request will negatively impact overall TCP/IP performance.

Subsystem Management

The STRATEGI subsystem is responsible for servicing all types of Strategi client requests and peer system functions. When Strategi is active, current activity can be displayed or monitored using the WRKACTJOB and/or WRKSBS displays.

When Strategi host software is suspected as being a possible performance bottleneck, standard iSeries 400 performance tuning rules and guidelines will apply. The following steps may be followed to improve Strategi host software performance and should be followed in the order listed for simplicity sake. Upon completion of each step, be sure to note changes made and any increase/decrease in overall system performance so a complete history of actions taken and respective results are available for future reference. Please note that not every step may be required to achieve expected performance levels.

Step 1 - Verify OS/400 System Values
Verifying OS/400 system values that relate to storage and performance on the system is the first step which should be taken. Depending on particular OS/400 release level, the following system values may available which can have an impact on system performance.
QACTJOB             Initial number of active jobs
QADLACTJ            Additional active jobs
QADLTOTJ            Additional total jobs
QTOTJOB             Initial total number of jobs
QBASACTLVL*         Base storage pool activity level
QBASPOOL*           Base storage pool minimum size
QDYNPTYADJ          Dynamic priority adjustment
QDYNPTYSCD          Dynamic priority scheduler
QMAXACTLVL          Maximum activity level of the system
QMCHPOOL*           Machine storage pool size
QPRFADJ             Performance adjustment
QPRCMLTTSK          Processor multi-tasking
QQRYDEGREE          Parallel processing degree

* If automatic performance adjustment is used, many of the
system values above will be set automatically by the operating
system. In addition to system values, shared pools are subject
to automatic performance adjustment by the operating system.

Properly setting system values is always dependent on individual system configuration. Based on this, review each current system value setting and determine if modifications to current values are warranted for your particular environment.

Step 2 - Modify Strategi Subsystem Defaults
The Strategi subsystem is a "batch" subsystem which runs using storage allocated from the *BASE subsystem pool. All active job types within the subsystem will be either BCH (batch) or BCI (batch-immediate). Since Strategi runs in its own subsystem, there are associated *CLS (class) and *SBSD (subsystem description) objects in the Strategi library which govern system resource utilization. The default installation settings can be considered the "minimum" when it comes to the amount and priority of system resource used by Strategi when active.

The class which is used by every job entering the Strategi subsystem has the following settings by default.

Class . . . . . . . . . . . . . . . . . . . . . . :   STRATEGI
  Library . . . . . . . . . . . . . . . . . . . . :     STRATEGI
Run priority  . . . . . . . . . . . . . . . . . . :   30
Time slice in milliseconds  . . . . . . . . . . . :   1000
Eligible for purge  . . . . . . . . . . . . . . . :   *NO
Default wait time in seconds  . . . . . . . . . . :   30
Maximum CPU time in milliseconds  . . . . . . . . :   *NOMAX
Maximum temporary storage in megabytes  . . . . . :   *NOMAX
Maximum threads . . . . . . . . . . . . . . . . . :   *NOMAX
Text  . . . . . . . . . . . . . . . . . . . . . . :   Strategi Background Jobs
Determining the proper run priority is dependent on the goals behind the Strategi installation and the current priority and importance of existing jobs in the system. In most cases, the run priority of Strategi jobs should be as close as possible to the current priority used for interactive work on the system. For those situations where interactive performance is not a factor, changing run priority to enable Strategi host jobs to run at a higher priority than interactive work is an option. Changing settings other than run priority is not recommended as we have not found sufficient evidence of performance gain.

  • WRKACTJOB can be used to display current run priority, storage allocation and performance indicators of all jobs in the system by pressing F11 when using the display. Columns listing job storage pool, priority, CPU/DASD utilization and response times will be shown and are useful when tracking system utilization.
  • It is good practice to never set the priority of a job on a system to be higher than the priority of the system console. If a job priority is changed and the job starts to get into trouble and consume more system resource than expected, the system console can be used to sign on and terminate the job. On the other hand, if a job priority is higher than the priority of the system console and begins consuming all available system resource it may be difficult if not impossible to end the job without performing a IPL.
Step 3 - Allocate Storage Pools for Strategi Subsystem Use
As mentioned previously, the Strategi subsystem will allocate storage from the *BASE system pool by default. When troubleshooting subsystem performance issues, the iSeries 400 command WRKSYSSTS can be used to view system performance indicators such as fault/page rates and the number of threads (i.e., jobs) that go from active state to ineligible state due to unavailable system resources. To improve performance, the Strategi subsystem may be configured to use shared, private or a combination of both types of storage pools.

Shared Pool
A shared storage pool is a pool in which multiple subsystems can run jobs. You can specify 63 of the 64 shared storage pools that are defined on the system for use when creating subsystem descriptions (the machine pool is reserved for system use). Shared pools are either special or general; the machine pool and base pool are considered special shared pools, all other shared pools are considered general.

  • can be monitored and adjusted automatically by the system
  • the system may also adhere to minimums and maximums specified by the user to aid in controlling fault/page rates and pool storage size
  • may result in contention for system resource between subsystems
  • does not guarantee optimum performance in complex operation environments where various types of work are processed
  • difficult to view performance indicators relevant to the Strategi subsystem only
Private Pool
A private storage pool is a pool in which a single subsystem can run jobs. Private pools are pools of main storage that cannot be shared by multiple subsystems. A private pool, often simply referred to as a pool, contains a specified amount of storage to be used by only one subsystem. You can have as many as 62 private pools allocated for use in active subsystems.

  • contention for system resources among other subsystems systems is not present
  • specific main storage and pool requirements for the Strategi subsystem may be easily displayed or changed until performance levels improve to acceptable levels
  • is not controlled by system performance monitors
  • system operator must determine storage size and activity levels of storage pool
  • requires periodic review and possible modification to ensure storage pool is sufficient to maintain acceptable performance levels
  • unused storage will not be shared with other subsystems
Whenever possible, it is recommended that private storage pools are used instead of shared pools due to the benefits they offer. Although more operator action is needed, a private pool will help ensure that system resources required for consistent Strategi subsystem response times will be available, regardless of other activities present on the system.

One of the requirements for implementing private storage pools is the values specified for pool size and activity level must be determined by the system operator. If these values cannot be determined, the following table lists possible initial values to use.
Strategi System     Pool Size (MB)      Activity Level
*ENTRY                  4-8                  10
*GROWTH                 8-16                 10
*STRATEGIC              16-64                15
*ENTERPRISE             64-128               20-30
*GLOBAL                 128+                 30+

The storage pools that you define decrease the size of the base storage pool. The system does not allocate storage to a user pool if the amount of storage available to the base storage pool would be less than the minimum base pool size specified by the system value QBASPOOL. With respect to activation levels, if the activation level is too low, jobs/threads in the subsystem may go to ineligible state waiting for system resource. If activation levels are too high, excessive page faulting may occur.

Configuration Example - Private Storage Pool
For example purposes, we will illustrate how to configure Strategi to use a private storage pool. The following steps will modify the subsystem to use a 16 MB storage pool with an activation level of 15.


When the Strategi subsystem is started, a WRKSYSSTS display will show all active storage pools in the system as well as values for fault, page and transition rates of all system pools.
                            Work with System Status                    SEATTLE1
                                                             05/15/01  06:39:16
 % CPU used . . . . . . . :       79.0    System ASP . . . . . . . :    16.97 G
 % DB capability  . . . . :         .0    % system ASP used  . . . :    47.2715
 Elapsed time . . . . . . :   00:00:00    Total aux stg  . . . . . :    16.97 G
 Jobs in system . . . . . :       2103    Current unprotect used . :      670 M
 % perm addresses . . . . :       .007    Maximum unprotect  . . . :      671 M
 % temp addresses . . . . :       .013

 Sys      Pool   Reserved    Max  ----DB-----  --Non-DB---  Act-   Wait-  Act-
 Pool    Size M   Size M     Act  Fault Pages  Fault Pages  Wait   Inel   Inel
   1      65.33     34.13  +++++     .0    .0   13.0  13.0     .0     .0     .0
   2     158.41       .28    128     .0    .0    3.9   3.9  157.0     .0     .0
   3        .25       .00      1     .0    .0     .0    .0     .0     .0     .0
   4      16.00       .00     20     .0    .0    1.3  20.9     .0     .0     .0

 F21=Select assistance level
System pool 4 is the storage pool that has been dedicated to the Strategi subsystem. Once the storage pool has been established, storage pool sizes and activity levels must be confirmed as being sufficient to accommodate peak usage levels. The general idea can be summarized as follows.
  • typical load is placed on Strategi subsystem
  • performance indicators are monitored using WRKSYSSTS (F10 to update display)
  • if fault/page rates are high, the storage pool may be too low and should be gradually increased
  • if wait/act-Inel values are high, the activity level may be too low and should be gradually increased
  • if fault/page rates and wait/act-inel transitions are low this indicates that there is currently sufficient system resource available for the Strategi subsystem
  • process repeats until all performance indicators display reasonable performance levels
A common question is "how can I place a typical load on my system?" Here are a few options which may be helpful.
  1. If possible performance fluctuation during peak use hours is acceptable, the storage pool may be adjusted during this time, which will save any changed settings to the Strategi subsystem description. In other words, Strategi users may experience degraded performance temporarily (while storage or activity levels are adjusted) but all changes made manually will be the same used the next time the subsystem is started.
  2. Obtain server load testing software that can simulate a number of users repeatedly requesting Strategi resource. This is the method used by our Technical Services staff when attempting to establish initial storage pool settings. Configuring the load testing software to make multiple simultaneous requests for multiple users for a fixed period of time allows you to increase Strategi subsystem activity to see if storage pool adjustments need to be made. The section "References & Related Materials" has links to websites that provide free and licensed versions of various load testing software packages.
  3. For interactive sessions, starting multiple 5250 sessions will help simulate the number of users online. Similar to HTTP load testing, this will also increase Strategi subsystem resource requirements but will allow you to determine the effect of 5250 emulation on Strategi performance. The critical point to note is that all 5250 session activity should be simulated as close as possible to obtain true performance statistics. This can be done by using the macro function of the enhanced Strategi 5250 applet or writing test programs on the iSeries 400 which can be called when the user being simulated has signed on. The goal is to replicate user activity as closely as possible.
Due to each iSeries 400 system being different with respect to functions performed and available resource available to perform those functions, acceptable performance on one system may not be acceptable on another. Only through experimentation can the correct storage pool size and activity levels be set.

If abnormally high fault/page or transition values are evident, this may be an indicator of degraded subsystem performance. For example, each fault uses some of the cycles available in your main processor. As more faults occur, the processor uses more cycles. As your faults increase, the amount of disk I/O increases. If you have very few disk arms, these faults can cause your disk utilization to increase more rapidly than if you have many disk arms. As your disk arm utilization increases, the time required to process disk I/Os increases.

Adding storage not only reduces fault rates but lowers overall CPU utilization. Ideally, fault/page rates and transitions from wait/act-inel should be as close to zero as possible for the system pool that Strategi is configured to use.

Once initial performance levels are achieved for a typical load, monitoring of system resources and respective performance levels must be periodically checked to ensure that increases in system activity do not result in performance degradation. If this is the case, the storage pool size and/or activity level may need to be adjusted to maintain expected Strategi performance levels during periods of abnormally high system utilization.

Step 4 - Examine iSeries 400 Disk Status
Once the system has been properly tuned, use the WRKDSKSTS (Work with Disk Status) command to view current disk utilization on the system. When viewing the WRKDSKSTS display, observe the percent busy data. Each unit (actuator) should be less than 50% busy. If each unit is between 50% and 70% busy, you may experience variable response times. If each unit is more than 70% busy, you do not have enough actuators to provide good performance. The actuator is the device within an auxiliary storage device that moves the read and write heads. If you have a well-tuned system with actuators that exceed 50% busy, you should increase the number of disk actuators.

It is possible to experience inadequate performance even if only one actuator exceeds the 50% busy guideline. This may be caused by the placement of frequently used data on a single actuator. If this occurs on your system, use the ASP balance commands (STRASPBAL, TRCASPBAL). See the CL Reference (Abridged), SC41-5722-03 for information about the ASP balance commands.

iSeries 400 work management and system tuning can be a complex task depending on the number of users accessing the system and the expected performance levels required for functions being performed. In addition to the steps listed above, the following should be noted when troubleshooting subsystem performance issues.
  • heavy database I/O on the system can pose performance issues
  • use a private storage pool if possible
  • obtain additional system main storage if possible to allow larger system pool sizes
  • if disk utilization is high, consider obtaining more disk units to reduce the load on existing disk configuration
  • properly estimate/size Strategi resource requirements, if possible, to ensure the iSeries 400 will be capable of meeting performance expectations that your Strategi users will expect
  • higher batch CPW will result in quicker Strategi subsystem response times
Lastly, try to set realistic performance expectations with respect to current system performance capabilities. Attempting to tune a 9406-170 with batch/interactive CPW of 73/20 and 512MB of main storage to achieve the same response times for similar workloads as a 9406-270 with batch/interactive CPW of 950/50 and 1 GB of main storage is not a realistic expectation.

Interactive Subsystem Configuration

IBM recommends that only a certain number of devices be allocated to one interactive subsystem in order to help increase performance and prevent any device allocation problems at signon.

Please review the IBM Software Technical Document on IBM's website titled,
"Recommended Number of Devices Allocated to an Interactive Subsystem (200-300)"

Strategi Applet Performance

The Strategi client applet offers 5250 emulation to host systems running Strategi host software. The factors to be considered when troubleshooting performance issues in relation to 5250 emulation include the following:

Client Workstation Requirements
The following minimum system requirement should be considered the baseline for systems which will be using the Strategi 5250 client applet.
  • Pentium class or comparable CPU
  • 32 MB RAM (64 MB recommended)
  • Internet Explorer or Netscape Navigator Version 4.0+
  • Stable TCP/IP Connection to Strategi Host
Optimizing performance on the local workstation will ensure that the Strategi client applet is running in the fastest environment possible.

Client/Host TCP/IP Connection Speed
The connection speed (i.e., bandwidth) between Strategi client and host will directly affect emulation performance as well as general page serving. In most cases, larger available bandwidth relates to faster response times. A general rule is to maximize connection speeds at both client and server to promote overall network performance gains.

The important point to note is that the overall bandwidth available for client/server use is dictated by the slower of the client/server network connections. For example, if a Strategi host is attached to a T1 (1.5 MBPS) but all clients are using dialup connections at 56 KBPS, the effective bandwidth between client and server will be approximately 56 KBPS.

This analogy remains true regardless of which client/server connection is slower. For example, if the client is attached to a 100 MBIT network but the Strategi host only resides on a 10 MBIT network, the effective throughput between client and server will be the connection speed of the host (10 MBIT) since it is the slower of the two.

For LAN only users, client/server connection speed usually does not present a problem as they are both in some way attached to a LAN supporting throughput rates of 10 MBIT or greater. Additional information for troubleshooting network performance issues in mixed, client/server connection speed environments are listed below:
  • It is common for Strategi hosts to share Internet connections with other services particular to the organization. This can result in multiple web servers, mail servers, and FTP/TELNET servers all sharing the same access point. When this occurs, Strategi clients and host software may end up competing with other applications and servers for available network bandwidth. If this is a suspected cause of performance problems, the network administrator for the organization should obtain appropriate usage reports for the affected networks to determine bottlenecks and resolve appropriately.
  • Troubleshooting client/server connections can sometimes be done using the common TCP/IP utility 'ping' or 'traceroute'. There have been cases where poor applet performance has been pinned down to a faulty router or hub which was responsible for client/server connectivity. Using the ping/traceroute utility and examining packet loss from point to point between client and server can aid in determining possible network hardware problems. Under certain circumstances other software tools may be necessary as firewalls are often configured to refuse ICMP traffic due to the threat of denial of service attacks via ping floods. In this case, contact the network administrator responsible for the site. They should be able to offer other methods of network testing.
Firewall/Proxy Configurations
The use of firewalls is sometimes responsible for problems encountered when using the Strategi 5250 client applet. The client applet can integrate smoothly with existing security measures but how this is done is important when optimal performance is required.

Scenario 1 - HTTP Tunneling is Used
The HTTP Tunneling feature of Strategi was designed to offer 5250 emulation to clients who are located behind corporate firewalls where modification of firewall rules to allow outbound connections on the standard TCP port 43856 is not an option. In this case, the Strategi client applet can be configured to connect on TCP port 80, which is a more common allowable port on most firewalls. The downside of this type of connection is that emulation data (i.e., screens displayed) must be packaged into a HTTP request to be processed by Strategi. When the Strategi host receives the request, it must unpackage-process-packge-transit back to the client which must also unpackage before processing the received data stream. This additional overhead results in slower screen turnaround times which are noticeable on slower client connections. As a general rule, the tunneling feature of the applet should be made available to clients but not set for all users by securing it server side. Forcing all clients to tunnel will result in delayed screen transactions for all emulation clients. Configuring the Strategi client applet is done by modifying the HTML page that loads the applet. The applet code should have a parameter called 'http_tunnel' located within the applet tags. For example, the following statement will give the client the option to tunnel if connection on the standard TCP port fails:

<applet code="abljem.class" codebase="/applets" archive="abljem.jar">
<param name="http_tunnel" VALUE="fallback">

The other available parameter values include "NEVER" (never tunnel) and "ALWAYS" (always tunnel). If the value "NEVER" is used, every emulation client will attempt connection on the standard TCP port 43856. This can possibly deny service to those clients behind firewalls with strict access list rules as the tunneling feature will be disabled. If the value "ALWAYS" is used, all emulation clients will attempt to tunnel regardless of standard TCP port availability. As mentioned previously, this is not recommended for optimal client connection performance.

Scenario 2 - Firewall/Proxy Port or Connection Duration Restrictions
The standard port used by the emulation applet is TCP port 43856. When the applet is downloaded to the client workstation and starts, it attempts to make a TCP connection on this port back to the URL that served the applet (i.e., Strategi host). If this connection cannot be made and the fallback feature is enabled, the applet will attempt to connect on TCP port 80 instead. If the firewall is configured to restrict access on both TCP ports 80 and 43856, the applet will not be able to connect to the Strategi host. Ideally, firewall administrators should allow outbound connections on TCP port 43856 as this type of direct connection allows for the quickest screen transaction times.

There have also been reported cases where the emulation applet suddenly terminates after a certain period of time. After further investigation we found the most common causes to be inactivity monitors or connection timeout rules. Some Internet connections have monitoring software used to ensure that connections are not idle. Part of the problem with some of these monitors is that they have been designed to monitor activity on "common" Internet ports such as HTTP/FTP/TELNET/SMTP/POP3, etc. Since Strategi uses a port not common to other Internet applications, the monitoring software doesn't take this into consideration and drops the connection regardless of the emulation applet being active or not. To resolve this, the monitoring software must be configured properly or removed completely to ensure stable operation. Lastly, certain firewalls and proxies enforce connection timeout rules regardless of port activity. If this is the case, these rules must be modified to accommodate emulation applet traffic without timing out the connection and interrupting service.

Available Host System Resource
Although all jobs in the Strategi subsystem are batch job types, all emulation clients enter the system as interactive job types. Strategi host software manages the communication between the client and the virtual terminal device(s) being used. Understanding that Strategi host software may require not only batch but interactive resource as well is important when attempting to optimize performance or troubleshoot performance related issues. Refer to the Subsystem Management section for tips on optimizing Strategi host subsystem performance.

Strategi Webserving

One of the most critical performance issues for webservers is the ability to quickly service web page requests. Assuming that TCP/IP configuration and subsystem storage requirements have been optimized on the iSeries 400, the focus should be geared more towards overall website design. One point that is often overlooked is that webserver response time is not the only factor to be considered. The time it takes for the user's web browser to render the page once received must also be taken into account.

  1. Optimize web pages and their content (i.e., graphics, applets, etc.) for the shortest download time possible while retaining expected levels of presentation quality. For Intranet applications where all users are attached to a high speed LAN, this is usually not an issue. For Internet websites, assume that most users will connect using dialup modem speeds. If page presentation can be optimized for dialup connection speeds then you can be assured that the performance will be acceptable for higher bandwidth users.
  2. Try to limit complexity of entry pages (e.g., homepage.htm or index.htm) as the entry page is often used to establish first impression. The last thing you need is a slow performing entry page which may discourage your visitors from returning to your website.
  3. Always test your web pages using different browsers and versions. Although there are numerous browsers to choose from, Internet Explorer© and Netscape Navigator© should be mandatory test platforms for sites which are publicly accessible. Some browsers will render a page faster than others due to differences in browser design.
  4. Monitor network usage levels periodically to ensure current bandwidth availability efficiently accommodates your user base. If network throughput becomes saturated, system tuning and web page design become secondary performance issues until the bandwidth required to meet performance expectations is obtained.

High Speed Messaging

In general, websites which utilize High Speed Messaging (HSM) to deliver dynamic page content are still encouraged to follow the same design guidelines used to optimize static web page delivery. When HSM is used to populate a web page with dynamic content, the content is retrieved from a user designed server program. Given this, server design becomes important when attempting to reduce the time taken to serve a web page with dynamic content.

As an example, lets say that a web page is designed to use a HSM server named PRODUCTS to retrieve current inventory status for a number of items. When the HSM server is started it will run in the Strategi subsystem and be identified as job name 'X_PRODUCTS'. The sequence of events to send the HSM populated web page to the user is dependent on server design, but is similar to the following:
  1. User requests a web page to display a list of stock items
  2. Strategi middleware sees that this web page requires HSM processing and passes the request to HSM server PRODUCTS
  3. HSM server PRODUCTS performs all operations required to service the user request
  4. Strategi middleware receives data from HSM server PRODUCTS
  5. Strategi middleware sends web page containing content provided by HSM server PRODUCTS
When the goal is optimizing server response times with dynamic page content, step 3 is the area to focus on. The time taken for a HSM server to complete the processing required to return a reply and associated data will be added to the time required to ultimately serve the page.

Performance Monitoring
Enabling performance monitoring on the HSM server definition is one method for determining HSM server latency. The parameter PRFMON must be set to *YES and the server restarted before collection statistics can be reviewed.

Change HSM Server (CHGHSMSVR) Type choices, press Enter. Server Name . . . . . . . . . . SVRNAM > 'MOVIESVR' Interface Type . . . . . . . . . TYPE *SRVPGM Server Program . . . . . . . . . SVRPGM MVIE01 Library . . . . . . . . . . . SGIHSM01 Instances . . . . . . . . . . . INST 1 Autostart . . . . . . . . . . . AUTO *YES Text Description . . . . . . . . TEXT 'Movie Ticket Express' Job Description . . . . . . . . JOBD MOVIESVR Library . . . . . . . . . . . SGIHSM01 Additional Parameters Restrict User Access . . . . . . RESTRICT *NO Performance Monitoring . . . . . PFRMON *YES Request Parm User Attribute . . USRATR *NONE Bottom F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys

Once the server has been configured and restarted, performance statistics can be reviewed from the WRKHSMPFR (Work with HSM Performance) display.

                        Work with HSM Server Performance             SEATTLE1

 Server . . . . . : MOVIESVR                   Position To

 Type options, press Enter.
   3=Reset Data  4=Remove  5=Display

 Opt Request Op    Reply Op         Minimum     Maximum     Average       Count
     *PING         *PING                  0         515          24          47
     *STOP         *STOPPED               0          12           2           7
     GETCAP        DSPCAP                 3         263         133           2
     GETDTL        GOTDTL                 3           3           3           1
     GETLST        *ERROR                 -           -           -           0
     GETLST        GOTLST                 4          79          41           2

 F3=Exit          F5=Refresh            F6=Restart Server            F12=Cancel
 F17=Top          F18=Bottom            F20=Subset

As you can see, the results from this display will show the number of requests, and min/max/avg times (in milliseconds) required to complete a request for a particular opcode. Using this information will help you determine which opcode requests take the longest to complete and if server re-design is necessary in order to reduce average response times.

Multiple Server Instances
In addition to optimizing opcode response times, the use of multiple server instances will allow for more simultaneous requests to the same HSM server thus improving overall response times. The number of instances is controlled by the HSM server definition and can be controlled while the server is active using the CHGHSMINS (Change HSM Server Instances) command. Before running multiple instances of HSM servers, please note the following with may be relevant to your environment.
  1. Be sure the server program can accommodate multiple clients performing the same operations, at the same time, on the same objects referenced or updated by the server.
  2. Additional instances will result in additional HSM server jobs active in the Strategi subsystem. If manual performance tuning is being relied upon for storage pools and activity levels used for the Strategi subsystem, verify the additional server instances do not exceed current storage pool limitations. Doing so may result in degraded performance.
Strategi Tracking File and History Cleanup Commands

There are three Strategi commands that have been made available for safely cleaning up old files and for removing old records from transaction tracking and connection tracking data files (SGITT and SGICT). In V1R9+ releases, the cleanup process can be automated using the Strategi Values for file cleanup.

Please see Strategi Technical Support Bulletin on
Strategi Tracking File and History Cleanup Commands

References and Related Materials

OS/400 V4R4 Performance Guide
OS/400 TCP/IP Configuration and Reference
OS/400 Work Management V4R4
Software QA and Testing Resource Center
Velocigen VeloMeter Server Load Testing Software

** End of Technical Support Bulletin **