The next step is to initialize the OpenEdge database server using the best possible configuration. This is easier than ever, with the new database server defaults.

Tune operating system resources to improve database performance

Because system and application performance can vary greatly depending on the configuration, use the performance recommendations provided and make adjustments for your specific configuration.

For best performance, Progress recommends that you use a dedicated server for your OpenEdge database to prevent outside applications from negatively affecting your database performance. Additionally, you should review the impact your operating system settings can have on your overall database performance. For more information, see Tunable operating system resources in OpenEdge Database Essentials.

Initialize your development, test, and staging database server

Once your application is ready to move to the test, staging, and production environments, you must set system, network and startup parameters that will optimize your performance.
  • Check system configurations

    The potential for improving the performance of your OpenEdge database depends on your m. Some options might not be available on your hardware or operating system platform. For more information, see Manage database performance in Manage the OpenEdge Database.

  • Set network communications parameters
    OpenEdge provides default startup parameters that help with performance. The following table describes the network communication parameters that are initialized to help your network run efficiently.
    Table 1. Best practices for network communication parameters
    Parameter How performance is improved
    -Mm Default value is 8192. Tune this parameter to avoid record fragmentation. For more information, see Message Buffer Size (-Mm).
    -prefetchDelay Enabled by default. Use this parameter to delay sending the first network message for queries with prefetch capabilities. When enabled, -prefetchNumRecs and -prefetchFactor parameters determine the duration of the delay. For more information, see Prefetch delay (-prefetchDelay).
    -prefetchNumRecs Enabled by default. Use this parameter to increase the number of records placed in a network message before it is sent to a remote client. Enabling this parameter may cause a remote client to wait longer for full network messages that contain prefetched records, but the overall system performance is expected to improve by saving on network traffic. Another possible side effect is that an individual remote client see might see irregular responses from the server. For more information, see Prefetch Num Recs (-prefetchNumRecs) Search.
    -prefetchFactor Default value is 100. Use this parameter to establish a percentage of a network message that is required to contain prefetched data before sending the message to a remote client that is waiting for a response. If users experience unacceptable delays on a consistent basis, consider reducing the percentage to a network packet size that meets the expected response times. In most cases, 100 is preferred. For more information, see Prefetch factor (-prefetchFactor).

    Use Prefetch Priority (-preFetchPriority) to utilize a "pollskip" that adds n records to the network message of an in-process prefetch query without additional polling. Adding more than one record to the message at a time can greatly reduce the number of poll() calls being made on a large database configuration. The expected result is that reducing poll() calls improves overall system performance by decreasing the "System CPU" cycles allow for increased "User CPU" cycles. The pollskip only occurs if the previous poll() call returned nothing waiting.
    -preFetchPriority Default value is 1. Use this parameter to add n records to the network message of an in-process prefetch query without additional polling. Adding more than one record to the message at a time can greatly reduce the number of poll() calls being made on a large database configuration. The expected result is that reducing poll() calls improves overall system performance by decreasing the "System CPU" cycles allow for increased "User CPU" cycles. The pollskip only occurs if the previous poll() call returned nothing waiting. For more information, see Prefetch Priority (-prefetchPriority).

    Here is a video that shows you how these parameters can improve performance:

Apply best practices for databases parameters and configurations

  • Put the before-image (BI) extent on a separate disk from the data extent, if possible—Writing to the BI extent should be as efficient as possible with no interference from other activity. If you have many databases on the same machine, then you put the BI extent with the data extents.
  • Stripe data extents—If you are using a RAID array, then there is no separate disk. i there are multiple RAID sets on your machine, then put it on a different RAID set on the same system.
  • Set the BI cluster size to 16 MB—Because larger BI cluster sizes increase the duration of checkpoints, allowing more time for modified database blocks to be written to disk by the page writers, Progress recommends setting the cluster size to 16 MB. The duration for the last 8 checkpoints are displayed in PROMON's Checkpoints option. If the checkpoints are at least a minute long, then you do not need to make any changes. Longer checkpoints are acceptable, but the checkpoints are not needed. If they are shorter than a minute, then increase the cluster size.

    If you have a workgroup database server license, then keep the cluster size small. Use a BI cluster size of 512 KB or less because a workgroup license does not include asynchronous page writers.

  • Leave -bibufs set to 64—The -bibufs parameter specifies the number of before-image buffers. This parameter is useful only when running the before-image writer (BIW).
  • Use two disks for AI extents, with the extents alternating between them—The purpose of after-image journaling is to provide a way to recover your database if the disk(s) holding your database fail. Do not store any AI extents on the same disks as the data extents. Alternating between two disks allows filled extents to be archived without slowing down the writing of the current extent. If you do not have enough disks, put all the AI extents on the same disk. If you are using a RAID array, then there is no separate disk, unless there are multiple RAID sets on the system. If there are multiple RAID sets, then put the AI files on a different RAID set on the same system.

  • Run at least one asynchronous page writer (APW)—The asynchronous page writer's job is to write modified database blocks to disk so that the database server does not have to do it and so that the modified blocks do not have to all be written to disk at the very end of a checkpoint. PROMON reports these writes as buffers flushed. The value for buffers flushed should be a number less than 10 for almost every checkpoint.