UltraLite databases are stored on a set of pages on all platforms. A working set of pages is maintained in cache and is managed using a first-in, first-out (FIFO) scheme. Pages that are currently in use are locked in cache to avoid being swapped out.
For larger databases, the database can be configured each time it is opened to limit the number of rows and index pages that resident in memory at one time.
You can graph the UltraLite Java edition database performance with benchmark tests to determine the optimal cache size for your business solution.
You can test different cache sizes and watch for performance to change abruptly. Your cache should be large enough to have a good working set of pages. Consider the following ideas to help you stress the cache:
Create multiple indexes on the table and add foreign keys.
Insert rows randomly (something other than the index order).
Create large rows, at least 25% of the database page size.
Set the index hash to something other than 0. This increased size also increases the page accesses needed.
Start graphing performance based on the smallest cache size. For example, 256 KB on Windows (the smallest allowed cache for this platform) or 64 KB on all other platforms.
Encrypt or obfuscate the database. Obfuscation uses less code compared to strong encryption and performs fewer computations. Simple encryption performance should only be marginally slower than no encryption at all. However, your security requirements ultimately dictate whether to use strong encryption.
See also |
Discuss this page in DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |