| 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. 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 Tips
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. ADVANTAGES
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. ADVANTAGES
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. ==> STRATEGI/ENDSGI ==> CHGSBSD SBSD(STRATEGI/STRATEGI) POOLS((1 16384 15)) ==> STRATEGI/STRSGI 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
Bottom
===>
F21=Select assistance level
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. Summary 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.
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.
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:
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"> ... </applet> 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. Tips
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:
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
Bottom
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.
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 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 ** |
|
|
 |