Planning to Measure Using Strobe

This section provides an overview of the tasks associated with measuring application performance with Strobe, as well as a discussion of the various planning considerations for each of these tasks. This section also discusses planning considerations for using Strobe in a multisystem environment. If AutoStrobe is installed at your site, you should also read Planning-to-measure-by-using-AutoStrobe for a description of additional AutoStrobe planning tasks.

To obtain the maximum benefit from Strobe, you must complete a set of tasks. The following figure shows these tasks and the sequence in which you would usually perform them. These tasks are briefly described below.

1. Select the job step you want to measure. Strobe can measure an application whether it runs as a batch processing job, uses TSO, or executes in an online region. The job step you decide to measure is called the target job step.
2. Submit the measurement request. A measurement request specifies the measurement parameters for the target job step. You can specify the parameters using Strobe/ISPF or the Strobe command language. Optionally, you can request that Strobe automatically create a Performance Profile upon the completion of the measurement session.
   Once you have prepared the measurement request, submit the request using Strobe/ISPF or the Strobe command language.
   As soon as the target job step is active, Strobe begins a measurement session, an interval during which Strobe collects performance data for the application during the execution of the target job step.
   A measurement request can consist of one or more measurement sessions. During each session, Strobe collects and stores measurement data in a sample data set, a file that contains the information collected during a single measurement session. The measurement session begins when Strobe opens the sample data set and ends when Strobe closes it. Each measurement session corresponds to one sample data set.
3. Optionally, create a map data set. A map data set is the repository for the information Strobe uses to relate hexadecimal offsets and addresses in the object module with procedures or statements in the source program. DDIO files must be used for Assembler, C, COBOL, or PL/I. Map data sets should accommodate all other languages.
   You can create a map data set with Strobe/ISPF or by using cataloged procedures. This step can be performed at any time, before you create the Strobe performance profile. Typically, you create and review the Performance Profile to identify modules that display application performance improvement opportunities and then decide whether to create map data sets for any of those modules.

4. Create the 

   Strobe

    Performance Profile. After Strobe closes the sample data set, you can create the Performance Profile.
   The Performance Profile is a hierarchical series of reports that presents the application performance data collected by Strobe during a measurement session. These reports show where and how time is spent during application execution. You can create the Performance Profile using Strobe/ISPF or stored procedures. When using Strobe/ISPF, you can specify that Strobe automatically create the Performance Profile upon completion of the measurement session.
   Indexed source support is provided if you supply a DDIO file or a map data set when you create the Performance Profile. The resulting reports relate activity to line numbers and procedure names in your application, instead of hexadecimal offsets. This process is called indexing. Although indexing is optional, we recommend you perform the indexing process to aid your program analysis.

5. Analyze the 

   Strobe

    Performance Profile. By interpreting the report data, you can identify where the resource demands are concentrated and determine where to make changes to improve the performance of the application. Performance improvement opportunities include:

   • High concentrations of CPU activity
   • Excessive wait time
   • How your application invokes system service routines
6. Incorporate changes into your source code. You might decide to make changes to your application, based on your analysis of the Performance Profile. For example, you might want to change how your application uses resources or rewrite the code so that certain statements are executed only when necessary. You may also conclude that you need to make JCL changes, or perhaps improve the way your application accesses files.
7. After you have completed steps 1- 6, you can use Strobe again to verify your improvements to the code by repeating the cycle.

Planning Your Tasks

This section describes the planning considerations for the tasks described in Tasks and Key Terminology. Before you measure an application, we recommend that you consider the planning issues associated with each of these tasks.

Selecting Job Steps to Measure

With Strobe you can measure applications that run as batch jobs, use TSO, or execute in online regions. Various conditions may indicate that a particular application should be measured with Strobe.

Batch Processing Applications

A production batch processing program usually executes as a job step within a production job. A likely target for measurement is a batch job that has recently begun consuming more resources and/or clock time than usual. For example, you would probably measure a batch processing job that is exceeding the available batch window and impairing the application performance or availability of online regions.

Online Applications

The system demands of online applications vary during the course of a day. The first step is to determine what online regions require measuring, and what time frame you are interested in observing. There are several approaches to measuring online regions:

• Submit one measurement request that spans the time frame in which you are most interested.
• Submit one measurement request, but specify that the request use multiple measurement sessions (more than one sample data set associated with the request). Strobe allows you to change sample data sets and produce a Performance Profile while sampling continues in a different sample data set. This approach enables you to check application performance without interrupting the measurement process.

For example, the transaction response time for a crucial CICS application slows down every day at the same time. In this situation you can measure the application when the response time is acceptable, and measure it again when application performance degrades. By comparing the Performance Profile reports for the two measurement sessions, you can identify and examine potential areas for improvement in your online application.

Creating and Submitting the Measurement Request

After you have targeted an application to measure, you need to configure your measurement request. Decide on your session duration and target sample size.

Submitting Active and Queued Requests

You can submit a measurement request in two ways:

• If you submit your request while a target job step is executing, Strobe begins measurement immediately within the active job’s address space. This type of measurement request is called an active request and is commonly used to measure online applications.
• If you submit your request before the target job step executes, Strobe begins measurement when the target job step becomes active. This type of measurement request is called a queued request and is helpful in measuring batch applications.

Another consideration is whether you are measuring a batch job or an online application. If you are measuring a batch job, you may want to measure only a certain step of the job. With an online application, you may want Strobe to conduct several measurement sessions for comparison purposes, as explained in Online Applications.

The following sections describe preparing the measurement request. In addition, there are several other measurement options that you may want to consider.

Setting the Session Duration and the Target Sample Size

The session duration of the measurement session is an estimated length of time during which Strobe will measure the application. The value that you specify for this parameter depends on what you are measuring:

• To measure a batch job step that is not currently executing, the session duration should be an estimate of how long the step runs.
• To measure an online region, or a currently executing batch processing job step, session duration should be equal to the amount of time for which you want to collect measurement information. Very active regions or jobs can be accurately measured with short measurement sessions. For example, if you detect symptoms of poor performance in an online region (such as sluggish response) a brief measurement of the online region can help identify the cause. Less active regions or jobs require longer measurement sessions.

The target sample size for the measurement session is the number of measurement samples Strobe collects during the measurement session. The required number of samples depends on desired accuracy of the measurement and how long the job executes.

If you prefer a highly accurate measurement, specify 10,000 samples for every minute of session duration until the session duration surpasses 10 minutes. If the session duration exceeds 10 minutes, specify the maximum number of samples: 150,000. If a more accurate report is desired, take multiple measurements for a job lasting longer than 10 minutes. For example, if the application lasts 45 minutes, take three active measurements with a session duration of 10 minutes and 100,000 samples. Doing so ensures that Strobe collects a sufficient number of samples for the length of the entire job.

For an accurate measurement of an application that executes for less than one minute, you must increase the number of samples. For example, if the job runs for 30 seconds, specify 30,000 samples and a session duration of 1 minute.

The accuracy of a Strobe report is based on the rate of samples per minute of session duration. If the sampling rate is increased, the performance profile will be more accurate. Depending on the use case, an increased sampling rate may not be necessary.

Creating the Strobe Performance Profile

The Performance Profile is a hierarchical series of reports that presents the application performance data collected by Strobe. These reports show where and how time is spent during application execution.

When Strobe builds the Performance Profile, it processes, correlates, and merges information from the sample data set and, if provided, the DDIO files/map data set. Depending on the application you have measured, and the data you want to examine, you may be interested in only some of the information that Strobe has collected.

By default you get all the information you need, but you can specify which reports, and how much detail, the Performance Profile contains. Producing-Performance-Profiles-with-Strobe-ISPF and Managing-Measurement-Requests-with-Strobe-ISPF explain how to tailor reports and how to generate customized reports that include special details. You should first refer to Using-the-Strobe-Application-Performance-Measurement-System to review all of the types of reports that can be generated in a Performance Profile.

The following sections explain how to customize the Performance Profile so you can view particular measurement data. If you are using Strobe/ISPF, these options are available on the Strobe- Detail For a Performance Profile and Strobe- Tailor Reports panels. If you are creating Performance Profiles with a batch job, specify these options by using the parameters described in Specifying-Options-for-Reports.

Automatically Creating the Performance Profile

You can manually create the Performance Profile using Strobe/ISPF or stored procedures, or you can specify that Strobe automatically create the Performance Profile upon completion of the measurement session. To automatically create the Performance Profile, specify this option when you submit the active or queued measurement request using Strobe/ISPF. Selecting the automatic Performance Profile option saves time because it combines two steps into one. For more information, see Producing Profiles Automatically.

Controlling the Level of Detail in the Performance Profile

You can either compress or expand the level of detail of the reports in the Performance Profile. You can control the size of the reports by specifying certain parameters when you create the Performance Profile. For several reports, you can specify a minimum percentage of activity that must occur in order for a procedure or cylinder to appear as an individual line on the report. If the percentage is not reached, contiguous procedures or cylinders are condensed to a single line. The lower the number you specify, the greater the level of detail in the reports.

The following reports have minimum percentage options:

• Program Usage by Procedure
• DASD Usage by Cylinder
• Transaction Usage by Control Section
• Attribution reports

You can also break the reports into manageable sections by specifying the report resolution; that is, the number of bytes to be considered a codeblock for detailed reporting. Once again, the lower the number you specify, the greater the level of detail in the reports. For more information, see Using-the-Strobe-Application-Performance-Measurement-System.

Suppressing Reports

Some of the reports can contain statistical data that is not relevant to your application and runtime environment. You can suppress these reports. You can also suppress all the Attribution reports for a specified type of attribution. You can suppress attribution reports for SVCs, Db2, CICS, CA-IDMS, PL/I, COBOL, CA Gen, ADA3GL, IMS, Java, and WebSphere MQ.

You can also suppress the following reports:

• Transaction Usage by Control Section
• Program Usage by Procedure
• DASD Usage by Cylinder
• Data Set Characteristics Supplement
• CICS Transaction Profile
• CICS Region Level

Formatting the Performance Profile

Strobe provides several options that affect the appearance of the Performance Profile. For example, you can specify a subtitle that appears on the title line of the Performance Profile. You can also specify the maximum number of lines per page that appears on Performance Profile reports.

Creating an iStrobe Data File

If iStrobe is installed at your site, you can use Strobe to create an iStrobe data file that enables you to analyze the Performance Profile at a workstation using a standard Web browser. For more information, see Creating iStrobe Performance Profiles.

Analyzing Performance Profiles

Analyzing reports in the Performance Profile can reveal areas of a program or subsystem that offer significant opportunities for improvement. How you perform the analysis can depend on several factors. For example, one factor is whether you are comparing application performance across time intervals. If so, make sure that the Performance Profiles reflect the time intervals that you want to compare.

For an in-depth analysis of a Performance Profile, see Using-the-Strobe-Application-Performance-Measurement-System. To learn how to analyze Performance Profiles with iStrobe, see the iStrobe online help.

Source Support Using Indexed Source Code Modules

Sometimes you may be fairly certain the source code is the cause of an application’s poor performance problem. For example, you suspect a specific transaction is causing the sluggish response time for an online region. You can then measure the online region with Strobe and, if the resulting data confirms what you suspected, you can change the source code to correct the problem.

However, you may not be able to pinpoint why an application is performing poorly. If you did not write the source code or if the code is very complex, you may not quickly be able to identify the source of the problem. In these cases, use Strobe’s indexing capability to track down performance problems:

1. Measure the application with Strobe to identify potential problem areas.
2. Create the Performance Profile.
3. Use the Performance Profile to narrow possible problem areas down to specific source code modules.
4. Locate the DDIO file containing the source listing for the program you have determined requires indexing, or create a map data set for each of the selected modules. This will be automatic if you are using DDIO files with the iStrobe source support best practices data set naming conventions and there will be no need to rerun the Performance Profile.
5. Create the Performance Profile a second time, specifying the DDIO files or map data sets as input along with the sample data set created in the first step. The reports now show how the program activity relates to specific statements or procedures in your source code module.

Although the indexing process is optional, consider making it a part of your overall Strobe measurement process. The additional information indexing provides can significantly reduce the time you spend finding problem areas in your code.