To obtain maximum productivity from computer users, it is essential to limit the computer's interactive response time to 1 second or less. The "old-fashioned" method of measuring response times involved sitting at the display station and manually timing each interactive response using either a stop-watch or by counting one-thousand one, one-thousand two, … . But times have changed and most computer platforms have much more sophisticated, not to mention more accurate, ways of measuring response times -- and you don't even need to leave your seat.
Why response times are important
Several years ago, studies conducted at IBM and elsewhere showed a relationship between a computer's response time and the users' productivity. The most compelling data showed that as response times extend beyond one second, user productivity starts falling off very rapidly.
Use the WRKACTJOB command to track response times
In the last installment, we discussed some tips to maximize your use of the Work with Active Jobs "tool." But this command does even more.
After the initial Work with Active Jobs screen is displayed, you can press F11 to toggle the right-hand side of the display to show detailed performance data for each job listed. Among the various figures is the average response time (the Rsp column) -- measured in seconds -- for every interactive job (only interactive jobs show a response time because non-interactive jobs such as batch jobs do not "respond" to a user). Figure 1 is an example of the Work with Active Jobs screen after pressing F11. Observing the numbers in the Rsp column lets you to keep track of how each interactive job -- and the system as a whole -- is faring.
|Figure 1: Example of the Work with Active Jobs screen after pressing F11.|
Interpreting response time data
The response times shown on the Work with Active Jobs screen are averages over the number of interactions occurring during the current measurement interval, that is, during the elapsed time as shown at the top-center of the screen. (See How to get the most from the WRKACTJOB tool for details on the elapsed time and how to refresh and reset it.) And see "Other useful columns on the Work with Active Jobs screen" for more information on data found on the Work with Active Jobs screen.
It is important to remember that the response times shown on the Work with Active Jobs screen are measured from the point when data arrives at the system to the point when data leaves the system. The time it takes the data to travel between the display station and the system is not included (even the time used by internal I/O processors to receive and send the data is not included). This can make the response time numbers on the Work with Active Jobs screen a bit misleading, especially if you are running over a relatively slow network/wiring scheme.
Remember to add the average time it takes data to travel through the network to the response times shown on the Work with Active Jobs screen to get an accurate reading. ("Network" time is usually negligible users connected directly to a local controller/network card.)
Making response times easier to track
If you have a large number of users to track (or even if you don't), you can save yourself some time when trying to spot jobs having response times greater than 1 second. Simply prompt the WRKACTJOB command and specify a "1" for the Response time limit (RSPLMT) parameter. This will limit the display to only interactive jobs having a response time of 1 second or greater during the measurement interval (i.e., as you press F5, jobs may appear and disappear from the list as their average response times change).
If you would rather spend a little programming time up front, you can save yourself from having to manually track response times by letting the system do it for you. The retrieve job information API (QUSRJOBI) can be used to retrieve information similar to that found on the Work with Active Jobs screen (the list job API (QUSLJOB) can be used to list all the interactive jobs on the system).
You can also go the quick and dirty route to automating the process by building a simple CL program that initially executes the following command once:
WRKACTJOB OUTPUT(*PRINT) RESET(*YES) RSPLMT(.1)Then have the program enter a delayed loop (e.g., using the DLYJOB command) that "wakes up" at a given interval (such as every 30 seconds, every minute or every five minutes), and executes the following command:
WRKACTJOB OUTPUT(*PRINT) RESET(*NO) RSPLMT(.5)
Note: You may want to replace the value on the RSPLMT parameter with a value that is more appropriate for you shop. Using .5 is a good start because it allows a cushion for network and other delays and still achieve sub-second overall response times.
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.
- Three basic system tools to help you tune your iSeries
The three basic performance management tools -- WRKSYSSTS, WRKDSKSTS and WRKACTJOB -- come with OS/400. Unfortunately, they aren't always put to the best use at the best time.
- Use CPU utilization guideline values to monitor high-priority (interactive) jobs
Don't wait until your system slows to a crawl before dealing with performance issues. By monitoring CPU utilization for critical applications, you can get warnings in advance of major problems.
- Interactive overload? Take a closer look at your programs
If your apps have sections that use a lot of CPU, make those subroutines separate programs. Then the heavy work can be done in batch via client/server and returned to the program.