Btrieve Engine performance tuning Btrieve Engine performance tuning Hardware, memory, network configuration, etc. Play a major role in the application's performance, but there are also some configuration options related to Btrieve that could possibly improve performance.
Pervasive.SQL Optimum Server Recommendations. If s/he said that you needed a server with quad 4.8-gigahertz processors, 64 gigabytes of memory, and 32 terabytes of RAID disk or your application would roll over dead, you would either issue the purchase order or you would know why your application rolled over dead. It is possible to run these tools in DOS box on Windows 95 and Window NT operating systems in Btrieve client/server mode on TCP/IP protocol with Btrieve DOS Requester for TCP/IP v7.00.300. You must load the Btrieve DOS Requester at a workstation running DOS box before that workstation can access Btrieve data files on the network server.
Following are some guidelines for performance tuning. The Btrieve Microkernel Database Engine (MKDE) supports two configurations:. Client/Server configuration.This setup uses a single engine running at a NetWare or Windows NT server handling all the Btrieve I/O requests from multiple clients.
Workstation engine configuration. This configurations requires the MKDE to be loaded at each workstation that wants to access a Btrieve file on a shared (network) drive. This configuration is not recommended by Scala.
The MKDE architecture includes a set of background writers. These are background tasks that perform all the actual disk I/O on each Btrieve data file. By default, the MKDE bundles together multiple operations on one or more data files into a 'system transaction' before signalling the appropriate background writers to initiate the required disk I/O. This provides a performance benefit to environments where a lot of batch processing is performed.
When an MKDE has a portion of a file involved in a system transaction, that file is unavailable for disk I/O (reads or writes) by any other MKDE. This is required in order to guarantee the file's integrity. There are two parameters that control when the background writers should perform disk I/O. These are called the Operation Bundle Limit and the Initiation Time Limit. The Operation Bundle Limit specifies the maximum number of operations performed on any one file required to trigger a system transaction.
The Operation Time Limit specifies the time limit that triggers a system transaction. When either of these two limits is reached, the MKDE signals the background writer to perform the necessary disk I/O and release the files involved in the system transaction. The default value for the Operation Bundle Limit is 100 and the default value for the Initiation Time Limit is 1000 milliseconds. A good rule of thumb for Scala is Operation Bundle Limit 1000 and Initiation time limit 1000. Btrieve for DOS: Add parameter /g:: to the options= line in BTI.CFG.
Example, BTI.CFG may have: Btrieve Client options=/l:20 /f:20 /h:60 /t:15 /m:512 /u:0 /g:1000:1000. Btrieve for Windows NT/Windows 95: Use the Microkernel setup utility (W32MKSET.EXE) to modify the Operation Bundle Limit and the Initiation Time Limit settings. It is generally recommended that you provide Btrieve with at least a 4Meg cache. This will usually improve performance, especially for applications performing many write operations.
The Btrieve cache is configured through the Microkernel Setup utility provided with each Btrieve engine. In the Btrieve for DOS environment, the cache setting corresponds to the /m parameter on the options= line of BTI.CFG or BTI.INI.