|
|
|
Transaction control comes at a performance cost. Fortunately, FairCom RTG transaction performance is tuned and configured out of the box for the most general best case usage.
Transaction performance is a balance of I/O and memory. Every transaction commit must be secured to persistent storage. This is done with a synchronous write to disk, which is the most expensive I/O write as it bypasses the filesystem cache. However, it is an absolute hard requirement to guarantee data recovery.
This write performance is balanced with holding data in memory caching as long as possible to maintain immediate access to updated record contents, avoiding additional I/O to disk. Periodically,updated “dirty” data is written back to the data and index files in the background to maintain the highest performance possible by the FairCom DB server.
Several options are used to tune this balancing act:
COMPATIBILITY TINDEX_WRITETHRU
Tip: Disable COMMIT_DELAY (-1) for most modern SSD storage devices. This is a legacy configuration that provides additional performance for older “spinning” type drives. It will be deprecated in the near future.
But I still want better performance!
If you are willing to open a minimal window of vulnerability, delayed durability may be an option for you. It ensures that transaction commits remain atomic and write to the transaction log as usual. However, it only goes to the transaction log in filesystem cache. It is not an immediate synchronous write to persistent storage. In this mode of operation a background thread is utilized to regularly flush and sync the filesystem cache to disk, ensuring your updates are secured. This can improve performance up to 300%!
The default (and recommended) time interval of this flush is once per second. Other values have not shown better performance and open wider vulnerability windows. In a high volume transaction writes, or with large transactions, the log buffer is often flushed and synchronized to disk immediately regardless, further minimizing vulnerabilities.
