Some Considerations for Performance Data Analysis

This section contains some of the considerations that apply to the analysis of LANSA Composer Processing Sequence performance data.

It is certainly not exhaustive.  Again, there is no substitute for a thorough understanding of all the factors affecting application performance on your IBM i or Windows server.

The considerations in this section are organised under the following headings:

Apples and Oranges

LANSA Integrator Activity

LANSA Composer Request Server Activity

Some Other Performance Metric Considerations

 

Apples and Oranges

If you are analyzing performance data for comparative purposes (with other runs of the same processing sequence or with another processing sequence or application), you should always make sure, as far as reasonably practical, that the processing sequence runs are performed under identical known, controlled and reproducible conditions.

On any multi-tasking system, performance of a given task is always subject to various configuration values as well as other workloads that the system is executing.  If you cannot ensure similar conditions across the runs you are comparing, then the results of your analysis may be flawed and any conclusions you reach may be unreliable.

Some of the factors you should consider include:

• Ideally the same versions of all relevant software operating system, database and other software should be used, or if this is not possible, the differences should be noted as a possible contributory factor.

• The resources available (the same amount of memory, adequate free disk space etc)

• Comparable system workloads

• Processing sequence inputs that will result in the same or comparable amount of work to be performed

• Relevant system settings are the same – for example, the tests should use the same system settings for logging in LANSA Composer.

 

LANSA Integrator Activity

LANSA Composer uses LANSA Integrator (JSM) services in a number of its supplied Activities, as well as for the execution of Transformation Maps.

When LANSA Composer invokes LANSA Integrator services, the work performed by the LANSA Integrator service is executed in a separate process.

Consequently, other than in the measure of elapsed time, the work performed by LANSA Integrator on behalf of LANSA Composer is not accounted for in the performance metrics collected by LANSA Composer.  This applies to disk and database I/O, memory usage and other resources that may be consumed by the LANSA Integrator service.

One most notable effect of this is that the LANSA Composer performance data collected will not account for I/O operations performed by Transformation Maps, or by certain other supplied Activities, such as the SQL database activities.

 

LANSA Composer Request Server Activity

If you use the CALL_FUNCTION or COMPOSER_RUN activities to call a LANSA function or to run a LANSA composer Processing Sequence through the LANSA Composer Request Server, the resources expended by the LANSA Composer Request Server job to satisfy the request will not be included in the LANSA Composer processing Sequence performance data collected.

The exception to this, in the case of a synchronous request, is that the time taken to complete the request will be included in the reported elapsed time.

 

Some Other Performance Metric Considerations

• When analysing performance data with respect to I/O operations, remember that they include I/O performed for Processing Sequence logging, for performance data collection as well as other I/O connected with the functions of the Processing Sequence controller.

• When analysing memory allocations, you need to be aware of the behavior of memory management algorithms implemented in the operating system and/or in the LANSA run-time.  For example, on an IBM i server, you may observe temporary storage intermittently increasing in increments such as 1024.  That may not necessarily mean that the processing sequence item suddenly required another whole megabyte of memory.  More likely, memory management is occurring that allocates memory in large blocks from time-to-time and then satisfies smaller request for memory from the allocated block until it is exhausted.

• Reporting of some metrics may be constrained by hardware and/or operating system limitations.  For example, in some Windows configurations, the smallest resolution of the system clock is 16ms.