Tech tips for performance tuning FairCom’s c-treeRTG

Note: c-treeACE became FairCom DB in November 2020.

FairCom c-treeRTG brings many advantages to your COBOL or Btrieve application, such as reliability, availability, serviceability, and access by modern interfaces such as SQL, ODBC, and JDBC. By replacing the file system, c-treeRTG not only improves data integrity, it also boosts performance. This document discusses several ways you can fine-tune your system to ensure you are getting the best performance so you get the most out of your c-treeRTG installation.

The tips below can be implemented using client-side configuration keywords in the ctree.conf file. For server-side configuration (using ctsrvr.cfg), the general FairCom DB Server configuration suggestions apply to c-treeRTG.

Note: These tips require changes to the c-treeRTG configuration file (ctree.conf). They should be performed only by a developer or administrator who is familiar with your installation and with c-treeRTG configuration keywords.

<optimisticadd>

The <optimisticadd> option enables adding keys before the data during WRITE operations. When <optimisticadd> is disabled, c-tree attempts to add unique keys before adding the data record. This eliminates the overhead of deleting a data record when the unique key check fails, speeding up the insert
process. Disable <optimisticadd> if the COBOL application frequently performs WRITE operations conflicting with existing records. See the documentation for <optimisticadd>.

Transaction Logging

In c-treeRTG (but not the default isCobol installation), it can be helpful to disable transaction logging if transactions are not used. You can completely disable transactions if data is stored on secure media (hardware redundancy, etc.). See the documentation for the <transaction> keyword.

<ctfixed>

Enabling the <ctfixed> option forces creating fixed-length record data files as fixed-length c-tree files. If you enable <ctfixed>, you may see a small performance enhancement as there is additional overhead in processing variable-length record data files. See the documentation for <ctfixed>.

<datacompress>

c-treeRTG allows data compression so that less disk space is used, which results in performance enhancements while reading and writing to disk. Enabling <datacompress> using the RLE algorithm provides the advantages of compressed data with a very small impact on CPU usage. Since most applications are saturated at the I/O level, the slight increase in CPU usage but less overhead on the I/O channel typically results in performance gains. Note that RLE compression (which is the default) is usually the fastest algorithm. See the documentation for <datacompress>.

<filepool>

Use <filepool> if files are frequently opened and closed. In COBOL applications it is common practice to close and re-open files for each procedure, which can cause unnecessary overhead. The <filepool> option keeps files open when the COBOL application requests to close them, allowing them to be available immediately when needed. Note: This may cause unexpected “file locked” situations when trying to open a file in exclusive mode if that file is kept open by the file pooling logic by another application. See the documentation for additional details for the <filepool> keyword.

<prefetch>

Use the <prefetch> option to improve performance of sequential reads. This option enables batch record retrieval to improve performance of consecutive sequential reads. It retrieves a specified number of records on the second consecutive sequential read. The next sequential read operations do not need to contact the server to retrieve records because they are now cached on the client side. Note: This might cause locking conflicts when an application attempts to write a record that has been prefetched and still buffered on the client. See the documentation for the <prefetch> keyword.

ACUCOBOL in RM/COBOL Compatibility Mode

Some installations use ACUCOBOL in RM/COBOL compatibility mode so that reads on locked records are expected to be blocked until the lock goes away (or a timeout is reached). If you are using this mode, you may find it beneficial to use <retrylock> and <locktimeout> to avoid the COBOL runtime polling the server to check for locks. ACUCOBOL runtime implements blocking locks by attempting the lock in a loop (by performing multiple requests) until the lock is released or the timeout expires. Using <retrylock> avoids a lot of communication traffic by having the server waiting on a lock. See the documentation for <retrylock> and <locktimeout>.

<memoryfile> and <temporary>

Use <memoryfile> on temporary files that do not need to be shared among applications. Use <temporary> on temporary files that may be shared among applications. Files set as <memoryfile> are not persisted to disk at all. Files set as <temporary> are persisted on disk but there is no guarantee of their consistency in case of disaster. See the documentation for <memoryfile> and <temporary>.