Performance Optimization of translated application
The most common performance problems are:
DB2 on Mainframe has commnunication lags
The communication between DB2 on mainframe and external Java / C# applications is usually slow.
The application's performance may significantly improve by moving the database to another machine - perhaps as much as couple of orders of magnitude.
An alternative approach would be to deploy the Java application on the mainframe.
The effects of this communication lag can be measured by switching SoftwareMining PROFILER on to generate timing logs, and checking the logs for Connection and SQL retrieval times.
Other database performance issues
Additionally, the following should help reducing impact of database communications :
For Java applications: Use type-4 Jdbc Drives
For C# applications: Use libraries utilizing MSSQLServer, Oracle or ADO drivers (rather than ODBC)
Where possible reduce database communications: For example the following SQL Statement does not retrieve any stored data, it just returns time with better precision:
EXEC SQL SET :WS-DATE-TIME = CURRENT TIMESTAMP
The above call can be replaced with a local call to a Java (or C#) utility to perform the same function, e.g. DateUtil.getDb2Date() NOTE: The default configuration for SoftwareMining CORECT Translator will do this automatically.
Review SQL Code
Due to the low cost of SQL communications, some COBOL developers may have used multiple database calls when one would have been sufficient.
For example:
EXEC SQL SELECT id FROM MASTER_TABLE where name = 'ABC'
...
EXEC SQL SELECT * FROM CHILD_TABLE where id = :MASTER_ID
The cost of above statements could be cut in half by using a the following statement, ie by changing the program to make a single call to the database:
EXEC SQL SELECT * FROM CHILD_TABLE WHERE id in (SELECT id FROM MASTER_TABLE where name = 'ABC')
Translation of VSAM KSDS files to Database table
On mainframe, VSAM is a file-access, it does not require a database connection to be setup and it does not require queries and results to be marshalled (usually via TCP/IP).
As such accessing VSAM files is faster than Database. (Storing data in databases have other HUGE advantages).
There are several approaches to overcome performance problems resulting from migration to VSAM to SQL databases:
Optimizing database - by adding additional indexes
Optimizing Object-Relational API's - adding new conditions. See Performance Optimization Techniques in VSAM Translation Guide
When the data is accessed only by one program at a time (ie not requiring Transaction Management), a file based approach can be used.
To do this you can change the super class of the relevant Object-Relational class from
SQLWrapper
to
IndexedFile
In built PROFILER
SoftwareMining's framework libraries have a built-in Profiling system.
The focus of the profiler is to show which set of API's may be causing bottlenecks and performance issues.
The profiler is most useful for detecting bottlenecks in batch programs.
Enabling the Profiler Place the following line in corect.properties configuration file to enable the profiler.
PROFILE_RUNTIME=true
Also, make sure the Log4j/Log4net has been set to write out "INFO" level logs.
What to look for in the generated logs: look out for lines relating to timings on the following
SQL & Database communication (e.g. ConnectionFactory, ESQLProcessor)
SQLWrapper times (to do with migration of VSAM data to SQL Database)
Sequential File Access
SortManager
CBLField.resetWrapperOffset (used in OCCURS DEPENDING)
Timing Business Logic Performance
The translated application uses the following Log4j (C# log4net) log levels:
TRACE
- traces library functions. for example for sqlProsessor.executeQuery() statement it will write out statement relating to
retrieving connection from pool
preparing SQL Statement
executing SQL Statement
Assigning value of column-1 to variable ...
DEBUG
Writes out entries into (and sometimes exits from) the methods in translated code.
INFO
Used for general information including PROFILING information,
WARNING
- Continue-able warnings. These are mostly generated when the following flag has been switched on in the corect.properties configuration file.
SAFE_MODE=true
ERROR
- Errors
With the right configuration of the logging system, the "Trace" or "DEBUG" log levels can be used to help identify where most of the time is being spent.
What to look for in the generated logs: Switch log level to trace, and look in log file for the following type of entries
Created new database connection ...
For batch programs, there should only one instance of the above line.
For online programs, the number of entries can be more, depending on how many times the program is executed concurrently.
However as programs are concluded, the connections should be placed in a connection-pool. The size of the pool is allocated in db.properties file.
Increasing performance of Batch Programs: Parallelization
Whether the application is deployed on a Cloud or local servers, these days processing power is cheap.
I.e. By slight manual adjustments, batch programs can benefit from multi-threaded / multi-processor approaches for significance performance gains.
SoftwareMining has already built parallelization techniques into our framework libraries to provide a quick path to parallelization and multi-threading.
Please see How-to parallelize translated Batch programs
