Help

 

Application Performance Analysis

This information provides the basic analysis workflow for using iStrobe to analyze your Performance Profile.

Before analyzing a Performance Profile, you should determine whether the Profile represents an accurate picture of the application's typical execution and performance. You can derive incorrect performance improvement strategies if you modify an application based on information derived from an atypical measurement session, or from a Profile with a high margin of error.

Look at the Measurement Session Data (MSD) report and consider the following:

  • Verify the Job, Step, Session start date, and Session start time fields to ensure that you are examining the correct Performance Profile. Make sure that the Subsystems field identifies the appropriate subsystems for the application, such as IMS.

  • Determine validity by examining the Runtime margin of error percent. A runtime margin of error of less than two percent indicates that enough samples have been taken to produce a valid report. If your runtime margin of error is higher than two percent, and your area of concern is a small percentage, consider re-measuring to get more samples so that you can benefit from greater accuracy. Reports with a higher margin can still be valid and usable, if your area of concern is a large percentage. You can also find it useful to check the Total samples taken field. If it is less than 10,000, consider re-measuring to get a larger number of samples.

  • Check the Page rate/sec field. System programmers should try to keep the paging rate low (1-10 per second). To eliminate excessive paging, application programmers should avoid unnecessary branching routines.

CPU or Wait?

Whether you approach the Performance Profile from the CPU or wait side is largely determined by your performance improvement goals and the proportion of execution time percent to wait time percent. You typically do not need to examine all of the reports in the Performance Profile.

To determine whether to examine the CPU execution or wait reports in the Performance Profile, look at the Percent time section at the top of the middle column of the Measurement Session Data report. The values reported for Execution (the percentage of time that one or more CPUs were active) and Wait will usually determine whether you should focus on the CPU execution reports or the wait reports.

  • If you are interested in wait, look at the Analyzing Wait section below. Note that if there is no significant wait time activity, Strobe will not produce any wait time reports.

  • If you are interested in CPU use, go to the next section,  Analyzing CPU Usage.

Note: The Top Resource Consumers report provides another quick way to find those programs and modules that are using the most resources. This report lists the top resource consumers and enables you to go directly to the reports that supply detail about the resource consumers.

Analyzing CPU Usage

Determine whether system overhead or user code is consuming the most CPU by looking at the CPU Usage by Program report.

  • If .SYSTEM (system routines such as SVCs, subsystem routines, and library routines) consumes the most CPU, try analyzing overhead.
  • Expand .SYSTEM (click  to the left of the pseudo-module name) to see which MVS subsystems and pseudo-modules consume the most CPU, and examine the appropriate subsystem-specific reports. For language routines or MVS supervisor calls (SVCs), examine the Attribution of CPU Usage to identify the invokers of these routines. To view procedure names and source code line numbers of code that invoked the routines, consider indexing your source code and then recreating the Performance Profile.
  • If .USER is consuming the most CPU, try examining source code.

Examining Source Code

On the Program CPU Use report, expand .USER to see which MVS and subsystems consume the most CPU.

  • If you see high execution time for language routines or MVS supervisor calls (SVCs), examine the Attribution of CPU Execution Time to identify the invokers of these routines, and if the Profile is indexed, the lines of code that invoked them.

  • If excessive CPU is caused by user code, see whether you can reduce CPU usage caused by data type conversions or improper looping structures. Expand the report down to the detail level to identify the specific offsets that are using CPU resources.

  • If you see a difference between total CPU and total attributed CPU, look at the system routines called on behalf of that line of code. If the percent of attributed CPU is significant, expand the Line number or Starting location to see the system services invoked on behalf of that statement.

To view procedure names and source code line numbers in these reports, consider indexing your source code and then recreating the Performance Profile.

Analyzing Wait

Determine what is causing the wait by looking at the Resource Demand Distribution report:

  • In the Task or DDNAME column, if the majority of the wait is shown to a DDNAME, examine physical access. If the majority of the wait is attributed to the pseudo-activity .FILEMGT, examine .FILEMGT.

  • In the Resource column, if you see the value CPU, go to the Wait Time by Module report to locate the module in which the wait is occurring. Use the Attribution of CPU Wait Time report to find what is causing the wait. For more information on task wait to subsystems, see the performance analysis tips for Db2, IMS, or CICS.

Examining Physical Access

To examine physical access for your application:

  • Examine the Data Set Characteristics report. For files with a high EXCP count, examine their blocking, buffers, and splits.

  • On the Resource Demand Distribution report, examine the Distribution of activity over run time graph to see if files are busy at the same times.

  • Examine the I/O Facility Usage report to see where files reside. Expand the report down to the detail level to examine cylinder access.

  • Examine the VSAM LSR Pool Statistics report to see how LSR pools are defined and used.

Examining .FILEMGT

If the Resource Demand Distribution report shows wait to .FILEMGT:

  • Use the Wait Time by Module report to examine wait incurred by MVS supervisor calls (SVCs).

  • Use the Attribution of CPU Wait Time report to determine which transaction or module invoked the function associated with the wait (that is, where in your program you open and close files).

  • Examine the Distribution of activity over run time graph (on the Resource Demand Distribution report) to see where wait was incurred.

  • Examine the I/O Facility Usage report to see which device is associated with the file management overhead.

Additional Performance Analysis Tips

For more ideas about how to interpret your measurement data, see:

  • Online help for each report. Be sure to take a look at the Analysis tips section (at the bottom of most report help panels).

  • Online help topics for subsystems. From the Help table of contents, select Application Performance Analysis Help, and choose Db2, CICS, or IMS.