InstantDB - Tuning


Home Top Next Prev

Please email any bug reports, comments or suggestions to:

peter.hearty@ceasar.demon.co.uk


InstantDB has been tried out with tables of over 100,000 rows. In these circumstances, setting the tuning parameters correctly can have a dramatic effect on performance.

Column Caches

The main thing that has to be tuned are the column caches. InstantDB doesn't cache "pages". Instead, it holds sections of individual columns in memory.

Note - in the current release only a single range of rows for any given column can be cached. Future versions will include multiple ranges.

InstantDB supports two algorithms for caching a column: CACHE_ROWS and CACHE_PERCENT. CACHE_ROWS caches a fixed number of rows from a column, whereas CACHE_PERCENT ensures that a fixed percentage is cached (which can in fact be 100%). The default algorithm can be altered using the cacheCondition property in the properties file. The amount to be cached is controlled using the cacheAmount property. Two additional properties, resultsSetCache and resultsSetCacheAmount fulfill a similar roll for results set tables.

InstantDB initially caches from row 1 up to some configurable limit. However, it also tries to find a better location. When a better cache location is found, the current cache is dropped and the new cache is set up. Two properties control when the cache gets reset. missesInCacheStats determines the number of recent lookups which are included in tests for better locations. For example, if this is set to 100, then the last 100 lookups are included in tests for a better cache location. cacheResetPercent controls how much better the alternative cache location has to be. For example, if this is set to 10, then the new cache site has to achieve a 10% better hit rate before a switch will take place. Dropping a cache will obviously lead to a short term drop in peformance. Setting cacheResetPercent appropriately ensures that the long term gain will compensate for this.

In addition to setting global defaults for the caching algorithm, InstantDB provides a non-standard SQL extension which can be applied at table creation time to control the caching of individual columns. Circumstances where this might prove useful would be where it would be impractical to cache all of a table, but where caching the primary key would improve the performance of joins. This additional column condition has the syntax:

CACHE rows {ROWS|PERCENT}

For example:

CREATE TABLE table1 (
	int1 int CACHE 10 PERCENT,
	int2 int CACHE 100 ROWS
)

It is not possible to control the caching of index columns. Indexes are always held entirely in memory and are only written to disk as a result of a clean shutdown. Failure to close the database cleanly, say as a result of an unhandled exception, causes the database to enter a recovery mode when it is next opened. During this recovery any indexes which have been modified are recreated from their target tables.

Changing a Column's Caching Algorithm

It is possible to change a column's caching algorithm after the table has been created. This can be accomplished by updating the $db$cols system table. This table has two columns that control the caching algorithm: CacheCond and CacheAmnt.

CacheCond is set to 1 to cache a fixed number of rows. It is set to 2 to cache a percentage of rows. For example, in the "sample" database, all of the columns default to caching 512 rows. To change the "ProductID" field of the "import1" table to cache 100% instead, issue the following SQL statement:

UPDATE sample$db$Cols 
	SET cachecond=2,cacheamnt=100 
	WHERE colname="ProductID" 
	AND tableid=(
		SELECT t.tableid 
		FROM sample$db$tables t 
		WHERE tablename="import1")
The database must then be shutdown and restarted for the new caching algorithm to take effect.

Additional Caches

As of InstantDB version 1.4, the Recent Row cache has been removed. Instead, non-cached rows are instantiated directly from the table read-ahead buffer.

InstantDB reads from tables in blocks of rows at a time. The number of rows read in a single IO is governed by the rowCacheSize property. The optimum value of this property will vary depending on the configuration of your system and on the characteristics of your database. However, a value of roughly 128 to 256 often produces good results.


Home Top Next Prev