With your application code and physical database created, the next step is to deploy and initialize clients. Using procedure libraries and optimal client startup parameters can improve you application performance in test, staging, and production environments.

Store r-code in procedure libraries

You can organize and store r-code in an ABL procedure library. OpenEdge provides two types of procedure libraries: standard and memory mapped. A standard library contains r-code that executes in local memory. Using a procedure library this provides the following performance gains:
  • Faster access to r-code
  • Fewer file open and close operations
  • Less I/O to temporary files

A memory-mapped library contains r-code that executes in shared memory. If your application is deployed on a machine that supports running multiple ABL clients or if your application is deployed on a Progress Application Server for OpenEdge, then deploy your application in memory-mapped procedure libraries. A memory-mapped procedure library has the following advantages:

  • Fast access to r-code
  • Less memory needed because multiple clients access the same r-code segments in shared memory

For more information, see Load and execute r-code from a standard procedure library and Load and execute r-code from a memory mapped procedure-library in Manage ABL Applications.

Manage ABL clients

On client machines, OpenEdge consumes system resources to execute ABL procedures, store variables and record buffers, sort records, and store temporary files. When you manage client performance, be aware of key performance factors such as procedure loading and execution, temporary file I/O, and sorting I/O. In addition to these factors, application design and coding can significantly affect client performance. The following table describes some key startup parameters that improve performance.

Table 1. Client startup parameters
Parameter How performance is improved
-asyncqueuesize

Specifies the number of bytes that you want OpenEdge to allocate for the send and response queues for a PAS for OpenEdge connection. Use this parameter to maximize performance of asynchronous requests. OpenEdge creates the send and response queues for each connection; they are not used unless you make asynchronous requests to the PAS for OpenEdge instance. Choose a value based on the amount of data that you expect to flow between the client and the PAS for OpenEdge instance for these asynchronous requests. If you make a lot of calls, then set a higher byte level. If you do not make asynchronous requests, then set a lower byte value, to reduce the space allocated to queues that you will not use. For more information, see Async Queue Size (-asyncqueuesize).
-Bt Specifies the amount of memory the temp-table database manages uses to manage the temp-table database blocks. If all the memory is used, then the temp-table database writes the blocks to disk using a DBI file. These writes to disk cause swapping and can negatively affect performance. This setting controls the temp-table database in the same way that -B is controls your OpenEdge database. For more information, see Number of buffers for temporary tables (-Bt).
-D Controls the number of directory entries within which the AVM tries to manage the r-code files for your application. Each distinct .r file loaded by your application uses a directory entry, even when the .r file is loaded from a procedure library. If multiple persistent procedures or OOABL objects are running from the same .r file, then that .r file only consumes one directory entry. If you run out of directory entries, then the AVM looks for the least recently used entry that does not have an active program running it, and flushes that entry. If the .r file for that flushed entry is needed later, then It must be re-read into a new directory entry. If the directory entries are not managed properly, then this can lead to thrashing, continually flushing entries, and re-reading entries, which are bad for performance. For more information, see Directory Size (-D).
-mmax
Controls the execution buffer where r-code is managed. Each .r file is consists of multiple segments. These segments are loaded into memory for execution by the AVM. Some segments are only needed temporarily, for example, during initialization. The AVM locks the segments in memory only as long as they are needed. Any time compiled code is read into memory, it takes up room in the execution buffer. If there is not room within the -mmax setting, then the AVM swaps unlocked segments to disk. These unlocked segments are stored in the rcd temporary file.
Note:
  1. If you run out of this resource and the AVM cannot find any r-code segments to swap to disk, then the AVM automatically increases the -mmax setting. Swapping is bad for performance.
  2. Any r-code that resides in a Progress procedure Llibrary (.pl) is not swapped to the temporary rcd file. The AVM uses the procedure library file as its swap space.
  3. Any r-code that is in a memory-mapped Progress procedure library (.pl) does not consume any -mmax space; instead, the AVM uses the (shared) memory allocated by the OS to manage the .pl file when it is first opened.
For more information, see Maximum memory (-mmax).
-q A quick request is useful for testing, staging, and production environments. This parameter tells the AVM to run compiled code without checking for a pre-compiled file that may have changed. Production environments only have compiled code, so suppressing the check avoids overhead on testing, staging, and production systems. For more information, see Quick Request (-q).
-reusableObjects Improves the performance of applications that use ABL classes. When your application deletes an ABL object, either explicitly or through garbage collection, that object goes into the reusable object cache. The next time your application instantiates a new object of that same class, the AVM looks in the reusable object cache, and reuses the object instead of creating the object . This is particularly helpful if the object defines one or more temporary tables because temporary tables are more expensive to create from scratch. When an object goes into the cache, if the cache is full, then the least recently used object is deleted and is not available for reuse. For more information, see Re-usable Objects Cache (-reusableObjects).
-T Tells the AVM where to store temporary files. These include the rcd (r-code swap), lbi (local before-image), dbi (temp-table database), and other files. This is less of an issue for fast disks, but the performance loss is worse for slow disks like NFS-mounted disks. For more information, see Temporary Directory (-T) .