
The purpose of this process is to define what to measure and what parts of it to measure. You also use it to define how and when the measurement must take place.
After you start the runtime analysis, the system displays the Measurement tab page by default. You use this tab to define and execute a runtime measurement.
The procedure for creating a measurement is as follows:
Check the traffic light for the Reliability of the Target Values. Can you execute a reliable runtime analysis in this system?
The light is green if there are no reasons why you should doubt the reliability of the runtime determination.
The clock resolution and type of kernel can influence the reliability. A relevant traffic light color and message is displayed if the reliability of the values is affected.
To set the clock resolution, see Setting the Measurement Accuracy.
Define the measurement strategy. Select a measurement variant for the measurement. There are both personal and system-wide variants.
You can also create a measurement variant of your own by selecting
, adapting the measurement settings, and saving the measurement variant.
Specify the description of a new measurement variant in the Short Description field. If you do not enter a description, the system automatically assigns the name of the measurement variant as the value for this entry field.
For more information, see Variant Definition.
You can choose to have the names of internal tables filled in the runtime measurement.
At runtime, the ABAP runtime system does not know the names of the internal tables. Instead, they are enumerated and appear in the trace with the pseudo-name IT_<Number>.
If you select the With Names of Internal Tables checkbox in the Data Preparation area, the system attempts to parse the real (ABAP source) names of the internal tables at the time of the trace analysis. This is a resource consuming option.
It only makes sense to select this option if you have activated the tracking of operations on internal tables in the measurement variant. Such operations are not tracked by default.
Now execute your measurement.
After you have defined the measurement settings, you can create the measurement in one of three execution modes:
Create a measurement interactively in dialog mode.
In this mode you execute the program to be measured interactively in that you can execute any functions of the program. In this way you can measure the functions that you think are adversely affecting performance in a targeted way.
Execute a measurement in a parallel mode.
In this mode you can activate the runtime measurement in specific work processes on the local server. In this way you can, for example, include the execution of a long-running program for the runtime analysis.
During activation the internal mode that is currently running is measured or the internal mode that comes next in the work process. An internal mode basically corresponds to a program that is to be executed. If the internal mode is ended or rolled out after a dialog step, then the measurement is also ended.
You can activate the runtime analysis at the same time in up to ten work processes.
Plan a measurement execution.
With this mode you can measure programs that you cannot start interactively in the runtime analysis. For example, you can measure the execution of Web Dynpro, BSP, and Web service application using scheduling as well as the executing of programs in the background processing.
For more information, see Executing Measurements.
After you have created and executed a measurement, a trace file with the measurement results is created and stored on the database.
You can display and analyze the results of a measurement using the Evaluate tab.
For more information, see Measurement Results.
If you measure the same transaction or program several times, the data can vary. Many factors make it difficult to reproduce identical performance data twice. In the first runtime analysis the system reads data records directly from the database, for example. In a second run, the system reads from the table buffer on the application server.
Performance data also depends on the overall system or network load. For example, the number of active jobs or programs in your SAP system can seriously affect the runtime.