Overview of Application Performance Management

Strobe is a software product that reports on how your application programs use resources in IBM z/OS environments. It determines where and how an online or batch application spends time. Incorporating Strobe measurement into each phase of the application life cycle—design and development; build, test and quality assurance; production; and maintenance—ensures that your applications are designed to run efficiently and responsively and that no performance problems are unintentionally introduced.

Strobe employs a sampling technique that executes within the Strobe Measurement Services Address Space (MSAS) and periodically takes snapshots of an application’s execution. Strobe stores this data in a sample data set, and organizes the information to produce the Strobe Performance Profile, a hierarchical series of reports that show where and how time was spent during the application’s execution. The Performance Profile can indicate which few lines of code, among perhaps thousands, are using significant amounts of system resources. With this focus, you can examine your coding techniques and make changes to only those areas of code that have a major effect on performance.

The benefits of APM with Strobe

Strobe and iStrobe enable you to implement an application performance management (APM) program, the quality management discipline used by IS professionals to deliver efficient and responsive applications and to maintain high levels of application performance throughout an application’s life cycle. APM ensures that each functional group within the IS organization views application efficiency and responsiveness as essential quality attributes of the products it delivers.

Efficient and responsive application performance is paramount to meeting the business goals of an enterprise. The cost of inefficiencies in business-critical applications can be measured in lost revenue, wasted resources, and weakened competitive position. An APM strategy establishes IS standards through which you can evaluate and control an application’s performance as the application moves through its life cycle. The benefits of APM include developing and maintaining efficient applications, delivering responsive applications, increasing system capacity for additional applications or program development, and controlling costs.

For each phase of the application life cycle, APM defines a set of methods, benchmarks, and tasks that ensure efficient and responsive applications. In an APM discipline, products specific to application performance—Strobe and iStrobe — are used with other software products to optimize application performance.

AutoStrobe allows you to collect and display historical information for measurement sessions. With this measurement session history, you can more easily identify and track changes in the performance of a particular job step, online region transaction, or DBRM and relate these changes in performance to changes in operating costs. This capability can be useful in all phases of application performance management. For more information, refer to the Using-Strobe-to-measure-online-applications-and-batch-programs.

The following sections describe how to incorporate Strobe in each phase of the application life cycle.

Design and development

As a development professional, you can use Strobe frequently during application development. Measuring with Strobe in development enables you to identify and fix performance problems early in the application’s life cycle. When designing a new application, you can measure the new code with Strobe to ensure that it is efficient in its use of system resources. As you develop an application, you can periodically measure with Strobe to identify and eliminate any performance problems inherent in the design before your code enters the test stage.

You can assess alternative programming techniques by measuring the performance of various test cases. This approach is useful for evaluating the resource demands of generated code (4GL), the relative efficiency of algorithms, and the effect on resource usage of such factors as data type. With Strobe you can also determine the relative resource demands of access methods in response to different parameters.

Build, test, and quality assurance

You can incorporate Strobe into the build, test, and quality assurance process. With Strobe you can confirm design assumptions about a new application’s resource requirements by measuring the application when it is exposed to production volumes of data. You can measure the resource use of a new release of an application and compare it with the production release it is to replace. This comparison will ensure that inefficiencies have not been unintentionally introduced and that program changes do not degrade performance.

You can embed Strobe measurement into test jobs, making performance measurement part of the test procedure. Your test cycle then ensures that your application is responsive and efficient.

Production

You can use Strobe in a systematic effort to improve the general efficiency of your application portfolio and reduce costs. By reducing the resource use of those applications that place the highest demands on your system resources, you free resources for other applications. Once you have investigated and acted on all the performance improvement opportunities in an application, you can develop a set of performance benchmarks for later measurement and improvement. You can plan the resource load of the application and respond early if a new release fails to meet your benchmarks.

Maintenance

During program maintenance, programmers make changes to existing code—whether to fix a problem, enhance application function, or refit the application to run in a new operating environment. Using Strobe in maintenance helps ensure that application efficiency continues to conform to established benchmarks.

When you first implement an APM discipline, you are likely to discover substantial opportunities for improving the general efficiency of your data center, enhancing service, and reducing processing costs. During maintenance, you can employ Strobe in a systematic effort to reclaim system resources used by inefficient applications. For example, you can free resources for additional processing by targeting those batch processing programs and online applications that place the highest demand on the system.

Overview of using Strobe

Using Strobe within an APM discipline is an iterative process. Your first step is to decide what program to measure. You then submit a request for measurement and produce a Performance Profile from the information gathered. You interpret the Performance Profile, focusing on high concentrations of CPU activity or elapsed time in your programs, or in service routines invoked by your application. As a result of your interpretation, you make improvements to your source code and then measure again with Strobe to verify your results and, possibly, to reveal additional performance improvement opportunities. This process is shown in the following figure:

The flexibility and powerful reporting capabilities of Strobe make it a convenient and useful product. Strobe provides you with a number of options, such as:

• Selecting job steps for measurement
• Controlling the duration and rate of measurement
• Controlling the type and amount of data collected
• Determining where Strobe saves the data.

For more detailed instructions on the steps discussed next, refer to the Using-Strobe-to-measure-online-applications-and-batch-programs.

What to measure

When considering which programs to measure, focus on those that are the heaviest users of CPU or experience elapsed time that is significantly above average. Particularly good candidates for improvement are programs whose CPU usage or elapsed time has recently increased.

The level of CPU or elapsed time that you consider high, and therefore a candidate for improvement, depends on your objectives and standards. If you want to delay a hardware upgrade, any opportunity to save CPU time is important. If your data center charges back for CPU time, any reduction in CPU time represents a cost savings for your department. If, however, your online applications risk coming up late because of long-running application programs, excessive elapsed time becomes your focus. Often, the most significant cause of an application’s extended elapsed time is wait time—the portion of run time during which the application was in the wait state when no task within the measured address space was able to make use of the CPU time available to it.

AutoStrobe measurement candidates

Instead of determining yourself what batch applications and CICS transactions are candidates for Strobe measurements, you can use AutoStrobe to help you select them. AutoStrobe can monitor your batch and CICS transaction activity. Based on performance criteria, AutoStrobe can initiate a measurement request for jobs performing abnormally.

Refer to the Using-Strobe-to-measure-online-applications-and-batch-programs for information about selecting Strobe measurement candidates with AutoStrobe candidate processing tools.

Invoking Strobe

Once you have selected a job step to measure, you can invoke Strobe through:

• Strobe/ISPF—a convenient menu-driven interface to the Strobe system
• Strobe command language—a program that you can invoke through TSO commands or batch jobs.
• iStrobe—the web based Strobe system 

The job step of the application that you decide to measure is a target job step. Strobe offers a way to:

• Submit a request to measure the job step, whether currently executing or scheduled to run later
• Retrieve the results of the measurement and produce reports.

Managing measurement

Strobe identifies the period of time it collects data for a sample data set as a measurement session. A measurement request initiates one or more measurement sessions, with an equal number of sample data sets.

When you submit a request to measure a target job step, Strobe manages the request by:

• Storing and tracking it
• Initiating a measurement session to service it
• Associating the details of the measurement session (including the name of the sample data set and messages resulting from it) with the measurement request.

When you submit a measurement request, you must identify the name of a job and the job step that you want to measure. You can also specify measurement session parameters, such as the target sample size, measurement session duration, and sample data set information. You can instruct Strobe to collect the types of data you need for your analysis, although in most instances Strobe collects the right kind of data about the application by default. Optionally, you can request that Strobe automatically creates a Performance Profile upon completion of the measurement session.

For more information on measurement parameters, refer to the Using-Strobe-to-measure-online-applications-and-batch-programs.

During execution of the target job step, Strobe uses a sampling technique to collect data about the system resources used within an active job step. At set intervals, Strobe interrupts the executing job step to record various types of information about the job that you are measuring.

Strobe provides flexibility for measuring different types of applications. You can manage Strobe measurement requests that target batch processing applications, online applications, and multi-region online applications.

Batch processing applications

You can use Strobe to investigate a critical batch processing program in production that takes much longer than expected to complete. You can invoke Strobe to initiate measurement while the job is being processed. If the production batch processing program executes when you are not logged on, you can submit a Strobe measurement request before the job is processed. When the targeted production job step is dispatched, Strobe begins measuring.

Online applications

You can measure online applications in response to changing transaction loads. When you measure an online application, you can conduct a number of measurements during the application’s most active periods rather than one long measurement.

In addition, Strobe enables you to respond to online activity while you observe it. You can control a measurement session while it is in progress by issuing commands to Strobe. You can:

• Start or restart sampling
• Suspend or stop sampling
• Switch to a new sample data set
• Terminate measurement.

If you schedule measurement during peak periods, you can detect trends in resource growth that provide information to help you in capacity planning. You can limit sampling to those periods in which you are interested.

Short measurement sessions can help you, if you are responsible for data processing services, to diagnose operational problems within an online region. A brief measurement session can help you identify the cause of performance problems such as sluggish response, saturation of the CPU, saturation of a channel, or excessive storage demand.

Long measurement sessions can help you to obtain information about resource use over time. You can conduct extended sessions to determine the resource demand of individual transaction types or application programs on the system.

Multiregion online applications

Some applications use more than one online subsystem (such as CICS, Db2, CA-IDMS, or IMS) consisting of one or more service regions and one or more dependent regions, each executing in its own independent address space. You can conduct independent measurements in all of these address spaces. With AutoStrobe, you can create a group of measurement requests that will simultaneously measure activity in multiple address spaces. For example, you can measure an IMS application that processes data managed by Db2. You can then see a more complete picture of the application’s overall performance by reviewing the Performance Profiles for both the IMS and the Db2 regions.

Producing the performance profile

When measurement is completed and the sample data set is closed, you submit a command through Strobe/ISPF or Strobe command language to produce a Performance Profile—or you can request that Strobe automatically produce the Performance Profile for you, as part of the measurement request. Alternatively, you can produce a Performance Profile by executing a batch job using BMC-supplied procedures. The Performance Profile is a series of reports that associates the performance information in the sample data set to sources within your application code. Strobe relates information in the sample data set to the hexadecimal offsets in your application, showing you where the application uses resources. If you perform the step called indexing, Strobe associates the sample data set’s measurement information with your application’s line numbers and procedure names.

Source support indexing

When measuring, Strobe can identify the offset of the instruction from the beginning of the executing module, but cannot identify source code statements or statement numbers unless they are present during execution. Indexing is an optional Strobe activity that uses the listing from a source language compiler to identify procedures and statements within a source module. When you index a program, Strobe creates a map data set that relates the source code statements and line numbers in the program to the offsets in the compiled object module. For certain languages, a DDIO file is used instead of a map data set. You then produce a Performance Profile using the DDIO file — or the map data set — along with the sample data set as input. This Performance Profile is referred to as indexed; that is, it relates activity to your application’s line numbers, procedure names, and statements instead of the hexadecimal offsets.

Source Support and the language-specific rules that govern indexing are detailed in Indexed Source Performance Profiles.

Strobe Indexed Source Support

DDIO is a BMC AMI Common Shared Services (CSS) file that is a repository for product information. Refer to the Using-Strobe-to-measure-online-applications-and-batch-programs for more information about indexing and DDIO files. DDIO files are used for indexing the following languages:

• COBOL
• C
• Assembler
• PL/I

The Strobe system also includes model cataloged procedures that compile and index source programs written in the following languages and development environments:

• ADS/O
• C++
• CA Gen
• IX_indexing_for:
• CA-IDMS dialogs
• CA-Optimizer
• FORTRAN
• Natural

Interpreting the performance profile

Your interpretation of the reports in the Performance Profile points you to opportunities to reduce CPU time or wait time. Interpreting the Strobe Performance Profile provides a sample Performance Profile and explains how to interpret the reports. Strobe Performance Profile provides a sample of each report in the Performance Profile, describing all the fields and columns.

Strobe options

Additional subsystem and language-specific performance data are available in your Performance Profile if you are using Strobe options. Strobe options extend your ability to manage application performance by providing additional facilities to collect specialized data about system performance and assisting your analysis of applications compiled in a variety of program languages.