gtpa3m15Application Requester User's Guide

Specific Performance Considerations

Methods of Calculating Response Time

This section describes methods for calculating TPFAR response times to SQL requests.

ZSTTD and the SQL Trace Table

Using ZSTTD, you can display the SQL trace table, which contains the response time for SQL requests. At the start of each SQL request, TPFAR saves the original clock value. When the return is made to the application, TPFAR saves the current clock value and subtracts this from the original clock value. The difference, which represents the response time, is stored in the SQL trace table. See TPF Operations for more information about ZSTTD.

The SQL trace table is processed in wrap-around mode. Only the most recent SQL commands are saved in the table and can be examined via ZSTTD. In order to save information from older SQL commands, the user exit in segment UAR1 can be used to process the information in the SQL trace table before it is overwritten.

Data Reduction Reports

A data reduction report, called a system summary report, is calculated for TPFAR. The system summary report has 2 fields:

Message stream data is available for data reduction for the TPFAR system by using the SNA DDM option. The STREAM DDM report shows the DDM message traffic, including the existence time. The existence time is the time difference between the SQL request being sent out from TPF to DB2 and the response coming back into TPF from DB2. By using the existence time and the ZSTTD information, you can determine the SQL request time within TPFAR and TPF/APPC code.

Segment Allocation

Because most TPFAR segments are one-time calls and returns, it is recommended that the segments be core-resident to reduce the enter/back overhead. This greatly improves TPFAR performance.

TPF Utilization Impact

The following list contains items in TPF that can affect TPF processor utilization when using TPFAR. All users need to evaluate their own requirements for utilization and TPFAR in order to adjust their system accordingly.

  1. The format of the data type.

    When the table is created on DB2, information about the column types is supplied. When a user program asks for the data back in a different form (for instance the table column was created as a floating point number, but the application wants the data in an integer format), this causes additional TPF overhead to convert the data to the requested type.

  2. The number of affected columns.

    The larger the number of columns returned on an SQL SELECT or the larger the number of columns used on an SQL INSERT, the more the processing time is affected. The affected columns can have a large impact on processing time, especially on SQL SELECTS. With SQL, you can specify the specific columns that you want returned to your application. An application program that issues an SQL SELECT should only request the data that is required for the application. This way, the amount of processing to return a row to the application can be reduced.

  3. The cumulative size of host variables.

    TPF/APPC limits the size of an RU. This limit affects the number of host variables that can fit in a single RU. See Request Unit Size Considerations for more on the effect this limit has on the system. TCP/IP similarly limits the size of a send message.

  4. The select conditions specified.

    When a large number of host variables are used in the condition statement of an SQL command, these variables need to be transmitted to DB2. The more host variables there are on a condition statement, the larger the utilization impact on TPF.

  5. The SNA pacing for LU 6.2.

    When sending a large amount of SQL traffic over SNA, SNA pacing limits need to be evaluated. If the pacing value is too low, the processing of a pacing request or response slows system performance. SNA pacing includes session as well as virtual route (with PU 5 support) pacing.

  6. The SQL command mix.

    Of all the SQL commands, the cursor-related, blocked-SQL fetch especially affects system performance. When using the blocked-SQL fetch, multiple rows of the answer set are sent back to TPF from DB2. When the application requests the next row, TPF can use the row information already returned by DB2, rather then having to go back to DB2.

  7. Run-time binding versus static binding.

    Run-time binding can be a convenient method for managing DBRMs across multiple platforms. Run-time binding incurs the overhead of the time required to perform the bind. This overhead depends on the system load and configuration. Once a DBRM is bound for a given program on a DB2 system, there is no performance difference between run-time binding and static binding.