Tuning ABL application code in test, staging and production environments is typically done by tuning how well the code is performing after being deployed to a Progress Application Server for OpenEdge instance. You can perform server-side profiling, write custom logging programs using the LOG-MANAGER system handle, and enable client parameters to collect usage statistics to monitor how well your ABL code is performing.

Monitor ABL code performance with server-side profiling

Profiling your application during development is the recommended method for catching performance bottlenecks.

Figure 1. Server-side ABL performance profiling architecture
To use server-side profiling for a PAS for OpenEdge instance:
  1. Enable server-side profiling.

    For more information, see PAS for OpenEdge server-side tuning in Manage Progress Application Server (PAS) for OpenEdge.

  2. The performance data is pushed to a diagnostic store, which is a web application deployed on a PAS for OpenEdge instance, that receives performance data from deployed ABL applications and stores that data in an OpenEdge database. You can either create a new PAS for OpenEdge instance for the diagnostic store, or you can use an existing instance.

    For more information, see Configure the diagnostic store in Manage Progress Application Server (PAS) for OpenEdge.

  3. View the data using a Profiler Viewer in Progress Developer Studio.

    For more information, see Profiler View in Progress Developer Studio for OpenEdge Online Help.

Monitor ABL code performance with LOG-MANAGER

Some developers use the LOG-MANAGER to capture logging details and write debug messages to help identify performance issues. The LOG-MANAGER system handle turns on logging details for the following:
  • 4GLTrace—Logs of execution details:what was called, when, for how long, and what was passed in and out.

    For more information, see ABL trace logging in Troubleshoot ABL Applications.

  • QryInfo—Logs queries (each open query and FOR EACH block) executed in an application.

    For more information, see Query information log entry type and logging levels in Troubleshoot ABL Applications.

  • 4GLTrans—Logs transaction processing and subtransactions in ABL procedures.

    For more information, see ABL transaction logging in Troubleshoot ABL Applications.

Reviewing the logs can help reveal potential bottlenecks caused by poorly written code with poor index selections and open transactions. There are Knowledge Base articles with scripts to help search for useful information in the log files. For more information about managing logs, see Script to help manage abl client log sizes when extended logging is enabled and Script to help manage PAS for OpenEdge log sizes when extended logging is enabled.

Collect ABL client statistics

There are a set of client startup parameters available to collect usage statistics. With this information, you can identify client usage, segment statistics, and details about the call stack.

Table 1. Client startup parameters for tuning
Parameter How performance is monitored
-y Collects procedure access and usage statistics throughout the OpenEdge session.

For more information, see Statistics (-y) in Startup Command and Parameter Reference.
-yd Writes segment statistics to the client monitor file (client.mon, by default).

For more information, see Segment Statistics (-yd) in Startup Command and Parameter Reference.
-yx Collects procedure call statistics and writes them to an output file.

For more information, see Statistics With Cross-reference (-yx) in Startup Command and Parameter Reference.